This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
From Jeff Walton: "Another reason this could cause problems is SHA3. Its a recursive hash function, and not an iterative hash with block size."
I think this is just a mistake and it should indeed be the output length.
(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
Closing as per conf call discussion.