Is HMAC needed for a SHA-3 based MAC?

Question

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?

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. — CodesInChaos, Jun 17 '14 at 10:44
This question is pretty similar to Can Skein be used as a secure MAC in format H(k || m)? — CodesInChaos, Jun 17 '14 at 10:44
@CodesInChaos, that post seems to assume a Merkle–Damgård construction, whereas SHA-3/Keccak uses the sponge construction. Does it still apply? — otus, Jun 17 '14 at 11:48
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. — Cryptographeur, Jun 17 '14 at 11:56
@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. — Henrick Hellström, Jun 17 '14 at 12:52
Agreed, but I felt it was a useful question to link to - I certainly don't think it is a duplicate, just a related question. — Cryptographeur, Jun 17 '14 at 12:59
There are MAC schemes based on SHA-3 which don't do the nested hashing of HMAC, but please don't call them "HMAC". — Paŭlo Ebermann, Jun 18 '14 at 20:26

otus · Accepted Answer · 2017-08-03T14:07:48.947

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.

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. — Ninja_Coder, Aug 04 '17 at 07:57
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 (https://bench.cr.yp.to/results-hash.html#amd64-skylake). — Ruben De Smet, Jan 26 '18 at 18:22

Maarten Bodewes · Answer 2 · 2021-08-02T18:34:21.357

11

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).

edited Aug 02 '21 at 18:34

answered Jun 08 '16 at 16:20

Maarten Bodewes

92,551
13
161
313

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? – otus Jun 08 '16 at 17:52
@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. – Maarten Bodewes Jun 08 '16 at 21:18
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.) – otus Jun 09 '16 at 06:09
2

@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. – Maarten Bodewes Jun 09 '16 at 06:45

Is HMAC needed for a SHA-3 based MAC?

2 Answers2

Linked