2
$\begingroup$

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?

$\endgroup$
  • 1
    $\begingroup$ SHA3/keccak does not suffer from length extension attacks, padding is not necessary. $\endgroup$ – user10653 Apr 23 '17 at 19:03
  • 2
    $\begingroup$ @dingrite nevertheless, if following the HMAC specification the padding must be performed $\endgroup$ – hunter Apr 24 '17 at 9:17
  • $\begingroup$ @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 nvlpubs.nist.gov/nistpubs/SpecialPublications/… $\endgroup$ – rmalayter Apr 25 '17 at 16:58
  • $\begingroup$ @rmalayter yes, I've read this ... but I'm using HKDF, which dictates HMAC. $\endgroup$ – hunter Apr 25 '17 at 18:49
3
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ 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. $\endgroup$ – rmalayter Apr 25 '17 at 21:42
  • $\begingroup$ @rmalayter sounds great - can you please point me towards a range of implementations and test vectors? $\endgroup$ – hunter Apr 26 '17 at 6:52
  • $\begingroup$ 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. $\endgroup$ – rmalayter Apr 26 '17 at 11:20
  • $\begingroup$ 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. $\endgroup$ – hunter Apr 26 '17 at 11:36
  • 2
    $\begingroup$ @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. $\endgroup$ – Luis Casillas Apr 27 '17 at 1:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.