# Is KMAC just SHA-3-256(KEY || message)

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)$$?

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)

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.

• The other functions (Keccak and Sponge) can be seen here Oct 22 at 15:22
• By "domain separation prefixes" you refer to the customizable string that cSHAKE takes? Oct 22 at 15:24
• Exactly, With the domain seperation the core of the hash function can behave like different random oracles. Oct 22 at 15:27
• By custom mean, they are fixed by NIST during the standardization. I've inserted the correct cSHAKE128, there are also, 256 versions, too. Oct 22 at 15:32
• Ok...Thanks! I am slowly digesting this. What comes next to mind is: if this custom string is actually fixed by NIST, what is the advantage of using KMAC vs just manually doing SHA-3-256(KEY || message)? Oct 22 at 15:35