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

[Sam Hartman <[e-mail]>]

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

    Paul> While I agree with the analysis that the use of a confounder
    Paul> will limit the exposure of the state of a faulty PRNG, I don't
    Paul> see this as a problem that needs to be addressed by Kerberos.
    Paul> The RNG is a system service and not part of the Kerberos
    Paul> specification.  RFC 4120 references RFC 4086 "Randomness
    Paul> Requirements for Security" so the condition not to use a PRNG
    Paul> that leaks state is already covered.  Between nonces and
    Paul> randomly generated session keys, there are plenty of other
    Paul> avenues for insufficient randomness to manifest.  This is not
    Paul> to say that I disagree with using a confounder.  A confounder
    Paul> is quite useful as a source of cipher text from which to steal
    Paul> in order to make CTS work with short inputs.

The issue here in my mind is that it seems like we as a community have
paid inadequate attention to what the damage of a malicious RNG could do
is.  We've been focusing on the sorts of things described in RFC 4086,
rather than RNGS maliciously affected either in implementation or
standards.

That class of attack having been pointed out, we should consider its
impact on security systems we design.

I agree that introducing another covert channel by which random data can
leak is kind of uninteresting.

However, an attacker who can predict your RNG state will now be much
more able to predict future explicit IVs.
Where as that attacker will find it difficult to predict explicit
confounders without knowing the key.

I have not yet figured out whether this matters.