# Does HMAC provide anything that AEAD does not?

Alice and Bob have to talk through Eve. (server to device through untrusted third party that relays messages, no TLS available)

Assume a secure key. Out of scope. Example, ECDH key exchange with HKDF.

Each payload has associated data. Time, version, type, etc. Data that is used to get a message to the correct function in Alice or Bob. The transport protocols have none of this in their designs.

Message authentication is important, so HMAC. Message payload encryption is sometimes important so at least occasionally AES-GCM128 on payload. Most of the time the payload data is not confidential. AES-GCM128 AEAD could cover both use cases.

Constrained device. Overhead for nonce, keyid, time, time are noticeable. Compiled size for both algorithms also a factor.

1. If I need to support AEAD sometimes, is it reasonable to just use AEAD all the time and skip HMAC entirely?

2. HMAC should be faster, but how much? I’ll need to test this, but suspect the difference might not be huge.

3. Is there an advantage to HMAC other than speed and being able to debug data that remains in clear text? Only other thing I know is smaller unpadded payload data.

4. Slightly aside, but does HMAC or AEAD benefit from including their nonces in the hashed / additional data? My replay attack prevention will mostly revolve around server time delivered to device on connection included in each message.

• associated data? Nov 17 '19 at 23:24
• @kelalaka Can't you run HMAC over associated data as well? Nov 17 '19 at 23:41
• Yes. Edited. Each message has some additional / associated data. Packaged in a serialized object that contains the payload as well. Signature/Has/Tag is one of these key pairs, and all messages use a common way to reassemble the data in the correct way for verification on the other end. H[Version, Type, Time, Payload], nonce currently outside of this. Nov 17 '19 at 23:42
• @jumpifnot0 Generally, AEAD is better simply because it's better integrated and usually faster. However, you're able to provide integrity of both ciphertext and associated data using just HMAC, just as you can with AEAD. This is assuming they can both be implemented correctly, of course. Nov 17 '19 at 23:45
• HMAC does not suffer from "sudden death" properties that many AEAD schemes suffer from, I would also suggest an encryption scheme that has nonce-misuse resistance, system times can me maliciously reset or modified, sometimes quite easily Nov 18 '19 at 4:16

If I need to support AEAD sometimes, is it reasonable to just use AEAD all the time and skip HMAC entirely?

Yes, and if you only need integrity / authenticity of the message then you can put all of the message in the Associated Data.

HMAC should be faster, but how much? I’ll need to test this, but suspect the difference might not be huge.

It won't be faster than GMAC generally, but if you include the CTR mode encryption then you may see a difference. This is too dependent on the system config to be able to answer this reasonably.

Some settings or openssl speed may help you with this. In my case AES-GCM was even faster than HMAC-MD5 which is normally quite fast - although the MD5 speed in OpenSSL isn't that great (but it's the only supported version of HMAC for the speed command, unfortunately). And SHA-256 may also have hardware acceleration. This is a muddy field...

Is there an advantage to HMAC other than speed and being able to debug data that remains in clear text? Only other thing I know is smaller unpadded payload data.

HMAC is a very sturdy algorithm that doesn't suddenly fail. AES-GCM may fail catastrophically if the authentication tag is too small or if the IV is repeated. I'd say that HMAC is less brittle than AES-GCM: the latter is secure, but it doesn't bend - it breaks.

Slightly aside, but does HMAC or AEAD benefit from including their nonces in the hashed / additional data? My replay attack prevention will mostly revolve around server time delivered to device on connection included in each message.

No. HMAC doesn't contain a nonce (although you may need a message specific nonce to avoid replay attacks). AES-GCM always includes the nonce automatically during the verification of the authentication tag, so adding it separately is useless.

• 4,5 GB / s on a single core, this CPU is nuts. Nov 18 '19 at 4:23
• You could also compare it with Poly1305, so you aren't tied to block ciphers with 128-bit blocks. Nov 18 '19 at 4:35
• @Maarten Bodewes “ if you only need integrity / authenticity of the message then you can put all of the message in the Associated Data”... fairly embarrassed to say I never considered this. I didn’t realize that AES-GMAC was GCM AEAD with a null encrypted payload length. Well yea! Makes no sense to also code in HMAC! I still need to process the rest of the reply, but thank you for your time! Found this in seconds crypto.stackexchange.com/questions/18164/… Nov 18 '19 at 7:58

Let's say you're talking about HMAC-SHA256, which is about the only reasonable use of HMAC other than HMAC-SHA512 these days. (For BLAKE2 or SHA-3, you don't need HMAC in the first place; there are native keyed versions.) How is HMAC-SHA256 different from AES-GMAC? (AES-GMAC is AES-GCM with an empty plaintext—the use case you're asking about, giving just an authentication tag.)

The crucial difference is that AES-GMAC requires you to specify a unique message number (nonce) every time you use it with the same key, while (say) HMAC-SHA256 does not.

If you use the same key for two messages with a repeated message number, the security of AES-GMAC totally collapses—it is only designed to be a nonce-based message authentication code. In contrast, HMAC-SHA256 is a good pseudorandom function family safe for more messages than you will ever have. A good PRF always makes a good MAC (without needing a nonce), but the converse is not true in general.

Actually HMAC-SHA256 is considerably more than a PRF: it's also collision-resistant, so it works, e.g., for hash commitments.

There's another important difference: AES-GMAC is either slow and full of timing side channels, or extremely slow, in software implementations, whereas HMAC-SHA256 is merely slow but not likely to have timing side channels. This is because AES and GHASH are both designed to be implemented most efficiently in software with secret-dependent table lookups, which are notoriously leaky. There is hardware acceleration for AES and GHASH, but it takes engineering work to ensure that you are reliably using it in your software stack—if it is available at all. On the other hand, if you have hardware AES and carryless multiplication, then AES-GMAC will blow HMAC-SHA256 out of the water.

If this is a constrained device, you might be interested in a single primitive that does everything like Keccak in STROBE or Gimli in libhydrogen. (Do you really want HMAC in particular, or are you just looking for a message authentication code? HMAC is just one way to construct a PRF out of SHA-256.)

1. If I need to support AEAD sometimes, is it reasonable to just use AEAD all the time and skip HMAC entirely?

If you only need to detect forgery, and you can assign a unique number to each message, yes. In a sequential conversation, the number of messages you have sent so far is always a good choice—it has the side benefit that you can cheaply reject replays this way. But if you're not in a setting where that makes sense, you might be better off with HMAC-SHA256.

1. HMAC should be faster, but how much? I’ll need to test this, but suspect the difference might not be huge.

Why do you think HMAC should be faster?

Here are three relevant points:

• Collision resistance—as SHA-256 provides—is generally quite expensive, but if you only need to detect forgery, there's no need for collision resistance. On some platforms SHA-512 is faster than SHA-256, but it still has to pay for collision resistance.

• AES-GMAC cost will be dominated by computing GHASH, which means evaluating a message-length polynomial over $$\operatorname{GF}(2^{128})$$. In software implementations (without hardware carryless multiplication):

• Table-based implementations are likely to have timing side channel attacks.
• Constant-time implementations (without side channel attacks) are likely to be quite slow.
• With hardware carryless multiplication, GHASH is extremely fast because you can vectorize the evaluation of a polynomial to an arbitrary degree to maximize utilization of your CPU's vector unit. Only other universal hashes like Poly1305 are competitive—SHA-256 doesn't stand a chance. For example, on my laptop, using openssl speed -evp aes-256-gcm sha256, I get about 3.5 GB/sec for AES-256-GCM (AES-GCM is basically AES-GMAC + AES-CTR), but 450 MB/sec for SHA-256—about 8x difference in favor of AES-GCM.

So AES-GMAC might be a lot faster or a lot slower than HMAC-SHA256 depending on what hardware you run it on.

For a little more consistency across platforms—including more consistent resistance to timing side channels—I would recommend Poly1305 over GHASH, e.g. by using NaCl/libsodium.

1. Is there an advantage to HMAC other than speed and being able to debug data that remains in clear text? Only other thing I know is smaller unpadded payload data.

HMAC-SHA256 does not require you to choose a unique number for each message. HMAC works for more applications. HMAC-SHA256 works for more applications than just message authentication codes, like commitments.

1. Slightly aside, but does HMAC or AEAD benefit from including their nonces in the hashed / additional data? My replay attack prevention will mostly revolve around server time delivered to device on connection included in each message.

A nonce is not merely a benefit for AES-GMAC but absolutely mandatory, and server time does not inspire confidence that it will be unique.

Using a sequential nonce with HMAC-SHA256 even though it is not necessary for HMAC-SHA256's security contract enables you to reject replayed messages, and raises the difficulty of forgery attempts because they have to keep in sync with your sequence numbers.