RE: [Fwd: HMAC-MD5: to be or not to be?]

>
>From: 	Taher Elgamal[SMTP:elgamal@netscape.com]
>
>This is forwarded to this group. We should keep the secrets in the
>inner
>hash in the MAC in SSSl/STLP/ the name of the day protocol.
>
>Taher

Well, I certainly agree that if we keep MD5 around as a valid choice of
hash function for MAC computation, then we should stick with HMAC.  In
that case, though, either MD5 should be removed from the "handshake
hash" (or replaced with another, non-broken hash function), since it is
used there without a key prefix to the input, or the "handshake hash"
should be restructured as an HMAC-style MAC.  (I'll make another pitch
here for not explicitly specifying the hash function or functions used
in the "handshake hash"; if this news about MD5 had come out a year
later, then the body of the spec itself would have had to be revised,
instead of just the list of valid hash functions).

My own recommendation would be that use of MD5 simply be abandoned;
after all, the new break affects not only the MAC method, but also
(hash-and-)signature-based authentication, where no secret MAC key can
be relied upon to make collision-finding harder.  A more
cryptographically correct alternative might be to define cipher suites
with separate choices for "MAC hash function" and "signature hash
function", with MD5 being permissible for the former (assuming
HMAC-style MACs) but not the latter.  An advantage of this approach
would be that various superfast hash functions (Krawczyk's LFSR hash,
Rogaway's "bucket hash") which are only useful for MACs could eventually
be added as options.  On the other hand, the extra complexity would make
cipher suite management completely unwieldy.  (Then again, I consider it
to be already completely unwieldy, and would like to see each type of
algorithm negotiated separately.)  

				Daniel Simon
				Cryptographer, Microsoft Corp.
				dansimon@microsoft.com


>
>
>

Received on Wednesday, 8 May 1996 19:11:18 UTC