up:: Classical Cryptography MOC

Authenticated Encryption (AEAD)

Authenticated encryption with associated data (AEAD) is the modern way to encrypt a message so that a single primitive protects both its confidentiality and its integrity, and also authenticates extra cleartext data such as a packet header. RFC 5116 defines the interface: one operation takes a key, a nonce, the plaintext, and optional associated data, and returns a ciphertext that hides the plaintext and lets the receiver detect any tampering with the ciphertext or the associated data. The two AEAD schemes the internet runs on are AES-GCM and ChaCha20-Poly1305, and both are mandatory options in TLS 1.3. The quantum story is calm, because AEAD is symmetric, so Grover’s algorithm only weakens its key search rather than breaking it, and a 256-bit key keeps a wide margin.

Source: D. McGrew, “An Interface and Algorithms for Authenticated Encryption,” RFC 5116, January 2008, rfc-editor.org/rfc/rfc5116.

The short version:

• AEAD delivers confidentiality and integrity/authentication together in one primitive, so the receiver both reads a message and proves it was not altered, without bolting a separate check onto a plain cipher.
• The “associated data” part authenticates extra cleartext, such as a header or sequence number, so it can be read in transit yet cannot be forged, while only the plaintext payload is encrypted.
• RFC 5116 fixes the interface: a key, a nonce, plaintext, and associated data go in, and a ciphertext (carrying an authentication tag) comes out.
• The two dominant AEAD schemes are AES-GCM, built on AES hardware acceleration, and ChaCha20-Poly1305, a software-friendly alternative. TLS 1.3 permits only AEAD cipher suites.
• It survives the quantum transition. AEAD is symmetric, so only Grover’s algorithm applies, and that just halves the key-search margin. A 256-bit AEAD key keeps about 128 bits of effective security.
• Its sharp edge is classical: every AEAD scheme in this family requires a nonce that never repeats under a given key, and a repeated nonce breaks the guarantees regardless of key size.

Picture a courier envelope with a wax seal stamped across both the flap and the shipping label. The envelope keeps a stranger from reading the letter, and the seal shows at a glance whether anyone opened the flap or rewrote the address. AEAD is that envelope and seal in one motion: the payload is hidden, the payload and the address are both under the seal, and if either is disturbed the receiver throws the whole thing away unread. That combination of privacy and proof-of-untampered is exactly what a secure connection needs on every message it carries.

What is authenticated encryption with associated data?

AEAD is a cryptographic interface, formalized in RFC 5116, in which one operation encrypts a payload and authenticates that payload plus a block of associated data at the same time. RFC 5116 describes it as encryption that “provides a way to check its integrity and authenticity” while also giving “the ability to check the integrity and authenticity of some Associated Data that is not encrypted.” The design exists to fold two jobs that used to be done by two separate primitives, a cipher for secrecy and a message authentication code for integrity, into a single primitive that is safe by construction.

The authenticated-encryption operation takes four inputs and produces one output:

1. A secret key K, which RFC 5116 requires to be generated in a way that is uniformly random or pseudorandom.
2. A nonce N, where each nonce given to distinct encryption operations must be distinct for any one value of the key. This uniqueness requirement is the operational rule the whole family lives by.
3. A plaintext P, the data to be encrypted and authenticated.
4. Associated data A, the data to be authenticated but not encrypted, meant for fields that must stay readable such as addresses, ports, sequence numbers, and protocol version numbers.

The output is a ciphertext C, at least as long as the plaintext, which carries the encrypted payload together with an authentication tag. Decryption is the mirror operation: given the key, the nonce, the ciphertext, and the same associated data, it either returns the plaintext or returns a failure because the tag did not verify. That single fail-closed path is the heart of AEAD, because tampered data is rejected rather than handed to the application.

Source: D. McGrew, “An Interface and Algorithms for Authenticated Encryption,” RFC 5116, January 2008, rfc-editor.org/rfc/rfc5116.

How does an AEAD scheme work?

An AEAD scheme runs a confidentiality mechanism and an authentication mechanism over the same key, then binds their results so the receiver verifies before it decrypts. The two dominant schemes take different routes to the same guarantee:

1. AES-GCM encrypts with AES in counter mode to produce the ciphertext, then runs the ciphertext and the associated data through a keyed hash called GHASH, working in the Galois field GF(2^128), to produce a 128-bit authentication tag. The counter-mode encryption and the GHASH both parallelize, and modern CPUs carry dedicated instructions for each, which is why AES-GCM runs at multi-gigabit speeds.
2. ChaCha20-Poly1305 encrypts with the ChaCha20 stream cipher and authenticates with the Poly1305 one-time authenticator. It leans on no special hardware, so it stays fast on devices that lack AES acceleration, and it is the common default on mobile and embedded platforms.

Both follow the same discipline on the receiving side. The receiver recomputes the authentication tag over the ciphertext and the associated data it actually received, compares it against the tag that arrived, and only decrypts if they match. If a single bit of the ciphertext, the associated data, or the tag was altered, the tags differ and the whole message is rejected. Verification and decryption are one operation, which is what makes AEAD safe by construction: there is no path that returns tampered plaintext to the caller.

Sources: NIST, “Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC,” SP 800-38D, November 2007, csrc.nist.gov/pubs/sp/800/38/d/final; Y. Nir and A. Langley, “ChaCha20 and Poly1305 for IETF Protocols,” RFC 8439, June 2018, rfc-editor.org/rfc/rfc8439.

What does AEAD add over a plain cipher?

AEAD adds tamper detection and header authentication on top of the secrecy a plain cipher provides, and it does both in one pass with one primitive. A confidentiality-only mode such as CBC or CTR hides a message’s contents but proves nothing about whether it arrived unchanged, so it has to be paired with a separate MAC to be safe. Composing those two pieces by hand is historically where protocols break: the wrong order, a MAC computed over the wrong bytes, or a timing leak in the tag comparison. AEAD removes that entire category of mistake by shipping the composition inside the primitive. The comparison:

Property	Plain confidentiality mode (CBC, CTR)	AEAD (AES-GCM, ChaCha20-Poly1305)
Hides message contents (confidentiality)	Yes	Yes
Detects tampering (integrity / authentication)	No, needs a separate MAC	Yes, built in via the authentication tag
Authenticates cleartext associated data (headers)	No	Yes
Composition of encrypt and authenticate	Done by the protocol designer, error-prone	Done inside the primitive, safe by construction
Main failure mode	MAC omitted or wrongly composed	Nonce reused under the same key

The practical upshot is that standards bodies moved toward AEAD-only designs precisely because a developer gets one primitive that is correct as long as nonces stay unique. That is why TLS 1.3 dropped every older confidentiality-only-plus-separate-MAC construction and permits only AEAD.

Source: D. McGrew, “An Interface and Algorithms for Authenticated Encryption,” RFC 5116, January 2008, rfc-editor.org/rfc/rfc5116.

Why does the nonce have to be unique?

The nonce has to be unique per key because every scheme in this family derives its keystream and its authentication behavior from the key and the nonce together, so repeating a nonce under one key collapses both guarantees at once. RFC 5116 states the requirement directly: each nonce provided to distinct encryption operations must be distinct for any particular value of the key. Two things go wrong when a nonce repeats:

1. Confidentiality collapses. These schemes encrypt with a keystream that depends only on the key and the nonce. Two messages encrypted under the same key and nonce reuse the same keystream, so combining the two ciphertexts by XOR cancels the keystream and exposes the XOR of the two plaintexts, the classic two-time-pad failure.
2. Authentication collapses. In AES-GCM specifically, a repeated nonce leaks enough about the GHASH hash subkey that an attacker can recover it and then forge valid tags for messages of their choosing, defeating the integrity guarantee entirely.

This is why well-built protocols never leave the nonce to chance. TLS 1.3 constructs each record’s nonce deterministically from a per-connection value combined with the record sequence number, so it cannot repeat within a connection. Where the risk of accidental reuse is unacceptable, systems reach for a nonce-misuse-resistant AEAD scheme, which limits the damage of a repeat. None of this touches the quantum question, because nonce management is a classical implementation hazard, present with or without a quantum computer.

Source: D. McGrew, “An Interface and Algorithms for Authenticated Encryption,” RFC 5116, January 2008, rfc-editor.org/rfc/rfc5116.

Is AEAD quantum-safe?

Yes, at 256-bit keys. AEAD is a symmetric construction, so the only quantum attack that applies is Grover’s algorithm, and Grover only speeds up brute-force key search quadratically, which halves the effective key strength rather than breaking the scheme. Walking it through:

1. AEAD security rests on the strength of its underlying cipher and the size of its key, not on the factoring or discrete-log math that Shor’s algorithm demolishes. Shor does not apply to AES, to ChaCha20, or to the authentication side.
2. Grover turns roughly 2^n key-search work into roughly 2^(n/2), so a 256-bit AEAD key (AES-256-GCM or ChaCha20-Poly1305, whose key is 256 bits) keeps about 128 bits of effective security against a quantum attacker, which is far out of reach.
3. A 128-bit key drops to about 64 bits of idealized quantum strength under the same attack, which is why the durable baseline is a 256-bit key.

The authentication side is quantum-safe on the same terms. The tag length sets the forgery resistance, and Grover offers no structural shortcut against a correctly used AEAD tag beyond the generic square-root effect. So the honest headline for AEAD matches the one for the ciphers underneath it: the quantum threat lands on the public-key key exchange that delivers the key, and a strong AEAD scheme at a 256-bit key carries forward through the transition unchanged. There is no post-quantum AEAD family to migrate to.

Sources: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov/pubs/ir/8105/final; D. McGrew, “An Interface and Algorithms for Authenticated Encryption,” RFC 5116, January 2008, rfc-editor.org/rfc/rfc5116.

Where does AEAD show up in real systems?

AEAD is the encryption layer of nearly every modern secure protocol, usually invisible under a name like “cipher suite” rather than appearing as a visible feature. Its common homes:

1. TLS 1.3, which permits only AEAD cipher suites and makes AES-128-GCM mandatory to implement, with AES-256-GCM and ChaCha20-Poly1305 as the other standard options. Every conforming TLS 1.3 stack carries at least one AEAD scheme.
2. QUIC and HTTP/3, which protect their packets with the same AEAD schemes TLS 1.3 uses, binding packet headers as associated data so they stay readable to the network while remaining unforgeable.
3. IPsec and WireGuard, the VPN protocols, which use AEAD (AES-GCM in IPsec, ChaCha20-Poly1305 in WireGuard) to protect tunneled traffic.
4. SSH and disk or database encryption, where AEAD protects a channel or a stored record and its metadata in one primitive.

The pattern across all of them is that the associated-data feature earns its place: a protocol almost always has fields that must be read by an intermediary (a routing header, a sequence number, a record type) yet must not be forgeable, and AEAD binds those fields to the encrypted payload without hiding them. That is why AEAD, not plain encryption, became the default shape of secure communication.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, August 2018, §9.1 (mandatory cipher suites), rfc-editor.org/rfc/rfc8446.

Common misconceptions

1. “AEAD is a specific algorithm.” AEAD is an interface, defined in RFC 5116, that many algorithms implement. AES-GCM and ChaCha20-Poly1305 are two AEAD schemes; AEAD itself is the shape they share.
2. “AEAD encrypts the header along with the payload.” Associated data is authenticated but left in the clear on purpose, so a router can read a header while still being unable to forge it. Only the plaintext payload is encrypted.
3. “You still need a separate MAC alongside an AEAD scheme.” You do not. The authentication tag is the integrity check, computed by the primitive itself, which is the entire point of AEAD.
4. “A quantum computer will break AEAD.” It will not. AEAD is symmetric, so only Grover’s algorithm applies, and a 256-bit key keeps about 128 bits of effective security. There is no post-quantum AEAD to migrate to.
5. “AEAD is safe no matter how you use it.” Its guarantees depend on never reusing a nonce under one key. A repeated nonce breaks both confidentiality and authentication regardless of key size.
6. “The authentication tag proves who sent the message.” It proves the message was untampered and came from someone holding the shared key, which is integrity and authenticity, not non-repudiation. Proving a specific individual produced it is the job of a digital signature.

Questions people ask

What does AEAD stand for? Authenticated encryption with associated data. It is an interface (RFC 5116) where one primitive both encrypts a payload and authenticates that payload plus extra cleartext data such as a header.

Why does AEAD matter? It removes the error-prone step of bolting a separate MAC onto a cipher by hand, which is where protocols historically broke. One primitive gives confidentiality and integrity together, safe by construction as long as nonces stay unique.

Is AEAD quantum-safe? Yes, at 256-bit keys. AEAD is symmetric and faces only Grover’s algorithm, which halves the key-search margin, so a 256-bit AEAD scheme keeps about 128 bits of effective security. The public-key layer around it is what gets replaced.

What is the difference between AES-GCM and ChaCha20-Poly1305? Both are AEAD schemes that TLS 1.3 supports and that give the same confidentiality-plus-integrity guarantee. AES-GCM leans on AES hardware acceleration, while ChaCha20-Poly1305 runs fast in software on devices without AES instructions. Their security is comparable when each is used correctly.

What is associated data used for? For fields that must stay readable in transit yet must not be forgeable, such as a network header, a sequence number, or a protocol version. AEAD authenticates them alongside the encrypted payload without encrypting them.

Does AEAD replace TLS or a VPN? No. AEAD is the encryption primitive those protocols use for the bulk of their traffic. TLS 1.3, QUIC, IPsec, and WireGuard all carry an AEAD scheme as their data-protection layer.

Is plain AES-CBC an AEAD scheme? No. CBC provides confidentiality only and has to be paired with a separate MAC to detect tampering. AEAD schemes fold that authentication into the primitive, which is why TLS 1.3 dropped the older CBC constructions.

---

Everything here is the map, given freely. When your team needs its own cryptography sorted into what survives the quantum transition and what has to move, that’s what an alignment briefing is for.

Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.