What's the opinion on using an AEAD cipher such as AES-GCM for example as a pure message authentication code (MAC) when only message authentication but not encryption is required.

  • does it bring any benefits?
  • does it have any obvious disadvantages?
  • does it have any security implications?
  • 1
    $\begingroup$ For GCM, it's called GMAC $\endgroup$
    – poncho
    Commented Mar 3, 2020 at 16:41
  • $\begingroup$ This is a broad question. Could you be more specific? There are tons of MACs.... $\endgroup$
    – kelalaka
    Commented Mar 3, 2020 at 16:45
  • $\begingroup$ related crypto.stackexchange.com/questions/10775/… $\endgroup$ Commented Mar 4, 2020 at 1:38

2 Answers 2


does it bring any benefits?

Yes, it could. It is likely that e.g. GCM is sped up more than e.g. HMAC. GMAC - the underlying MAC - is using faster operations than HMAC as well, and GMAC is unlikely to be present as MAC in most runtimes. Besides that, it would also require a 128 bit block cipher, so you'd basically have everything you need for an AEAD cipher again.

does it have any obvious disadvantages?

It could wrong-foot casual readers of the protocol or code. Suddenly they are presented with a cipher rather than a MAC, and that might lead to incorrect conclusions.

It may also well be that there is an additional overhead to take care of verifying a nonce and ciphertext. Although that's a constant overhead that is not related to message size, it may still be significant for small messages.

does it have any security implications?

Depends on the MAC used and the MAC that it is compared against (and configuration, usage scenario etc.).

EAX mode is an AEAD cipher that uses CMAC for all MAC calculations. It is very likely to be as secure as using CMAC directly.

GMAC security on the other hand is more dependent on the size of the authentication tag compared to e.g. HMAC. It has a substantially lower limits for message count, message size, total message size compared to an algorithm such as HMAC configured with a SHA-2 hash.

Furthermore, a MAC as GMAC or CMAC is limited to 128 bits while e.g. HMAC can output 256 bits or 512 bits. Not that you're likely to ever need that amount of security for a MAC, but it can weigh in none-the-less.

Key reuse for two ciphers can negate all security and even lead to leaking the MAC key, something that is less likely an issue for a cipher + HMAC.

  • 1
    $\begingroup$ also for disadvantages, GCM has substantially lower message count, message size, and total data processed limits compared to something like HMAC-SHA512 $\endgroup$ Commented Mar 4, 2020 at 1:39
  • $\begingroup$ Good point, amended. $\endgroup$
    – Maarten Bodewes
    Commented Mar 4, 2020 at 1:42
  • $\begingroup$ Is GMAC really faster than HMAC? I've actually observed the opposite to be true for must of my use-cases. Of course GMAC could be sped up a lot as it supports parallel processing but considering that you have one hardware accelerator for SHA256 for example and one accelerator for raw AES-ECB, HMAC would outperform GMAC by multiple factors. $\endgroup$ Commented Mar 4, 2020 at 10:12
  • $\begingroup$ There are special instructions for GCM as well, and it is definitely a less complex operation. These kind of comparisons are sometimes counter intuitive. ECC in Bouncy Castle was slower than RSA, then they reimplemented and now it is faster than the ECC provided in the Java runtime - and that is using native speedups. So yes, in principle faster, but mileage may vary (and only the latest processors have SHA-256 acceleration)l. $\endgroup$
    – Maarten Bodewes
    Commented Mar 4, 2020 at 11:07

If used correctly, and solely for the purpose of authenticity, then AES-GCM or any other AEAD with an empty plaintext is just as good as HMAC (or KMAC, a MAC construction based on the same primitive as SHA-3). But these are pretty big assumptions! HMAC and KMAC are a lot more robust than AES-GCM.

AEAD requires a nonce for the encryption. If the same nonce is used twice with the same key, this impacts confidentiality with any AEAD algorithm: at the very least, it reveals whether the messages are identical. But for many popular AEAD algorithms, nonce reuse also impacts authenticity. In particular, with GCM, nonce reuse is catastrophic: if you use the same key and the same nonce with two different messages, this allows a wide range of forgeries. HMAC and KMAC don't have this problem: it doesn't rely on a nonce at all.

AES-GCM-SIV remedies this weakness: reusing a nonce doesn't impact confidentiality. However, this comes at the cost of making two passes over the message, which more or less defeats the performance benefit of AES-GCM over HMAC.

AES is naturally vulnerable to side channel attacks when implemented in software. In particular, it's vulnerable to timing attacks from processes running on the same machine when implemented in the naive way; it's possible to protect against this, but at a significant performance cost. HMAC and KMAC, in contrast, are naturally resistant to timing attacks. And it's no more sensitive than AES to other side channels such as power.

AES-GCM (with an empty plaintext) only guarantees authenticity: someone who doesn't have the secret key can't forge an authentic message. HMAC and KMAC have a stronger property which is sometimes desirable: even with the secret key, they're also a keyed hash, meaning that it's infeasible to create two distinct messages that have the same HMAC (or KMAC) with the same key, and it's infeasible to find a message knowing its HMAC (or KMAC) and the key other than by guessing. Both are easy with GCM or CCM.


Your Answer

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

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