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

["Paul Miller (NT)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Tom Yu
Sent: Thursday, September 26, 2013 12:01 PM
To: [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/kitten