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.

Improve this question
$\endgroup$
0

1 Answer 1

Reset to default
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.

Improve this answer
$\endgroup$
12
  • $\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, 2018 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 Bodewes ♦
    Jun 13, 2018 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, 2018 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, 2018 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, 2018 at 2:31

Your Answer

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

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