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?

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

1 Answer 1

Reset to default
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.

Improve this answer
$\endgroup$
10
  • 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
    Commented Apr 25, 2017 at 21:42
  • $\begingroup$ @rmalayter sounds great - can you please point me towards a range of implementations and test vectors? $\endgroup$
    – hunter
    Commented Apr 26, 2017 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
    Commented Apr 26, 2017 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
    Commented Apr 26, 2017 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
    Commented Apr 27, 2017 at 1:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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