- From: Ben Laurie <ben@gonzo.ben.algroup.co.uk>
- Date: Fri, 10 May 1996 14:34:54 +0100 (BST)
- To: Taher Elgamal <elgamal@netscape.com>
- Cc: ietf-tls@w3.org
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