Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
2  
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
2  
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
1  
@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
1  
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. – figlesquidge 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
up vote 10 down vote accepted

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 standard does not specify this MAC mode, only a hash function. So using HMAC-SHA-3 would be the more conservative choice if you wanted to use only standardized primitives.

share|improve this answer

There is work underway to specify KMAC. It's basically just SHA-3, but with a length specification for the key and a special value to indicate that this is KMAC instead of hashing.

These constructions are required to make sure that there are no unfortunate collisions with previously hashed data or - more importantly - key / message pairs where $H(K_1,M_1) = H(K_2,M_2)$ in case $K_1 | M_1 = K_2 | M_2$. This could happen 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 (unless you fix the key size yourself anyway).

share|improve this answer
    
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 8 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 8 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 9 at 6:09
1  
@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 9 at 6:45

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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