0

KMAC128 is defined as:

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

The definition of bytepad() is as follows: bytepad(X, w):

Validity Conditions: w > 0  
1. z = left_encode(w) || X. 
2. while len(z) mod 8 ≠ 0: 
z = z || 0 
3. while (len(z)/8) mod w ≠ 0: 
z = z || 00000000 
4. return z.

I couldn't find any stipulation about the maximum length of the key anywhere And according to the definition of bytepad it won't cut the key by 168 bytes, but will make it a multiple (mod) of 168 bytes. That is, if the key is longer, it will complement it to a value multiple of 168 byte

In this case,

z = left_encode(w) || X.

not the length as a whole will go to the beginning, but only a multiple value

I don't understand and don't know where to find out whether we should limit the key by length, what can be used as a guide

keccak view as

KMAC128(K, X, L, S) = KECCAK[256]( (“KMAC” || S, 168) || (K, 168) || X || right_encode L || 00, L)
Aleister'Andrew Luci'Luzhin
  • 1
  • 1

2 Answers2

0

until it is a byte string whose length in bytes is a multiple of w.

thus, the standard clearly specifies what the result should be, although it does not specify what the key for kmac should be.

If we go beyond the standard using the keccak functionality, we can assume a new function for a key of any length and similar text

newX = Big_Key || X
cSHAKE128( newX, L, "", "custom function").
KECCAK[256](  ( "" || "custom function", 168)  Big_Key || X || 00, L)

It still makes sense to add an addition to the standard about how long the key should be.

These documents state everything, but apparently the length of the keys is a separate issue.

NIST Special Publication 800-185 SHA-3 Derived Functions: nist.sp.800-185.pdf

SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions: nist.fips.202.pdf

Aleister'Andrew Luci'Luzhin
  • 1
  • 1
0

I couldn't find any stipulation about the maximum length of the key anywhere

Such a standard wouldn't really make sense. Keccak, and sponge functions generally, are well studied as it pertains to keying methodologies. The security degradation from key lengths which extend over multiple blocks (invocations of the permutation $\pi$) is negligible in relation to the inherent increased possibility space that comes from adding more highly entropic key material. And as the Keccak team's analysis explains:

"a fixed-length permutation makes no distinction between data and key input and hence can treat all input bits on an equal footing and at the same time can be made simpler."

The simplicity here is due to its flexibility. If Keccak can take an arbitrary amount of data, and key material and data can be treated on equal footing, than so too can it take an arbitrary amount of key material. What KMAC does is specify how to do proper canonicalization of inputs, and domain separation between key and data sections by padding them into distinct blocks.

Intuitively, padding the key into distinct prior blocks from the data, and thus beginning the absorbsion of data with an entire freshly permuted state, more closely resembles the ideal of the key "choosing" a hash function uniformly at random. This is preferrable to letting implementations arbitrarily align the key-data transition boundary to somewhere in the middle of an arbitrary block.

aiootp
  • 1,182
  • 4
  • 11