SHA3 HMAC key padding

Question

According to the pseudocode, keys longer than the block-size of the underlying hash function are shortened by hashing the key. Furthermore, keys shorter than the blocksize are zero-padded up the length of the block-size.

    if (length(key) > blocksize) {
        key = hash(key) // keys longer than blocksize are shortened
    }
    if (length(key) < blocksize) {
        // keys shorter than blocksize are zero-padded (where ∥ is concatenation)
        key = key ∥ [0x00 * (blocksize - length(key))] // Where * is repetition.
    }

Taking into account that the block-size of SHA3-512 is 72 bytes, and it's output is 64 bytes, does that mean the keys longer than 72 bytes should first be hashed and then the resulting 64 bytes should be zero-padded?

SHA3/keccak does not suffer from length extension attacks, padding is not necessary. — , Apr 23 '17 at 19:03
@dingrite nevertheless, if following the HMAC specification the padding must be performed — hunter, Apr 24 '17 at 09:17
@hunter HMAC isn't necessary with SHA-3; a secured keyed MAC called KMAC was standardized for SHA-3. KMAC is faster and simpler than HMAC, which was designed to protect older MD-style hashes from length extension attacks. See http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf — rmalayter, Apr 25 '17 at 16:58
@rmalayter yes, I've read this ... but I'm using HKDF, which dictates HMAC. — hunter, Apr 25 '17 at 18:49

score 3 · Answer 1 · answered Apr 25 '17 at 19:21

3

In lieu of any answers; I've compared my own implementation with the few test vectors I've been able to find (one of which can be found here) and it would appear that yes, keys longer than the block-size are hashed and zero-padded. It feels counter-intuitive to shorten a key and zero-pad it, but that's what the specification stipulates.

answered Apr 25 '17 at 19:21

hunter

3,965
6
28
42

1

You're building a non-standard construction using SHA-3 in HMAC; it will work fine and be secure. But why not just use the standardized KMAC with a customization string of "my key derivation" or whatever and the desired output length? This accomplishes exactly what HKDF does in a much simpler, cleaner, and standardized way. It's always nice to point to a NIST doc when the box-checking auditors visit. – rmalayter Apr 25 '17 at 21:42
@rmalayter sounds great - can you please point me towards a range of implementations and test vectors? – hunter Apr 26 '17 at 06:52
sure, right after you point me to all the implementations and test vectors for HKDF-SHA3-512. If you really have such concerns about interoperability just use a HKDF-SHA2 library and don't use SHA3 at all. – rmalayter Apr 26 '17 at 11:20
both HKDF and HMAC are simple, established and well-studied primitives. Neither of them dictates the use of any specific hash function. Implementations and test vectors for both are widely available. I really don't think swapping out SHA2 for SHA3 is an issue. When the KMAC construction has seen more crypto-analysis I would consider using it. I appreciate your feedback (and you're correct in everything you say) but my question was not really about which primitive to use. – hunter Apr 26 '17 at 11:36
you miss the point: nobody else is ever likely to use SHA3 with HKDF/HMAC, because they are unnecessary and from different "generations" of crypto. Implementing KMAC is just a few lines of code if you have a SHA3 implementation. Why do you want to use SHA3 (which is quite new) with old and unnecessary constructions like HMAC and HKDF? Keccak is a sponge function and therefore has no need for length extension protection (so HMAC is useless) and can already produce variable-length output (making HKDF useless) – rmalayter Apr 26 '17 at 11:48
if you do ukltimately chose to use KMAC, test vectors for KMAC from NIST can be found here (near the bottom): http://csrc.nist.gov/groups/ST/toolkit/examples.html, I also found sevral library implementations via google and GitHub search for "keccak kmac". Searching KMAC by itself turns up all sorts of things with that acronym that aren't related. – rmalayter Apr 26 '17 at 17:35
Yup, I had searched on github. Both this and this query return nothing (not to mention cSHAKE, which is also necessary). Thanks for the link to the test vectors though.. that's a start. – hunter Apr 26 '17 at 18:01
Github search stinks. This comes up via Google: https://www.google.com/search?q=keccak+kmac+site%3Agithub.com. If KMAC is supported by an implementation then cSHAKE is obviously included. – rmalayter Apr 26 '17 at 22:42
2

@rmalayter: I dispute your suggestion that HKDF-HMAC-SHA3 is a non-standard construction. FIPS 202 approves HMAC-SHA3 and specifies the block sizes (see top of p. 22); SP 800-56C approves of HKDF-HMAC-hash as a randomness extractor with any approved hash function. But in contrast, I can't find any NIST statement that explicitly approves the use of KMAC as a randomness extractor. – Luis Casillas Apr 27 '17 at 01:05
@LuisCasillas I'd never noticed that before; you're right SHA-3 is approved for use in HMAC. But that is still completely pointless construct, as HMAC only exists to cover up weaknesses in Merkle-Damgard hashes. Hence no implementations of HMAC-SHA3 in any well regarded crypto library. As for HMAC being an "approved randomness extractor", every secure hash function is a randomness extractor by definition. That's just a nonsense phrase, even if it appears in some RFC that is also designed do cover up a limitation of Merkle-Damgaard hashes (fixed output length). – rmalayter Apr 27 '17 at 01:18

SHA3 HMAC key padding

1 Answers1