# Security difference between $\mathrm{Keccak}(k\mathbin\|x)$ and $\mathrm{Keccak}(x\mathbin\|k)$

$\require{begingroup}\begingroup \DeclareMathOperator{\keccak}{\mathrm{Keccak}} \DeclareMathOperator{\concat}{\|}$According to Keccak's website, $\keccak(k \concat x)$ is safe:

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.

My question is, is $\keccak(x \concat k)$ safe?

I read Why is $H(k\mathbin\Vert x)$ not a secure MAC construction? but I guess it doesn't apply to Keccak. $\endgroup$

See chapter 5.11.2 of the paper “Cryptographic sponge functions” (the link can be found here):

Note that one can also define a MAC function by taking as input the message followed by the key: $t = \left\lfloor {F(M \mathbin\Vert K)} \right\rfloor _n$. In this case, an adversary has the advantage that she can try to generate inner collisions offline, i.e., without having to query the keyed sponge function. Additionally, she can try to construct a path to a state that occurs in the absorbing of a target message, leading to a second message with the same MAC.

• For an offline attack you would need to create a collision on the full 1600 bit internal state, a rather tall order. in case finding sha3 collision wasn't hard enough. Jul 31 '18 at 4:22
• @MeirMaor: But $\text{Keccak-}f[b]$ permutations are defined for all $b \in \{25, 50, 100, 200, 400, 800, 1600\}$, thus the full internal state is not required to be always equal to 1600 bits. Jul 31 '18 at 4:43
• SHA-3 only uses $b = 1600$, so Meir Maor's statement is about SHA-3, but the question was about Keccak in general. But if I understand the quote right, an inner collision is a collision in the capacity section of the sponge state, which I believe is sufficient to construct a full state collision (top of p. 17 for the linked paper on sponge functions). Jul 31 '18 at 17:15

Keccak(x||k) is very likely secure, but it is less efficient than Keccak(k||x) for multiple messages.

The standardized MAC construction for use with Keccak is KMAC as defined in FIPS 800-185. In KMAC, you first absorb the key padded to the rate length of the sponge. You can then copy the resulting Keccak state, and re-use it for all messages which will use the same MAC key.

With KMAC you don’t need to re-absorb the same key repeatedly for each message. This can make a significant performance benefit for MAC of many small messages (such as VPN packets).

In short: use KMAC.