Jerrold Leichter wrote: > > | > NIST is proposing a change notice for FIPS 180-2, the Secure Hash Standard > | > that will specify an additional hash function, SHA-224, that is based on > | > SHA-256. The change notice is available at > | > http://csrc.nist.gov/publications/drafts.html. NIST requests comments for > | > the change notice by January 16, 2004. Comments should be addressed to > | > [EMAIL PROTECTED] > | > | Does anyone know what the story is behind this? It seems to be the > | same sort of relationship that SHA-384 has to SHA-512 - that is, the > | same basic algorithm, the same amount of work to calculate it, but > | with different initial values, and some bits chopped off at the end. > | It all seems a lot of effort just to save 4 bytes in the final hash.
> I'd guess that this is part of an effort to define hashes "equivalent in > strength" to various standardized ciphers. Because of birthday attacks, in > some sense the security of an n-bit hash is comparable to that of an n/2-bit > cipher. So SHA-256, -384, and -512 are intended to match the three supported > AES key sizes of 128, 196, and 256 bits. SHA-224 then comes out to match > 2-key 3-DES. That is the guess we came up with too. But, why does NIST bother to standardise this? Granted 2-key 3-DES is in widespread use, but it should gradually switch across to other ciphers. And, for a stop-gap measure, if a protocol implementor finds a need to match a hash size, why not just truncate a SHA-256? Or, to take the alternate position, if there is a case for "wierd lengths," then maybe this is a case that SHA could be reworked to be of flexible length, at the algorithm level? Defining a new SHA seems to be a lot of detailed work, albeit hardly challenging, for everyone involved in producing standard crypto, and there doesn't seem to be much of a payoff for all those people. iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
