26
$\begingroup$

HMAC does nested hashing in order to prevent Length Extension Attacks.

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC?

Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC?

Improve this question
$\endgroup$
7
  • 4
    $\begingroup$ Use the key as prefix not as suffix. Key as suffix is secure as well as long as SHA-3 remains unbroken, but falls once a collision attack is found. If you don't care about the performance cost, still using HMAC is a good choice as well. $\endgroup$
    – CodesInChaos
    Commented Jun 17, 2014 at 10:44
  • 2
    $\begingroup$ This question is pretty similar to Can Skein be used as a secure MAC in format H(k || m)? $\endgroup$
    – CodesInChaos
    Commented Jun 17, 2014 at 10:44
  • 1
    $\begingroup$ @CodesInChaos, that post seems to assume a Merkle–Damgård construction, whereas SHA-3/Keccak uses the sponge construction. Does it still apply? $\endgroup$
    – otus
    Commented Jun 17, 2014 at 11:48
  • 1
    $\begingroup$ This question is arguably closer, but not really a duplicate (I retracted my vote) because it asks whether HMAC-SHA3 is provably secure rather than whether there are smaller schemes that work. Have a look at the dedicated Keccak MAC functions (for example as part of their AE schemes), including the Keyed Sponge functions. $\endgroup$
    – Cryptographeur
    Commented Jun 17, 2014 at 11:56
  • $\begingroup$ @figlesquidge Security is a relative notion. The question you link to in your comment, as well as the accepted answer to that question, explains in detail to what extent HMAC-SHA3 would be more secure than using in SHA3 in its built in MAC mode. $\endgroup$
    – Henrick Hellström
    Commented Jun 17, 2014 at 12:52

2 Answers 2

Reset to default
28
$\begingroup$

Given that you use the SHA-3 hash (which is resistant against length extension attacks), would you still need to go through that procedure in order to produce a secure MAC?

No, you don't need to do that, but you can.

Needless to say we'd still use a key, which we prepend or append to the message, but is that sufficient for a MAC?

Yes, you can prepend the message with the key, i.e. use $H(K||M)$.

Quoting the Keccak (SHA3) website:

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.

However, the original standard does not specify this MAC mode, only a hash function.

There is now a specification (pdf) of KMAC (and other constructions) based on SHA-3, or specifically the SHAKE extendable output functions. The changes from "prepend key to message" are key padding as well as the inclusion of constants and the output length, which are all done for domain separation.

It is possible to implement KMAC in this form using SHAKE128/SHAKE256 but not using the other SHA-3 variants.

Improve this answer
$\endgroup$
2
  • 2
    $\begingroup$ I would also like to note, that using MAC with SHA-3 is actually preferable to using an HMAC, because an HMAC will effectively be needlessly doubling the computation time of the authentication code. $\endgroup$
    – Ninja_Coder
    Commented Aug 4, 2017 at 7:57
  • $\begingroup$ Ninja_Coder, do you have the numbers to prove this performance claim? It sounds logical, but a single SHA3 is still quite a bit slower than a single SHA2 (bench.cr.yp.to/results-hash.html#amd64-skylake). $\endgroup$
    – Ruben De Smet
    Commented Jan 26, 2018 at 18:22
11
$\begingroup$

KMAC has now been specified in NIST SP 800-185, chapter 4. It is based on cSHAKE128 and cSHAKE256, which both are based on the same Keccak sponge that SHA-3 is. It doesn't use any additional methods to protect against length extension as HMAC does.

Some additional construction on top of the hash is still required to make sure that there are no unfortunate collisions with previously hashed data or - more importantly - key / message pairs. Otherwise it could be that $H(K_1,M_1) = H(K_2,M_2)$ in case $K_1 | M_1 = K_2 | M_2$. This happens if $K_1 = A | X$, $M_1 = B$ and $K_2 = A$ while $M_2 = X | B$ as both would result in $H(A | X | B)$. The $|$ operator is concatenation of course.

So HMAC is indeed unnecessary, but some kind of MAC construction is still needed to keep the key and message apart (unless a fixed key size is used anyway).

Improve this answer
$\endgroup$
4
  • $\begingroup$ Isn't the problem fairly theoretical? As long as your key is 128+ bits and randomly chosen, chances are no one's ever hashed a message starting with it anyway. (Or if someone has, it's about the same chance as someone sharing your MAC key, which is an argument for 256-bit keys.) Or is it about a better security proof? $\endgroup$
    – otus
    Commented Jun 8, 2016 at 17:52
  • $\begingroup$ @otus I'd guess mainly the latter. OTOH just prefixing a single byte with the length of the key in bytes isn't that much of an issue either. For a high security construct such as Keccak I'd probably choose a 256 bit key, yes. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 8, 2016 at 21:18
  • $\begingroup$ Based on this, which is newer than other KMAC stuff I can find, it seems like the plan is full domain separation so that KMAC cannot be computed with SHA-3 alone. (Presumably some SHA-3 constants or parameters will change for KMAC.) $\endgroup$
    – otus
    Commented Jun 9, 2016 at 6:09
  • 2
    $\begingroup$ @otus Yep, that's the general idea. They are just two bits, in 2.1 and 6 of the SHA-3 spec. This escaped my attention; I've got no clue why they are just using two bits; a full byte would make more sense. I'll call this bit-angst I suppose. Anyway, you can still extend the two bits for value 11 of course. Sometimes I forget that cryptographers are not always that practical. $\endgroup$
    – Maarten Bodewes ♦
    Commented Jun 9, 2016 at 6:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.