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

RE: Remove little-used algorithms from IKEv2




> - 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

Phillip Hallam-Baker (E-mail).vcf