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

Re: [Ipsec] Last Call: 'Cryptographic Algorithm ImplementationRequirements For ESP And AH' to Proposed Standard



Bart,

I am aware of most of the results you mention. Yet, they do not seem to
show any particular weakness of MD5 in the HMAC contest (not more than
SHA-1). Of course, being conservative is a good thing in cryptography but
in this case arguing against HMAC-MD5 may be too conservative.

First, as far as I can see there is no indication that we are closer to a
break of HMAC-MD5 than to a break of HMAC-SHA1 (which is what we are
comparing with).  Second, MAC functions have the nice property that their
break affects security of those using the function AFTER the break, not
those that used it before (this is in sharp contrast to encryption);
therefore having HMAC-SHA1 in an implementation (and this is what ipsec is
demanding by having HMAC-SHA1 as a MUST) allows to move to HMAC-SHA1 if
necessary (i.e. if serious deficiencies of MD5 are found that effect its
security in the context of HMAC). Third, the better speed of MD5 is
significant in some environments (and only for those the use of HMAC-MD5
should be considered).

Finally, I like your last suggestion: a concrete proposal based on
universal hashing for those that need truly fast authentication.
However, I am disappointed by the lack of perceived need for such speeds.
(Say 5-10 times faster than MD5). If anyone has a clear need for such
functions (in particular in the ipsec world) I'd like to know.

Hugo

On Sat, 10 Jul 2004, Bart Preneel wrote:

> Hugo,
>
> I am not so sure that we should strenghten the recommendation for HMAC-MD5.
>
> 1) Very few researchers work on hash functions of the MDx-type, and I am
> aware of only 1 (not yet published) result on "deviation of randomness"
> for these functions; hence the absence of results should not be
> interpreted as an indication of security.
>
> 2) The little effort that has been spent has resulted in some progress
> in the last 2 years:
>
> Saarinen has shown at FSE 2003 that there are some problems when SHA-1
> and MD5 would be used as block ciphers (keyed by the message input -
> feedforward omitted); collisions have been found for 3 rounds of HAVAL
> (Biryukov et al., Asiacrypt 2003); at Crypto 2004 Eli Biham and Rafi Chen
> will present near-collisions of SHA-0 (they can also break now 36 rounds
> of SHA-1).
>
> None of these attacks forms a direct threat to HMAC-MD5, but these
> results show that after 10 years our ability to attack this type of functions
> keeps improving; nothing indicates that this progress will stop in
> the next years.
>
> 3) Nobody has so far attempted to apply algebraic attacks to these
> objects; these attacks have been rather successful against stream
> ciphers, even if their applicability for block ciphers is currently
> unclear.
>
> Once problems are discovered, getting rid of an algorithm is difficult,
> which is a reason to be conservative (some components in the banking world
> are still in the process of being upgraded from DES to triple-DES).
>
> Finally, it seems that if performance is really an issue, one should
> start working on developing a concrete solution using universal
> hash function-based constructions.
>
> --Bart
>
> On Thu, 8 Jul 2004, Hugo Krawczyk wrote:
>
> > Draft draft-ietf-ipsec-esp-ah-algorithms-01.txt
> > specifies HMAC-MD5 as MAY (in the list of authentication algorithms).
> >
> > Given that 8 years after the invention of HMAC and 8 years after
> > Dobbertin's attacks on MD5 there is no single piece of evidence (big or
> > small) against the use of HMAC-MD5, and given that HMAC-MD5 is close to
> > twice the speed of HMAC-SHA1, then I suggest to upgrade HMAC-MD5 to SHOULD
> > (it is good to make it available for applications that need the speed,
> > especially in authentication-only configurations (are there any?)
> >
> > Just a suggestion. Feel free to ignore.
> >
> > Hugo
> >
> > On Wed, 23 Jun 2004, The IESG wrote:
> >
> > > The IESG has received a request from the IP Security Protocol WG to consider
> > > the following document:
> > >
> > > - 'Cryptographic Algorithm Implementation Requirements For ESP And AH '
> > ><draft-ietf-ipsec-esp-ah-algorithms-01.txt> as a Proposed Standard
> > >
> > > The IESG plans to make a decision in the next few weeks, and solicits
> > > final comments on this action.Please send any comments to the
> > > iesg@ietf.org or ietf@ietf.org mailing lists by 2004-07-07.
> > >
> > > The file can be obtained via
> > > http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-algorithms-01.txt
> > >
> > >
> > > _______________________________________________
> > > Ipsec mailing list
> > > Ipsec@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/ipsec
> > >
> >
> >
> >
> > _______________________________________________
> > Ipsec mailing list
> > Ipsec@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ipsec
> >
>
>
>
>


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec