Subject: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-hmac-sha2)

From: Tom Yu <[email-masked]>
Date: Thu, 26 Sep 2013 15:01:11 -0400

There have recently been allegations that certain RNGs might be
compromised.  This is significant when making cipher mode decisions
for Kerberos, because encrypted confounders could mitigate against
malicious RNGs.  I suggest that we consider the tradeoffs of using
encrypted confounders.

Some of us have been thinking about whether encrypted confounders add
any security beyond plaintext explicit IVs.  Researchers,
e.g. Boldyreva and Kumar
(http://www.cs.washington.edu/research/projects/poirot3/Oakland/sp/PAPERS/oakland07-24.pdf)
have proven that the encrypted confounder CBC modes in Kerberos with
encode-then-E&M are no worse than explicit IVs with encrypt-then-MAC.

A posting by Perry Metzger
(http://www.metzdowd.com/pipermail/cryptography/2013-September/017571.html)
brings up the idea of explicit plaintext IVs as being a covert channel
through which a malicious RNG could leak state information.  If, as
alleged, leaking only 32 bytes of RNG output is sufficient to allow
recovery of its internal state, leakage through IVs is a serious risk.
Using an encrypted confounder can remove this covert channel, or at
least significantly raise the bar for using it.

A malicious implementation could still leak RNG state by first passing
the confounder through a block decryption operation, but that requires
access to the encryption key.  Also, invocation of a decryption
operation during what is supposed to be an encryption operation might
be more obvious to auditors than a malicious RNG would be.

I think one question we should consider is whether the increased
security from using encrypted confounders is worth deviating from the
historically preferred explicit IVs that we're considering in
draft-ietf-kitten-aes-cts-hmac-sha2.

---

From: "Paul Miller (NT)" <[email-masked]>
Date: Fri, 27 Sep 2013 22:56:07 +0000

While I agree with the analysis that the use of a confounder will limit the exposure of the state of a faulty PRNG, I don't see this as a problem that needs to be addressed by Kerberos.  The RNG is a system service and not part of the Kerberos specification.  RFC 4120 references RFC 4086 "Randomness Requirements for Security" so the condition not to use a PRNG that leaks state is already covered.  Between nonces and randomly generated session keys, there are plenty of other avenues for insufficient randomness to manifest.

This is not to say that I disagree with using a confounder.  A confounder is quite useful as a source of cipher text from which to steal in order to make CTS work with short inputs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Yu
Sent: Thursday, September 26, 2013 12:01 PM
To: [email-masked]
Subject: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-hmac-sha2)

There have recently been allegations that certain RNGs might be compromised.  This is significant when making cipher mode decisions for Kerberos, because encrypted confounders could mitigate against malicious RNGs.  I suggest that we consider the tradeoffs of using encrypted confounders.

Some of us have been thinking about whether encrypted confounders add any security beyond plaintext explicit IVs.  Researchers, e.g. Boldyreva and Kumar
(http://www.cs.washington.edu/research/projects/poirot3/Oakland/sp/PAPERS/oakland07-24.pdf)
have proven that the encrypted confounder CBC modes in Kerberos with encode-then-E&M are no worse than explicit IVs with encrypt-then-MAC.

A posting by Perry Metzger
(http://www.metzdowd.com/pipermail/cryptography/2013-September/017571.html)
brings up the idea of explicit plaintext IVs as being a covert channel through which a malicious RNG could leak state information.  If, as alleged, leaking only 32 bytes of RNG output is sufficient to allow recovery of its internal state, leakage through IVs is a serious risk.
Using an encrypted confounder can remove this covert channel, or at least significantly raise the bar for using it.

A malicious implementation could still leak RNG state by first passing the confounder through a block decryption operation, but that requires access to the encryption key.  Also, invocation of a decryption operation during what is supposed to be an encryption operation might be more obvious to auditors than a malicious RNG would be.

I think one question we should consider is whether the increased security from using encrypted confounders is worth deviating from the historically preferred explicit IVs that we're considering in draft-ietf-kitten-aes-cts-hmac-sha2.
_______________________________________________
Kitten mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/kitten

---

From: Nico Williams <[email-masked]>
Date: Sat, 28 Sep 2013 21:23:07 -0500

> least significantly raise the bar for using it.

That's an interesting idea.  Combined with a counter mode that would
be... counter mode.  Counter reuse being so disastrous to counter
modes, one could use a small counter, pad it, and encrypt into an IV
for a CBC/CTS mode.  Combined with small sequence number windows this
would make it very difficult to leak data via the IV.  Anyways, an
enctype based on such a mode would not fit RFC3961.

Which brings me to: RFC3961 is a bit too constraining.  A single,
simple extension would make it so much easier to produce new enctypes:
an indication of whether a given key is a long-term key, a Ticket
session key, a sub-session key, or some other type of key (e.g.,
non-shared).  Actually, we could derive that from key usage for known
key usages, and we could setup key usage number ranges as well for
future uses.  Anyways, just an idea.

Nico
--