3

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.

Kannan Goundan
  • 331
  • 3
  • 10

1 Answers1

3

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.

forest
  • 15,253
  • 2
  • 48
  • 103
  • 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. – Future Security Jun 13 '18 at 04:04
  • 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. – Maarten Bodewes Jun 13 '18 at 14:10
  • 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? – Kannan Goundan Jun 13 '18 at 22:30
  • @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. – forest Jun 14 '18 at 02:27
  • @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. – Future Security Jun 14 '18 at 02:31
  • I'm trying to understand how a variable-length key situation would come up. Is it when the verifier checks a single MAC against multiple different-length keys? Does the problem go away if the MAC is prefixed with the version of the key being used, so the verifier only ever check a given MAC against a single key? – Kannan Goundan Jun 15 '18 at 18:18
  • @KannanGoundan Unless the implementation is broken, you won't be using a variable-length key. – forest Jun 15 '18 at 18:19
  • @forest: Just out of curiosity, what does it even mean to have a variable-length key for a MAC based on truncated SHA-512? What does that code look like? – Kannan Goundan Jun 15 '18 at 19:24
  • @KannanGoundan For an HMAC, if the key were variable length, it would violate the HMAC specifications. It matters for the other MACs. For $\operatorname{SHA-512/256}(k \mathbin| m)$, $k$ must be fixed-length. – forest Jun 15 '18 at 19:26
  • @forest: But how can the key even be variable length? For example, what does the code look like for an (insecure) MAC verifier that uses a variable-length key. – Kannan Goundan Jun 17 '18 at 21:45
  • @forest The key length for HMAC is not fixed by the specification. From RFC 2104: “The authentication key K can be of any length up to B, the block length of the hash function”. The block length of SHA-256 is 512 bits. – rmalayter Jun 20 '18 at 02:04
  • @rmalayter Oh I wasn't aware of that. Thanks for pointing that out! – forest Jun 20 '18 at 02:05