RE: SHA-2 based HMAC algorithm...

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

> -----Original Message-----
> From: Niels Möller [mailto:nisse%lysator.liu.se@localhost]
> Sent: Sunday, April 10, 2011 1:07 PM
>
> Dan Brown <dbrown%certicom.com@localhost> writes:

>
> > 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?
>
> To size must be specified. But using the hash block size (which I think
> is what you're suggesting) seem unnecessarily large. That would meen

You're right: what I said implies a block size key, which is larger than the hash size.  I perhaps intended hash size: I was wrongly thinking that the HMAC definition hashed any keys longer than the hash size.

This may be unnecessarily large, but it's not too costly to generate to generate a block length key pseudo-randomly.

> 512
> bits for hmac-sha1 (for which use in the ssh protocol is specified to
> use a 160 bit key), and 1024 bits for hmac-sha2-512, which I find
> totally out o fproportions. And the effective key size (i.e., the size
> of the internal state an attacker need to recover in order to form
> valid
> MACs) is limited to the digest size, or possibly twice the digest size,
> if I understand hmac correctly.

I don't quite understand your argument about the internal state.

I agree that a tag-guessing attack has success rate depending only on the tag size.  So, with respect a forging a single MAC, there seems to be no advantage to having a key larger than a MAC.

If the MAC key is re-used, then the situation is a little different.  As I understand HMAC, every block-sized should create a different MAC function because the outer hash (with opad). I'm not seeing the hash-length bottleneck of the internal state.

That all said, the way MACs are generally used is for immediate authentication.  So, in terms of the threat prevented, MACs are an algorithm of least concern.  By contrast, digital signatures and encryption sometimes need long-term protection to resist future attackers  (though I suppose MACs used in storage need long term protection), so an argument for larger key sizes may be useful in those cases.

Therefore, the minimum key size recommended for HMAC, the hash length, is probably fine.  Indeed, if one matches AES-128 with HMAC-SHA256, then the authentication key is already twice the size of the encryption key (which is backwards according to the prudent future-proofing argument above).



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