What are the benefits of using AEAD algorithms as MAC

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?

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:

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.

• The last part is a bit unclear. "So don't make the mistake of thinking that ..." can you clearify what mistake of thinking should avoid by clearing up the sentence structure? "And even in scenario where ..." are you trying to make the point that "streaming AEAD" (like the ones listed in the links) protects one from unreliable transport of ciphergram? "... but beware reading too much into it" can you make a formalized argument here? Jul 9, 2020 at 2:34
• @DannyNiu: I've made a grammar edit. The point is just that even if the receiver can verify that all individual messages are individually authentic, without some protective measure, an active man-in-the-middle might still have tampered with the sequence of messages. Whether that's a threat depends on the application where the MAC is used. Jul 9, 2020 at 12:10

• 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.

• Let me edit my question for the purpose of seeking a more specific answer. I appreciate your effort, both answering and notifying me the problem in my question. Jul 7, 2020 at 6:18
• I appreciate your effort, but everyone seems to misinterpret my intent. I'm actually asking MAC as a component rather than MAC as functionality. I've edited my question accordingly. Jul 8, 2020 at 7:45

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.