2
$\begingroup$

I've asked before if some kind of canonical encoding should be used on the input parameters of SHA-3 before it could be used as replacement for HMAC.

However, if I read the current NIST specifications in NIST SP 800-185 correctly, there is no Keypack function defined. The Keypack function prefixed a key size to the key so that the key and message data are kept separate. Currently the key just seems to be zero-padded up to the next block boundary using the function bytepad(encode_string(K), 168) for KMAC128 and bytepad(encode_string(K), 136) for KMAC256.

Does that mean that there is no canonical encoding for key and data? Is it safe to use a dynamically sized key and data within KMAC so that bytepad(encode_string(K), 136) || X != bytepad(encode_string(K'), 136) || X' for K != K?

$\endgroup$
2
$\begingroup$

Yes, however it does take a deeper look into the standard.

KMAC128 is defined as:

  1. newX = bytepad(encode_string(K), 168) || X || right_encode(L).
  2. return cSHAKE128(newX, L, “KMAC”, S).

So there seem to be no encoding of the size of the key, which that there could be multiple K, M key message pairs that would result in an identical value of bytepad(encode_string(K), 168) || X (because A || BC = AB || C).

However if we take a look at the encode_string(S) function:

  1. Return left_encode(len(S)) || S.

This means that the (bit) string encoding canonically encodes the key including the size of the key (len(S)). That means that any key with a different size will be encoded in such a way that the division between key K and message X is clear.

The canonical encoding is still present even though the encode_string has a more generic name compared to earlier KMAC drafts where it was called Keypack(K, l) and took the length as explicit parameter.

$\endgroup$
2
  • 1
    $\begingroup$ Hmm, found the answer while creating the question, posted anyway, knowledge based style. The NIST notation is a bit of a compromise between text, pseudo-code and math if you ask me. $\endgroup$ – Maarten Bodewes Jan 13 at 12:16
  • $\begingroup$ We have come a long way. I would be surprised if NIST could have done such a mistake. $\endgroup$ – kelalaka Jan 13 at 22:38

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.