3
$\begingroup$

RFC 2104 says:

Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t [...]. We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be predicted by an attacker).

Obviously, different lengths of HMAC outputs provide different levels of security. What's not obvious to me, is: If one needs the security provided by a 128-bit MAC, why is HMAC-SHA-256 suitable to generate such (half the length of the hash = 128 bits) but HMAC-SHA-512 is not (half the length of the hash = 256 bits)?

Improve this question
$\endgroup$
3
$\begingroup$

HMAC doesn't suffer the issue with collision resistance (in other words: the birthday bound does not apply). This is simply because an attacker doesn't have the secret key used to generate the HMAC authentication tag, so there is no way to build a huge table of possible outputs that can be compared against.

So usually the security of a hash is defined as half the number of output bits because of the birthday bound. To get the same level of security you can therefore output half of the output bits of HMAC because the birthday attacks do not apply.

You can use HMAC-SHA-512 to generate 128 bits of security by using the leftmost 128 bits (and it may even be slightly faster than HMAC-SHA-256 for large messages on a 64 bit CPU). However, it won't deliver the maximum security that can be provided by HMAC-SHA-512 - not that you would ever need 512 bits of security.

Note that the 80 bit security is half the output size of SHA-1 (or RIPEMD-160 for that matter). Nowadays 80 bits is not considered (all that) secure anymore.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for the quick answer. I'm still a bit confused. If truncating HMAC-SHA-512 to 128 bits generates 128 bits of security, then truncating HMAC-SHA-512 to 256 bits generates 256 bits of security -- which is the 256 bits of security that SHA-512 promises, right? Why is it useful to have a HMAC algorithm that provides the 512 bits of security promised by a 1024-bit hash function? I think I'm missing something... $\endgroup$ – user42529 Jan 2 '17 at 15:51
  • $\begingroup$ 1. Right. 2. That isn't useful; 512 bits of effective security strength isn't that helpful in general. Generally the security should be between 128 and 256 bits. Higher amounts are nonsense; 256 bits of security is completely infeasible to break computationally - if anything breaks it is the algorithm itself. That's why there is no SHA-2-1024 specified even if it is perfectly feasible to create such a construction. So basically, determine your minimum security strength of the protocol and use that or more - as output size. If you've got room for it, why not use the full output size? $\endgroup$ – Maarten Bodewes♦ Jan 2 '17 at 15:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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