Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Additionx

[Marsh Ray <[e-mail]>]

On 03/08/2011 01:36 PM, Blumenthal, Uri - 0668 - MITLL wrote:
> In general - since pseudorandom-ness of the output was NOT a design
> principle or criteria of hash functions (until SHA3) - truncating
> hash output is problematic from crypto point because you cannot
> reasonably assume that all the output bits have the "entropy" spread
> over them equally.

But if you can find a systematic way to generate patterns in the output, 
then you have a publication-worthy attack on the function. E.g. if you 
have a way to cause any specific bit position of the output of SHA-256 
to be a '0' 75% of the time, then you have reduced it to a 255.2-bit 
function. (Hilarity ensued when this turned out to be case with RC4).

The TLS doesn't use a raw hash function though. It doesn't even use a 
raw HMAC. It uses recursive application of an HMAC to generate an 
arbitrary amount of output, essentially making a stream cipher. This is 
probably the most conservative aspect of TLS's design, making me a big fan.

For TLS 1.2 it's:

     verify_data
        PRF(master_secret, finished_label, Hash(handshake_messages))
           [0..verify_data_length-1];

     PRF(secret, label, seed) = P_<hash>(secret, label + seed)

     P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + ...

     A(0) = seed
     A(i) = HMAC_hash(secret, A(i-1))

Each HMAC represents two hash function invocations, each SHA-256 
represents 64 rounds.

So before they are used to generate the first block of output, the 
handshake_messages are hashed something like 5 times mixing in 
additional pseudorandom key material all but the first time.

Don't get me wrong, I think 96 bits is too short and is probably a 
holdover from the days when we (wisely) didn't trust our ability to 
design hash functions. But insufficient diffusion does not look like a 
problem.

- Marsh