Re: [TLS] draft-turner-ssl-must-not

[Marsh Ray <[e-mail]>]

On 07/06/2010 12:17 PM, Blumenthal, Uri - 0668 - MITLL wrote:
> There are two attacks: (a) finding collisions, and (b) offline
> guessing/brute-forcing the key. The fewer bits of the complete hash you have
> - the less ability to verify&  disambiguate your guess.
>
> The balance is between outputting enough bits to defeat collision-based
> attacks, yet omitting enough bits to prevent disambiguating the key in
> offline trials.

My impression was that preventing the occurrence of known plaintext was 
no longer considered an important design principle.

Even if the Finished message were made very short, it's probable that 
there will be plenty of known plaintext in record headers, padding 
bytes, not to mention the application data itself. Any text based is 
going to have a zero high bit on a great majority of chars, compression 
is far from standard and it presumably brings its own known headers.

So, from what I hear, modern ciphers are expected to be resistant to 
known plaintext attacks.

> Most of the sources prioritize fending off collision seekers.
>
> Barring a discovered cryptographic weakness in the underlying hash function,
> the likelihood of finding collisions in SHA256 output (say even truncated to
> 160 bits) is comparable with the likelihood of guessing a key used for HMAC.
> Both currently aren't high on my list of concerns.

Even if the hash functions are broken, the PRF is very conservatively 
designed. The hash functions are doubled-up in the HMAC construct, and 
HMAC is then performed recursively to generate the output! For TLS 1.0 
and 1.1, this is done separately for MD5 and SHA-1 and those results get 
combined. It's nice that there are some parts of the design with a 
generous safety margin!

- Marsh