3
$\begingroup$

I'm looking at three options for shared-secret message authentication codes:

  1. HMAC-SHA-256(secret, payload)
  2. SHA-512/256(secret+payload)
  3. SHA-512(secret+payload) truncated to 256 bits

Option 1 is the most standard choice. I'm considering option 2 because it is faster on 64-bit CPUs. I'm considering option 3 because SHA-512 is more widely available in programming language libraries than SHA-512/256.

Are options 2 and 3 appropriate for MACs? Are there any security-related reasons to pick one over the other?

Clarification: I realize that a good HMAC-SHA-256 implementation is not significantly slower than SHA-256. I'm considering options 2 and 3 because SHA-512 is faster than SHA-256 on 64-bit machines (link).

Background: Some cryptographic hash functions (like SHA-256 and SHA-512) are "length-extendable". This is not necessarily a problem because correct uses of a hash function should not be affected by that property. But you can't use such a hash function directly as a MAC because, in that use case, the signature and input both come from an untrusted source (length extension attack).

SHA-512/256 is a hash function based on SHA-512 that is not length-extendable. (It's similar to running SHA-512 and only using the first 256 bits of output, which is also not length-extendable.) My question was whether these two hash functions could be directly used as MACs.

$\endgroup$
  • $\begingroup$ Finding a difference between those hash functions, all of equal digest bit lenght might impy an implementation problem, with no implementation issue, would mean the math might be a problem $\endgroup$ – Q-Club Jun 13 '18 at 1:29
3
$\begingroup$

Option 2 and 3 are appropriate for a MAC, assuming the length of the key is not variable (otherwise appropriate padding must be used, similar to that used in KMAC). In this manner, it behaves like SHA-3 which does not need to be run in the usual nested HMAC construction. Numbers 2 and 3 are actually virtually identical. The only difference is that SHA-512/256 uses a different IV than plain truncated SHA-512. They all provide protection against length extension attacks.

Note that you can optimize HMAC to reduce the number of calls to the hash. Any decent implementation will not have significantly impaired performance compared to HMAC-SHA-256. You can also get away with only executing a single SHA-256 function using an older construction called an envelope MAC which concatenates the key, message, and key again, with padding.

$\endgroup$
  • $\begingroup$ Good answer. Just don't take away from it that the number of times a hash function is used necessarily matters. The number of blocks processed (including padding) determines performance. $\endgroup$ – Future Security Jun 13 '18 at 4:04
  • $\begingroup$ Please include the reason why they are impervious to length extension attacks (before some noob creates a protocol that is vulnerable). Maybe you meant: "... not have significantly impaired performance compared to SHA-256."? Something about speed of SHA-512 on 32 / 64 bit machines and long / short messages may be in order as well. 🦉 $\endgroup$ – Maarten - reinstate Monica Jun 13 '18 at 14:10
  • $\begingroup$ In this context, what does it mean for the key to be variable-length? For any particular use of a MAC, the key is a fixed string, right? Is there something I have to be careful with when rotating keys? $\endgroup$ – Kannan Goundan Jun 13 '18 at 22:30
  • $\begingroup$ @KannanGoundan The key should be a fixed string, yes. That's what I meant. If it is variable length, it must be appropriately padded. The problem is that these functions take the key as a string, so unlike a symmetric cipher, you can't force it to use only one key length. $\endgroup$ – forest Jun 14 '18 at 2:27
  • $\begingroup$ @KannanGoundan It means not-fixed-length. If you use a KDF or key generator algorithm that can only output keys of one length, then it's not a concern because your keys are indeed a fixed length. The key itself can still be replaced with a new key that is the same size. $\endgroup$ – Future Security Jun 14 '18 at 2:31

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.