[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

HMAC-MD5: to be or not to be?



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