Nikos Mavrogiannopoulos wrote: > > On 03/14/2011 06:28 PM, Martin Rex wrote: > > > > That was, what I assume, the fear, based on the second part of this > > message from Dan Simon > > http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html > > and the second part of this message from Hugo Krawczyk > > http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0231.html > > > > Since the TLSv1.0 finished message was defined based on the output > > of the TLS PRF (a function with indefinite output length), > > defining a truncation was inevitable. :) > > Indeed. It seems the messages you list summarize that design decision > in a nice way. The concerns for the one-wayness of the MAC used lead > to that truncation. That way one-wayness is ensured by discarding data > at the cost of having a weaker MAC. I don't know if the current > construction can be extended for a longer size without implications. The concern with the one-wayness of the hashes was about >SSLv3< and how it computed its Finished message: enum { client(0x434C4E54), server(0x53525652) } Sender; struct { opaque md5_hash[16]; opaque sha_hash[20]; } Finished; md5_hash MD5(master_secret + pad2 + MD5(handshake_messages + Sender + master_secret + pad1)); sha_hash SHA(master_secret + pad2 + SHA(handshake_messages + Sender + master_secret + pad1)); handshake_messages All of the data from all handshake messages up to but not including this message. This is only data visible at the handshake layer and does not include record layer headers. Personally, I'm having difficulties to see how exactly it would leak the master_secret if MD5 was found to be fully invertable. The MD5 output is 128 bits = 16 bytes, and the input is *MUCH* larger than 128 bits. The master_secret should is 48 bytes alone. Even if one is successful at inverting MD5, one can not undo the collisions from the Finished computation caused by the compression of a much larger input into a 128 bit output value. Anyhow, I do see the new Finished computation algorithm in TLSv1.0 as a sensible change in the TLS design. -Martin _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf