Can you use a dynamic key and data size for KMAC?

Question

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?

Answer 1

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.