- From: <bugzilla@jessica.w3.org>
- Date: Thu, 02 Oct 2014 22:05:34 +0000
- To: public-webcrypto@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26950 --- Comment #3 from Ryan Sleevi <sleevi@google.com> --- (In reply to Richard Barnes from comment #0) > Currently the HMAC Operations section for generateKey requires the default > key length to be equal to the block size of the underlying hash algorithm. > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#hmac- > operations > > RFC 2104, which defines HMAC, says that there's no point to having keys > longer than the *output* length of the hash (L): > """ > Keys longer than L bytes are acceptable but the extra > length would not significantly increase the function strength. > """ > http://tools.ietf.org/html/rfc2104#section-3 > > The block length is typically much larger than the output length. In the > case of SHA-256, for example, the block length is 512 bits. In order to > avoid wasting bytes, the default key length for WebCrypto should be the > output length of the hash. Can you describe what you mean by "wasting" bytes. The terminology implies a particular assumption about usage. Keys longer than B are compressed to L bytes (through an iteration of the hash), and keys less than L are dangerous. The choice of language was not accidental, and reflect the discussions within SP800-107 r1 (5.3.4 and 5.3.5). In these cases, the 'maximum' effective security strength for HMAC-SHA1/SHA-256/SHA-512 is 2C (where C = L, see the spec). If one generates a key of size L, it's effectively a key at half the length. The choice of using B, rather than L, was to generalize this across all constructions. Yes, there is limited value where B > 2C, but there is value with B > L, with all included hash functions having L <= C -- You are receiving this mail because: You are on the CC list for the bug.
Received on Thursday, 2 October 2014 22:05:35 UTC