There are a few posts that I've come across that seem to imply that using regular encryption and a MAC might be better than using the newer AEAD (ie: AES/GCM) modes.



My questions are thus:

Is an AEAD more likely to fail (being subject to chosen plaintext attacks, versus HMAC protecting the encrypted part more securely), and if so, does it fail in a more catastrophic way?

Assuming that you have securely generated both the HMAC and encryption keys, is Encrypt+HMAC therefore more secure?

  • 1
    $\begingroup$ The properties of universal hashing based authentication in modes like GCM is pretty similar to the properties of CTR mode encryption: It's strong when used correctly, but if you ever reuse a (Key, Nonce) pair, it fails catastrophically. HMAC doesn't need a nonce. $\endgroup$ Jan 22 '13 at 19:55
  • $\begingroup$ Personally I prefer HMAC when using long term keys, and universal hashing when using session keys (with a counter as nonce). $\endgroup$ Jan 22 '13 at 19:59
  • $\begingroup$ Note that the combination of Encrypt + HMAC can be seen as an EAED scheme. $\endgroup$ Jan 23 '13 at 9:38
  • $\begingroup$ @CodesInChaos A universal hash function can be designed so that nonce reuse doesn't lead to catastrophic failure, can it not? $\endgroup$
    – Melab
    Jan 3 '18 at 2:53

This is something I tend to disagree somewhat with Colin Percival on.

You should use Encrypt-then-HMAC if and only if you can get it right. The biggest pitfall is using a short-circuiting string comparison versus a constant-time string comparison. Given the former, people can use timing attacks to forge valid HMACs for arbitrary ciphertexts. With an encryption mode like CBC, this could be used to read the contents of encrypted messages. Other pitfalls include accidentally implementing Encrypt-and-MAC or MAC-then-encrypt, which have historically had vulnerabilities related to their construction.

On the other hand, EAX and GCM modes provide this feature transparently. There are some concerns about potential side-channel attacks against dedicated AEAD modes, and there is also the conceptual issue of potentially passing unauthenticated packets to your decryption algorithm. You, of course, have to get details like unique IVs correct, but you also have this requirement for Encrypt-then-MAC.

That said, potential flaws in EAX and GCM implementations can be fixed for many people at once with patches to the relevant libraries. Flaws where non-cryptographers naïvely compare HMACs are epidemic, and even high-profile projects like Google's KeyCzar have made this simple mistake. If you absolutely know what you're doing, Encrypt-then-HMAC is a provably secure construct. If you don't know what you're doing, something like EAX or GCM may be found to have weaknesses, but they are assuredly better than implementing something yourself.

Edit: I may have made Encrypt-then-HMAC sound easier than it actually is. One other major pitfall of Encrypt-then-HMAC is not HMACing enough information, or not HMACing the information correctly. The HMAC must include the ciphertext, the additional authentication data, and the initialization vector. It probably must also (perhaps someone else can confirm or deny this) include a descriptor to identify the encryption algorithm used. To pass these fields into the HMAC, you must use a format that unambiguously delineates fields. The easiest way to do this is to prepend a 4-byte big-endian length before any variable-length field (usually just authentication data and ciphertext), but doing this for all fields is probably a good idea. If you don't HMAC all this information, an attacker can modify any of the data not included. If you don't HMAC them unambiguously, an attacker can manipulate message boundaries, which could allow him to conduct an exploit.

Edit 2: Another detail of Encrypt-then-HMAC I've forgotten. Hopefully you can see how hard this is to get right. Ideally, you should never reuse the same key across security contexts. I'm unaware of any attacks that would result from using your encryption key as the key for the HMAC, but best practice is to use a different key for encryption and authentication. One simple approach (assuming a 256-bit encryption algorithm and 256-bit HMAC) is to use a "virtual" 512-bit key. Use the first half for encryption and the last half for authentication. Another approach is to use a 256-bit key, but pass it through HKDF with a 512-bit output; use this as before: split it into two parts, use one for encryption and one for authentication.

Edit 3: I asked a highly relevant question on the security StackExchange a few months ago. Thomas Pornin's detailed answer may be helpful.

  • $\begingroup$ What I'm missing from this answer is the part that the protocol plays in all this. There are plenty protocols where a single incorrect MAC would stop the protocol, delete the session keys and then require re-authentication. It's rather tricky to retrieve side channel information that way. You need some kind of oracle for this to be practical. $\endgroup$
    – Maarten Bodewes
    Aug 1 '14 at 13:48
  • $\begingroup$ Same of course for challenge response protocols, if the challenge is indeed random, then side channel attacks won't be much help. $\endgroup$
    – Maarten Bodewes
    Aug 1 '14 at 13:50

I think this question splits into two parts, the one is about AEAD in principle vs. Encrypt+HMAC, the other about AES-GCM.

As far as I know, Galois counter mode may have some weaknesses in the checksum, which might reduce its strength, and a well-known limitation to transfer size (64GB) before you definitely should renegotiate; read this paper for more information: http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/CWC-GCM/Ferguson2.pdf

I also recall reading a paper comparing the galois field MAC computation with poly1305 from DJB, pointing out that the prime modulus (2^130-5) has significantly better properties. That's not bad enough for practical attacks, though.

These weaknesses are related to the particular AEAD encryption scheme AES-GCM; others are more secure. Examples of AEAD cipher suites which are considered more secure than AES-GCM are ChaCha20+Poly1305 from DJB, and Keccak in duplex mode.

The general picture however is really that AEAD is much, much easier to get right as mere user of a cryptographic library than Encrypt+HMAC. That does not mean that they have to be technically different from Encrypt+HMAC, just that you use a library where both the encryption and the HMAC is combined, like e.g. ChaCha20+Poly1305. Technically, ChaCha20 is just a stream cipher without authentication, and Poly1305 is just authentication. On the other hand, Keccak in duplex mode is really computing both authentication and encryption with the same operation, so it's integrated by design.

  • $\begingroup$ What weaknesses does GCM have "in its checksum"? $\endgroup$
    – forest
    Sep 9 '19 at 7:10

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.