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

Dan Simon wrote:
>> 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).

I don't believe this is true.  The way the handshake hashes are used in
SSL 3.0 requires that a collision exist in both MD5 and SHA1 for the same
pair of message streams.  To construct such a collision is currently
computationally infeasible.  Negotiating the function(s) to be used in the
handshake hashes allows a roll-back attack if any of the possible hash
functions are compromised.  

> My own recommendation would be that use of MD5 simply be abandoned;

I think that's a great idea.  This attack certainly shows MD5 to be
weaker than previously thought, but it's not totally broken.  We should
move away from MD5 as soon as reasonably possible, but I don't think we
should panic and abandon existing standards without suitable replacements.  

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

What are you talking about?  The MAC is SSL 3.0 is keyed and relies
primarily on the secrecy of the key, not the collision intractability
of the underlying hash function.  Both places where signatures are used
rely on both MD5 and SHA (except for DSA signing).  What kind of attack
do you think a hash collision could allow on the signed messages?

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

I strongly oppose splitting the cipher suite up into several seperate
"fields".  It provides no extra level of flexibility or security and it
only encourages people to mix and match algorithms in untested ways.
As I already stated, I believe that allowing negotiation of the algorithm
used for computing the handshake hashes allows a roll-back attack.  The
use of a single algorithm is also weaker than the paired algorithms
currently used.

-- 
One tag to rule them all, One tag to find them; One tag | Tom Weinstein
to bring them all, and in the source tree bind them.    | tomw@netscape.com

Received on Wednesday, 8 May 1996 21:21:30 UTC