Re: SHA-2 based HMAC algorithm...

[Dan Brown <dbrown%certicom.com@localhost>]

What about FIPS 180-4, which, if I recall, defines SHA-512-256, a truncation of SHA-512 with a different IV?

Arguably for use in HMAC it could be truncated to 128 bits (or less), so one could have:

HMAC-SHA2-512-256-128

(But I didn't yet check what 180-4 wants for HMAC.)

With regard to naming, to avoid ambiguity with future 180-4 followers, the number of numbers following SHA2 could be used to determine their meaning: with 180-4 truncation requiring three numbers even if no further HMAC tag truncation is applied, eg HMAC-SHA2-512-256-256.

HMAC accepts any key size, so adding key size to alg name seems odd.  Nevertheless, parties must use the same key size, maybe the protocol, ie SSH, using HMAC should fix key size to the largest not requiring an extra hash?

Best regards,

Dan

----- Original Message -----
From: Peter Gutmann [mailto:pgut001%cs.auckland.ac.nz@localhost]
Sent: Sunday, April 10, 2011 08:32 AM
To: ietf-ssh2%denisbider.com@localhost <ietf-ssh2%denisbider.com@localhost>; nisse%lysator.liu.se@localhost <nisse%lysator.liu.se@localhost>
Cc: galb-list%vandyke.com@localhost <galb-list%vandyke.com@localhost>; ietf-ssh%NetBSD.org@localhost <ietf-ssh%NetBSD.org@localhost>
Subject: Re: SHA-2 based HMAC algorithm...

nisse%lysator.liu.se@localhost (Niels =?iso-8859-1?Q?M=F6ller?=) writes:

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

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 agree that it's
overkill, but in pretty much every case where it's used, it's the output of a
PRF, and so key size doesn't really matter.

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

To quote someone on another list (possibly SAAG), SHA2-224 and -384 were
created by NIST to confuse the crypto-clueless.  They're barely supported and
have no real reason for existence, please don't use them.

Peter.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.