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

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.

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. :-)

P.S. Of course there are also bandwidth and packet size concerns that matter
even though they're not "security" issues.

On 7/6/10 10:40 , "Nikos Mavrogiannopoulos" <nmav@gnutls.org> wrote:

> Martin Rex wrote:
> 
>>> There's no logic to it, or whatever there might be is too clever by half.
>> 
>> There appears to be a lack of logic by not adjusting the truncation size
>> when going from a SHA-1 (=160 bits) based PRF to a SHA-256 (=256 bits)
>> based PRF.  In case a 96 bit truncation is deemed adequate for SHA-1,
>> then a truncation like 144 or 160 bits appears more appropriate for SHA-2.
> 
> Or just sending the whole output. I don't even know why truncation is
> there. I'd understand truncation in the record layer HMAC that is sent
> on every message, there it would save bandwidth... but on the finished
> message?
> 
> regards,
> Nikos
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls