Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
