What are the benefits of using AEAD algorithms as MAC

Question

I've seen in 2 places where NIST acknowledge the possibility of using AEAD algorithm for MAC (e.g. page 7 section 5.2 of GCM spec, summary for LAEM on page 6 of LWC status report).

And I see 2 problems with this:

1. An AEAD algorithm requires a nonce - something that doesn't fit well into the interface of $\text{MAC}_K(M) \rightarrow T$.

2. Most (and the correct) API for AEAD implementations (e.g. Web Crypto, Apple CryptoKit) receives input all-at-once - they are not progressively updated.

On the other hand, HMAC has several more application than authenticating messages - HMAC_DRBG, HKDF, to name a few. And they seems to be specifically instantiated from HMAC and cannot use other MACs, whether artificial like GMAC or associated with the algorithms they come with such as KMAC from SHA3/Keccak or keyed BLAKE2.

So to summarize, MACs derived from AEAD: 1) needs nonce, 2) needs different API (init-update-final) from that of AEAD (all-at-once), and 3) lacks usefulness.

So the questions:

1. Is there any benefit using an AEAD as a MAC (edit: specifically as a building block in constructs that expects one that behaves like a PRF such as HMAC) other than "it reduces code/circuit size"?

2. And what is (or was) NIST thinking when they acknowledge(d) using AEAD as MAC?

Answer 1

Your question almost answers itself, in my opinion:

Is there any benefit using an AEAD as a MAC (edit: specifically as a building block in constructs that expects one that behaves like a PRF such as HMAC) other than "it reduces code/circuit size"?

No, doesn't seem to be.

And what is (or was) NIST thinking when they acknowledge(d) using AEAD as MAC?

Somebody who was involved in NIST's standardization process would need to chime in, but likely they were thinking that it reduces code/circuit size in some applications.

---

This bit merits a tangential remark:

Most (and the correct) API for AEAD implementations (e.g. Web Crypto, Apple CryptoKit) receives input all-at-once - they are not progressively updated.

Something that's becoming increasingly common is for cryptography APIs to offer incremental constructions on top of all-at-once AEADs:

• https://libsodium.gitbook.io/doc/secret-key_cryptography/secretstream
• https://github.com/miscreant/meta/wiki/STREAM
• https://www.imperialviolet.org/2014/06/27/streamingencryption.html

So don't make the mistake of thinking that, because vendor crypto libraries still haven't adopted this approach, therefore all-at-once is always the correct way to use an AEAD, or that having an incremental primitive is more valuable than it really is.

And even in a scenario where you only need a MAC, you might still need to worry whether an adversary can cause harm by undetectably reordering, duplicating or deleting the messages in a stream. This is often taken care of by higher-level protocols that incorporate e.g. a message number as part of the input to the MAC (which is a kind of nonce!), but streaming AEAD constructions like these would get you this sort of protection for free as well.

That is, the contrast you bring up between the APIs of AEADs and MACs and use as a premise for your evaluation of the disadvantages of an AEAD-as-MAC construction do reflect very common implementation choices, but beware reading too much into it.

Answer 2

Think about 2 special cases when using AEAD:

• Some confidential data but blank associated data
• Some associated data, but blank confidential data

In first case what you get when using AEAD cipher (e.g. AES-GCM) is just Authenticated Encryption, as there is no associated data.

In second case what you get when using AEAD cipher (again, e.g. AES-GCM) is essentially a MAC - there was nothing to encrypt, and what you actually did was calculation of authentication tag over associated data.

BTW, "What are the benefits of using AEAD algorithms as MAC" and "What is (or was) NIST thinking when they acknowledge(d) using AEAD as MAC?" are actually two different questions. I hope I answered the latter.

EDIT:

If you look at MAC algorithms like Poly1305, Poly1305-AES or CBC-MAC, they also use nonce/iv.

Answer 3

Efficiency

Efficiency is one reason why e.g. GCM as a MAC would be nice. GCM uses GMAC, which can be a relatively fast operation with hardware support. Modern (AMD 64 compatible) processors have an Intel defined multiplication instruction called PCLMULQDQ to support it (Intel hosted PDF).

Commonly GCM is said to have 1.5 passes instead of the actual two to indicate that the MAC pass is faster than what you would commonly expect (the speed depends on the implementation and isn't necessarily 0.5 times the speed of a "normal" MAC). However, in software it could actually be slower than other MAC implementations.

Note that if the ciphertext is empty that the GCM spec will simply hash the padded AAD, the length of the AAD (64 bits) and the length of the ciphertext (64 bits set to zero). As the lengths together make one 128 bit block, this is relatively efficient. The computation is just GMAC according to the specification. Some libraries still have a separate GMAC implementation though.

CPU cycles on Intel

Currently GMAC scores about 2.33 cycles / byte using the optimized instruction, SHA-256 in software somewhat over 11 cycles / byte but in hardware (Intel SHA extensions), it may be faster at 1.9 cycles / byte (!). Beware that these are optimal results, it's not required that software makes use of these instructions. For smaller messages you should also take in mind that there will be a non-negligible overhead for both GMAC and HMAC constructions.

Above are general cycle counts on modern 2017-2020 Intel CPU's. You should only use these as numbers that give an idea of the overall performance.

Security

And yes, the nonce should supplied and the key / nonce combination should be unique. Personally I would not use GMAC for MAC only; it is a much more risky algorithm compared to e.g. HMAC. Please make sure your implementation will remain secure if you do use it.

Other AEAD ciphers

A similar argument can be made for Poly1305; it is probably somewhat faster than GMAC in software.

Other AEAD constructs such as CCM and EAX are build on more common MAC constructions. CCM uses CBC-MAC while EAX uses (AES-)CMAC. Both are so called two pass protocols, so using those as MAC will not offer any performance benefits. Instead of using CCM or EAX as MAC it is probably best to just use HMAC or indeed AES-CMAC directly, whichever is best for your particular application and system.