Re: SHA-2 based HMAC algorithm...

[nisse%lysator.liu.se@localhost (Niels Möller)]

Peter Gutmann <pgut001%cs.auckland.ac.nz@localhost> writes:

> The convention, both for pre-SHA2 hashes, and in other protocols where SHA2
> hashes are used, is to use the block size as the key size.

I see. I take it you mean *digest* size, not *block* size (or else,
hmac-sha1 would use a keysize of 64 octets / 512 bits)?

I guess there's some value in doing the same thing as everybody else, as
long as that way is silly rather than actually broken.

(And I should modify my previous statement that key size "can't usefully
exceed the internal hash blocksize". After thinking just a little bit
more I realized that key sizes larger than the *digest* size are not
very useful, since it's the digest size, rather than the block size,
which corresponds to the size of the internal state. This makes the
convention of using keys of the same size as the digest more
understandable. Sorry for the confusion).

> To quote someone on another list (possibly SAAG), SHA2-224 and -384 were
> created by NIST to confuse the crypto-clueless. 

The only property of sha224 which you don't get with sha256 with
trunctated output, is that its difficult, given a sha256 hash of unknown
data, to produce a sha224 hash for the same data (and similarly for
sha512 and sha384). And also in the other direction, given a sha256 hash
of unknown data, truncated to 224 bits, one could guess the missing bits
with a success probablility of 2^{-32}; that is a lot harder to do based
on the sha224 hash of the data.

I don't know any protocol or scenario where these sha224 properties are
important or desirable, but maybe there is some?

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.