4
$\begingroup$

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

$\endgroup$
5
$\begingroup$

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.

$\endgroup$
6
  • $\begingroup$ The other functions (Keccak and Sponge) can be seen here $\endgroup$
    – kelalaka
    Oct 22 at 15:22
  • $\begingroup$ By "domain separation prefixes" you refer to the customizable string that cSHAKE takes? $\endgroup$ Oct 22 at 15:24
  • 1
    $\begingroup$ Exactly, With the domain seperation the core of the hash function can behave like different random oracles. $\endgroup$
    – kelalaka
    Oct 22 at 15:27
  • $\begingroup$ By custom mean, they are fixed by NIST during the standardization. I've inserted the correct cSHAKE128, there are also, 256 versions, too. $\endgroup$
    – kelalaka
    Oct 22 at 15:32
  • $\begingroup$ 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)? $\endgroup$ Oct 22 at 15:35

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.