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

Taher Elgamal wrote:
> 
> 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

I would just like to be sure I'm understanding this correctly. Does this mean,
for example, that an MD5 digest as used in PGP to generate a key fingerprint
is no longer secure?

Cheers,

Ben.

> 
> 
> HUGO@watson.ibm.com wrote:
> > 
> > As it has been already announced in this list, MD5 is broken for collisions
> > (Hans Dobbertin has extended his own techniques used against MD4 to attack
> > MD5 as well).
> > MD5 needs to be dropped (hope everyone already did) from any use that
> > requires resistance to collisions by plain MD5.
> > 
> > One application that is NOT broken with Dobbertin's attack is HMAC with MD5.
> > Collisions in plain MD5 do not compromise HMAC-MD5 as the latter uses
> > secret IVs and hides the result of the inner iterated function.
> > The question is whether the new attack has a significant potential
> > of being developed further to break also HMAC-MD5.
> > Beyond our own assessment we have got the opinion of a few first line
> > cryptographers that they see no way to make these techniques work against
> > the use of MD5 in HMAC.
> > 
> > With permission of Hans Dobbertin I reproduce this note he sent to me
> > over the weekend in response to my question of whether he sees any
> > application of his results to break HMAC-MD5:
> > 
> >     Date: Sat, 4 May 1996 22:48:09 +0200 (MET DST)
> >     From: Hans Dobbertin <>
> >     To: "H.Krawczyk" <hugo@watson.ibm.com>
> > 
> >     Hi Hugo,
> > 
> >     I looked in your paper which you have sent me in January. To answer your
> >     question I can assure you that I cannot image any way to attack MD5 as it
> >     is used in HMAC.  To be more precise, from the recent attack on MD5
> >     (compress) one cannot derive any reservation against the use of MD5 in
> >     this context. (Perhaps one could argue that the randomness of MD5 is not
> >     sufficiently investigated ..., but that is another question, and I
> >     personally do not see a problem here.)
> > 
> >     Best regards, Hans
> > 
> > This does not mean in any way that HMAC-MD5 is going to be secure forever.
> > It is only to stress that the new attack is not necessarily a reason to drop
> > MD5 from its current use in IPSEC.
> > 
> > I believe that we can keep using it until new developments will bring
> > HMAC-MD5 closer to a break. Remember this "principle" from
> > draft-ietf-ipsec-hmac-md5-txt.00:
> > 
> >      Message authentication, as opposed to encryption, has a "transient"
> >     effect. A published breaking of a message authentication scheme
> >     would lead to the replacement of that scheme, but would
> >     have no adversarial effect on information authenticated in the past.
> >     This is in sharp contrast with encryption, where information encrypted
> >     today may suffer from exposure in the future if, and when, the
> >     encryption algorithm is broken.
> > 
> > Following this principle I believe we can keep enjoying the better speed of
> > MD5 at least for some time (weeks? months? years? who knows?)
> > 
> > Just to stress this: there is NO known security advantage in keeping
> > MD5 relative to going to SHA-1. The only issue here is performance.
> > It is there where the trade-off seems to favor MD5 right now.
> > 
> > Having said all of this here is a short note on the theory behind HMAC-MD5.
> > In our paper we have chosen to make much stronger assumptions than needed
> > on the underlying hash function. This is motivated by the search of easy
> > to state and well-defined assumptions together with a simple and correct
> > analysis. One of these assumptions on the hash function which we call
> > "weakly collision resistance" requires resistance to collisions when the
> > IV is secret. In a strict sense such collisions can be found for MD5
> > using Dobbertin's techniques. However, this is possible through
> > extension attacks that are prevented in HMAC by the outer application
> > of MD5. Therefore, the actual function HMAC-MD5 remains secure.
> > 
> > In our coming Crypto'96 paper we will elaborate more on the analytical
> > issues and strength of assumptions. In particular, we may suggest an
> > additional (more conservative) variant of HMAC in which one appends a
> > key to the data before hashing (in the inner transformation).  However,
> > this has to be seen as "yet another fence" and not something for which
> > there is clear indication that we need to adopt immediately.
> > 
> > Bottom line: I suggest keeping HMAC-MD5 as defined now. (And being always
> > very attentive to updates from the cryptanalytic front.)
> > 
> > Hugo
> 
> -- 
> Taher Elgamal	    elgamal@netscape.com
> Chief Scientist, Netscape Communications
> (T) 415 937 2898, (F) 415 428 4054
> 

-- 
Ben Laurie                  Phone: +44 (181) 994 6435
Freelance Consultant and    Fax:   +44 (181) 994 6472
Technical Director          Email: ben@algroup.co.uk
A.L. Digital Ltd,           URL: http://www.algroup.co.uk
London, England.

Received on Friday, 10 May 1996 10:17:09 UTC