Re: SHA-2 based HMAC algorithm...

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

"denis bider (Bitvise)" <ietf-ssh2%denisbider.com@localhost> writes:

> Is there a way we can agree on HMAC-SHA-256 with a 32-byte key, call it 
> "hmac-sha256", and register it?

I see you're trying to follow the hmac definitions in RFC 4253. But is
there any good reason a hmac keysize should match the digest size, in
general? My understanding of hmac keysize, is that

  * it can't usefully exceed the internal hash blocksize (64 bytes for
    sha1 and sha-2-256, 128 bytes for sha-2-512)

  * should be large enough to exclude keysearch, by a reasonable margin

Any other concerns I'm missing? Is the birthday paradox relevant to hmac
in some way?

My gut-feeling is that the suggested keysize (64 bytes, 512 bits) for
hmac-sha2-512 is ridiculously large for a symmetric cryptographic
construction. 20 bytes (160 bits) seem sufficient, and 32 bytes (256
bits) is overkill for the foreseeable future.

I fully support a spec for using sha-2, but I'd like to see some
motivation for the chosen key sizes. 

Ah, and one other thing: Would it make sense to use hmac-sha2-224-96
(different initial state) rather than hmac-sha2-256-96? I confess I
never really understood the rationale behind sha2-224 and sha2-384.

Regards,
/Niels

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