Despite working with AES-GCM and other AEAD algos for a few years, I've struggled with the concept of 'authenticated' in the term 'AEAD'. In my own experience (of Unix, PKI and blockchain) authentication means being able to attribute actions towards a particular entity (eg, a user account). In the simplest case, say authentication on a Linux box, logging in would use the pam_unix Pluggable Authentication Module to check a user's provided password, when hashed, matches the hash stored on the Linux system. You could also authenticate user accounts by their fingerprint, or face match, etc. In each of these cases, authentication means being able to attribute that login or unlock action back to an individual entity (eg a user account).

Even the authentication tag on crypto.stackexchange.com reads:

Authentication is successfully validating that an entity you are communicating with is actually who they claim to be. The entity typically demonstrates who they are by showing they possess a secret that only they could know.

Whereas the authenticated-encryption tag reads reads:

Combination of encryption and authentication in a way that ensures confidentiality and integrity.

There's no authentication in the authenticated-encryption definition, according to the definition provided in the authentication tag.

Wondering exactly where the 'authentication' was in in AEAD has bugged me for years, and I've recently spent time investigating. This video from F5 'What Are AEAD Ciphers?' has some useful parts around 2:30 mins:

The authenticated encryption, the A part of the 'AE', brings in another piece which in the integrity of the message itself

The A part, the authenticated encryption, brings in the integrity

Whoever sent this message I need to make sure the message had not been changed or tampered with

Does 'authentication' in the sense of 'Authenticated Encryption', just mean 'message integrity' and not 'authentication' in the sense most cryptography, infosec and Unix people would use?

Some follow up questions:

  • If 'Authenticated' just means 'has message integrity': how and why did 'message integrity' get confused with 'authentication'? This seemingly uncommon definition of 'authentication' seems unusual in technical communities where words have very specific meanings.

  • If 'Authenticated' in fact means 'authenticated' in the common sense (which I now suspect it does not), how are AEAD messages attributable to a particular entity?

  • $\begingroup$ Replying to self - we do have 'MAC' as message authentication code (a hash used to for integrity of messages) which has similar issues - it's integrity, not authentication. Apparently some people once used Message Integrity Code instead. $\endgroup$ Commented Oct 28, 2022 at 15:45
  • $\begingroup$ What does AES-GCM provide? $\endgroup$
    – kelalaka
    Commented Oct 28, 2022 at 18:05
  • $\begingroup$ The AEAD authentication is mutual, that is without additional information apart from the ciphertext and tag, anyone who has the key can be the owner of the authenticated message. $\endgroup$
    – kelalaka
    Commented Oct 28, 2022 at 22:33
  • $\begingroup$ I read "integrity" as meaning that the message wasn't disrupted by some technical reason, a glitch or an error. And "authentication" as meaning we can verify it came from some known sender. $\endgroup$
    – ilkkachu
    Commented Oct 29, 2022 at 10:14

3 Answers 3


The notion of authentication stated in the question seems to be more compatible with what is sometimes talked to as entity authentication. In short, "you know who you are talking to." Bellare & Rogaway discussed this in the context of key exchange protocol. In comparison, an AEAD scheme provides message authentication. As discussed in the other answers, message authentication implies message integrity and "authentication" of the message source.

However, source authentication of AEAD isn't necessarily and generally is not the same as entity authentication. It does tell that whoever held the key produced the message at some point. But it doesn't say:

  1. Who exactly is that person for some notion of identity? Indeed, assume the key was derived using the usual Diffie-Hellman protocol. Sure, any received ciphertext comes from whoever participated in the key exchange, but if they claim to be Alice, the AEAD won't tell us if that's true.
  2. The message comes "directly" from the source. Indeed, an eavesdropper may replay an existing ciphertext. So, receiving a ciphertext doesn't necessarily guarantee that we are in "direct" communication with the message with whom we share a key.

The point is, indeed, we must carefully consider what is understood as authentication. By the way, entity authentication also doesn't necessarily guarantee the "authentication" of AEAD either. Hence, careful constructions are needed.


Personally, I don't find the term "integrity" to be very useful when discussing cryptography. Cryptography (almost always) enforces/restricts behavior based on who holds a secret key. Knowledge of a secret key is the cryptographic way of formalizing identity. I find it generally easier to talk in terms of authenticity, because authenticity is always a reference to identity.

Authenticated encryption and MACs have the following property: "only someone who holds the key can generate valid objects." This is a guarantee about both authentication and integrity:

  • Authentication: it concerns the identity of who created an object
  • Integrity: it implies that there is no way for someone without the key to modify the contents of a valid object to obtain a different valid object.
  • 3
    $\begingroup$ I disagree with this definition. Cryptographic hash functions are certainly part of cryptography, don't have a "key" input, and guarantee integrity of the hashed data. $\endgroup$ Commented Oct 29, 2022 at 1:11
  • $\begingroup$ Hash functions are exactly why I wrote "almost always" $\endgroup$
    – Mikero
    Commented Oct 29, 2022 at 3:34
  • $\begingroup$ There is always at least two entities that can claim ownership of the authentication. The sender and the receiver(s) because they have both the keys. This is where authentication differs from non-repudiation which requires secure digital signatures. I prefer to use mutual authentication to indicate the difference. Without additional information, a third party may not determine the creator by just looking at the AES-GCM encrypted information. $\endgroup$
    – kelalaka
    Commented Oct 30, 2022 at 19:36
  • $\begingroup$ Yes, it is an important distinction. In ZK we have the term "designated verifier" which means only a particular person can verify the proof. So a MAC is a kind of "designated verifier" authentication whereas signatures are "universal verifier". $\endgroup$
    – Mikero
    Commented Oct 31, 2022 at 1:49

It's authentication of the data, not who or what encrypted the data. It goes beyond integrity as the party decrypting the data can determine if he's using the same key as the encrypting party did to encrypt the data.

  • $\begingroup$ I agree that's the easiest way of defining it. However, there are key commitment issues with AEADs that mean the second part isn't necessarily true. $\endgroup$ Commented Oct 29, 2022 at 7:33

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.