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

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


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

Received on Wednesday, 8 May 1996 17:50:45 UTC