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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
