7

$\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$

Ilmari Karonen
  • 46,700
  • 5
  • 112
  • 189
MCCCS
  • 731
  • 1
  • 7
  • 15

2 Answers2

10

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.

lyrically wicked
  • 1,379
  • 7
  • 11
5

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.

rmalayter
  • 2,297
  • 17
  • 24