RE: Remove little-used algorithms from IKEv2
"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 14 March 2002 22:34 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2EMYK426205; Thu, 14 Mar 2002 14:34:20 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA06545 Thu, 14 Mar 2002 17:00:19 -0500 (EST)
Message-ID: <2F3EC696EAEED311BB2D009027C3F4F405869A0A@vhqpostal.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: 'Paul Hoffman / VPNC' <paul.hoffman@vpnc.org>, "Hallam-Baker, Phillip" <pbaker@verisign.com>, ipsec@lists.tislabs.com
Subject: RE: Remove little-used algorithms from IKEv2
Date: Thu, 14 Mar 2002 14:12:53 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1CBA5.63534B10"
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
> - As I understand the argument, the "somewhat" is exactly that: there > is no known break for real-world use, but there is a strong suspicion > that a break could happen. > > - We want it in there in case of a catastrophic failure of SHA-1 and > the related bigger SHAs. SHA-1 and MD5 are both variants of MD4 that share the same design approach with the addition of extra rounds. SHA-1 also has an initial expansion stage that was added at a later date that appears to have been introduced to defend against the attack Dobbertin discovered recently. In short, if SHA-1 is broken it ia almost certain that MD5 will have been broken. To answer Henry's point about MD5 not being designed by the NSA, well the same pretty much applies to SHA-1. The only NSA input that could be detected was the expansion fix. > If those have the same failure relationship to SHA-1 as MD5 does, the > argument becomes circular. My understanding is that the SHA-2 algorithms are going to be something completely different with no architectural ties to the MD4 scheme. Last I tracked it the discussion appeared to be centered on hashing modes for AES. The performance issue does sound like it could be a reasonable justification, particularly for HMAC-MD5. However there is the counter argument that for most applications DES is perfectly adequate and three times faster than 3DES. Incidentally, any reason why CAST remains on the list? Also in his JFK talk Steve Bellovin made some comments about 3DES still being subject to problems in certain block modes that mean you want to do rekeys at intervals of 2^(56/2)= 2^28 blocks due to the fact that you are using the same 64 byte value to mask each of the 3 DES keys so you will start to double encipher under the same key quite quickly (and in some cipher modes detectably). I don't think we can kill off 3DES, but there should probably be some pretty strong 'don't use this' type advice. Phill
- Remove little-used algorithms from IKEv2 Paul Hoffman / VPNC
- RE: Remove little-used algorithms from IKEv2 Hallam-Baker, Phillip
- RE: Remove little-used algorithms from IKEv2 Henry Spencer
- Re: Remove little-used algorithms from IKEv2 Paul Koning
- Re: Remove little-used algorithms from IKEv2 Dan McDonald
- RE: Remove little-used algorithms from IKEv2 Paul Hoffman / VPNC
- Re: Remove little-used algorithms from IKEv2 Paul Hoffman / VPNC
- RE: Remove little-used algorithms from IKEv2 Hallam-Baker, Phillip
- Re: Remove little-used algorithms from IKEv2 Derek Atkins
- Re: Remove little-used algorithms from IKEv2 Paul Hoffman / VPNC
- Re: Remove little-used algorithms from IKEv2 Uri Blumenthal
- Re: Remove little-used algorithms from IKEv2 Paul Hoffman / VPNC
- Re: Remove little-used algorithms from IKEv2 Henry Spencer
- Re: Remove little-used algorithms from IKEv2 Paul Koning
- RE: Remove little-used algorithms from IKEv2 Hallam-Baker, Phillip
- Re: Remove little-used algorithms from IKEv2 Stephane Beaulieu
- RE: Remove little-used algorithms from IKEv2 Paul Hoffman / VPNC
- Re: Remove little-used algorithms from IKEv2 Dan McDonald