[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPsec mandatory authentication algorithms
Robert Moskowitz writes:
>
>Well, actually, I have old messages from Hugo stating that HMAC addresses
>these concerns. And the workgroup came to the conclusion that HMAC-MD5 and
>HMAC-SHA1 were equally secure. Then once we truncated both to 96 bits,
>well is there a difference anymore, other than MD5 is consistantly reported
>as faster than SHA1...
Careful, Bob.
I've NEVER said that HMAC-MD5 and HMAC-SHA1 are EQUALLY secure.
There is NO evidence that that is the case. Actually, all evidence
points to the possibility that SHA1 is more secure.
This is a proven fact for the use of these functions for
collision-resistance (e.g, for their use with signatures).
In this case MD5 should be considered broken while SHA1 not.
For use of these functions with HMAC the situation is different.
None of these two candidates are broken in this case.
However, this is not a basis to claim that they are *equally* secure.
I append a message of mine to this list from (exactly) 1.5 year
ago in which I do recommend keeping MD5 for use with HMAC
based on the fact that MD5 is faster than SHA (by a factor of
2) and that SO FAR the known attacks on MD5 do not seem to endanger this
use of the function.
However, one reason that I feel comfortble making this recommendation
is the fact that ipsec design does allow for what Bart Preneel
put as "switching overnight to HMAC-SHA1" (and that authentication,
differently than encryption, does not have a backwards compromise effect;
see below).
I always thought that the best way to guarantee that implementations
are ready for a fast switch to SHA1 would be to mandate both transforms.
If this is done (I do not see the downside of it) an editorial note could be
put in the document saying that the security of SHA1 is probably better than
that of MD5 (even for use with HMAC) and therefore applications where
the security level is fundamentally more important than performance should use
SHA1. However, for those implementations where the superior speed of MD5 is
significant (and I personally know of such applications) could use HMAC-MD5.
To the point: I'm voting to keep both as mandatory.
>
>Thus many of us feel that MD5 is the mandatory, as the SHA1 does not seem
>to bring technical value.
Hope that the above correct this feeling. There is a technical value for
SHA1. Basically, it it hard to conceive that one day HMAC-SHA1 is broken but
HMAC-MD5 is not. The other way is more plaussible (though not plaussible
enough in the short term as to completely drop the use of MD5
*for this particular application with HMAC*)
LAST REMARK: all of the above (and below) refers to the use of HMAC as
a message authentication code in AH and ESP. Not as a pseudorandom function
as needed in isakmp/oakley. For that use our analytical results of these
functions are much weaker. As I said many times, for that use I'd prefer
3DES (and that's one of my reasons to "push" the general notion of prf instead
of just keyed-hash as well as to oppose wiring in in the isakmp/oakley spec
the use of HMAC as the only prf.) When using HMAC as a prf I do recommend using
SHA1 since in that case we need to be particularly cautious
(the "backwards compromise" problem does arise there) and also the
performance difference of MD5 and SHA1 is not that essential there.
[Sorry for diverging to this issue. Just to make sure that you do
not apply the reasoning in one case to the other]
Below is my old message.
Hugo
From: HUGO at watson.ibm.com
Date: Wed, 8 May 96 16:32:58 EDT
To: IPSEC@TIS.COM
Subject: 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.
[some technical issues on the analysis of HMAC removed]
Bottom line: I suggest keeping HMAC-MD5 as defined now. (And being always
very attentive to updates from the cryptanalytic front.)
Hugo