4

According to keccak strengths you have:

Unlike SHA-1 and SHA-2, Keccak does not have the length-extension weakness, hence does not need the HMAC nested construction. Instead, MAC computation can be performed by simply prepending the message with the key.

Meaning I can get a MAC of a message by just computing $\operatorname{SHA-3-256}(KEY \mathbin\| message)$. If this is the case, why then does $\operatorname{KMAC}$ exist?

Is $\operatorname{KMAC}$ the same as just $\operatorname{SHA-3-256}(KEY \mathbin\| message)$? If not, then how is using $\operatorname{KMAC}$ to generate an authentication tag different from computing $\operatorname{SHA-3-256}(KEY \mathbin\| message)$?

kelalaka
  • 49,797
  • 12
  • 123
  • 211
Finlay Weber
  • 504
  • 1
  • 3
  • 12

1 Answers1

5

Standard KMAC is more than that thanks to domain separation prefixes; NIST SP 800-185

KMAC128(K, X, L, S):

Validity Conditions: $\text{len}(K) < 2^{2040}$ and $0 \le L < 2^{2040}$ and $\text{len}(S) < 2^{2040}$

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

and

cSHAKE128(X, L, N, S):

Validity Conditions: $\text{len}(N) < 2^{2040}$ and $\text{len}(S) < 2^{2040}$

  1. If N = "" and S = "": return SHAKE128(X, L);
  2. Else: return KECCAK[256](bytepad(encode_string(N) || encode_string(S), 168) || X || 00, L)

and NIST FIPS 202

SHAKE128(M, d) = KECCAK[256] (M || 1111, d),


NIST's information about suffixes;

The suffix supports domain separation; i.e., it distinguishes the inputs to KECCAK[c] arising from the SHA-3 hash functions from the inputs arising from the SHA-3 XOFs defined in Sec. 6.2, as well as other domains that may be defined in the future.

I.e words, we have different random oracles per domain separation. SHA3 and Blake2 are more close to random oracles than SHA256 since they are free from the length-extension attack.

kelalaka
  • 49,797
  • 12
  • 123
  • 211