Cybersecurity glossary
What is Authenticated Encryption with Associated Data (AEAD)?
Learn what AEAD is, how authenticated encryption binds ciphertext to associated data, why GCM and ChaCha20-Poly1305 matter, and how to avoid nonce-reuse failures.
Definition
Authenticated Encryption with Associated Data (AEAD) is a cryptographic construction that provides confidentiality for plaintext and integrity for both the ciphertext and additional associated data, typically returning an authentication tag that must verify before decryption succeeds.
Why AEAD changed applied cryptography
Encrypting alone is not enough. Attackers who can flip bits in ciphertext—or swap headers—often break systems even when they cannot read plaintext. Authenticated Encryption with Associated Data (AEAD) closes that gap by binding confidentiality and integrity into one primitive.
Modern TLS, SSH, age, WireGuard, and most cloud envelope-encryption libraries default to AEAD for exactly this reason: one API, fewer footguns, stronger defaults.
What AEAD guarantees
An AEAD scheme takes a key, a nonce, plaintext, and optional associated data. It returns ciphertext plus an authentication tag. Decryption succeeds only if the tag matches for that exact ciphertext, nonce, and associated data under the key.
Confidentiality
Plaintext is encrypted so network or disk observers without the key cannot recover content.
Integrity of ciphertext
Any modification of the encrypted bytes fails tag verification and must be rejected.
Associated data binding
Cleartext metadata is authenticated so attackers cannot re-label or re-route messages unnoticed.
Fail-closed decrypt
Implementations should refuse to emit plaintext when authentication fails.
How an AEAD protect-and-verify cycle works
Assemble inputs
Application selects key, unique nonce, plaintext, and any headers that must stay visible but authentic.
Seal the message
The AEAD encrypts plaintext and computes a tag covering ciphertext and associated data.
Transmit or store
Ciphertext, nonce, tag, and clear associated data travel together; the key does not.
Receiver recomputes trust
Using the same key and nonce, the library verifies the tag against ciphertext and AAD.
Accept or reject
Only verified messages decrypt to plaintext; failures are logged as integrity errors.
AEAD vs older compositions
| Approach | Integrity | Typical risk |
|---|---|---|
| AEAD (GCM, ChaCha20-Poly1305) | Built-in authentication tag | Nonce misuse if uniqueness is not enforced |
| Encrypt-then-MAC | Separate MAC over ciphertext | Wrong order, wrong coverage, or skipped verify |
| MAC-then-encrypt | MAC inside ciphertext | Padding oracles and fragile designs |
| Encrypt only | None | Bit-flipping and protocol confusion attacks |
Practical checklist for AEAD use
- Call a vetted AEAD API instead of composing cipher and MAC primitives yourself.
- Put protocol fields that attackers might swap into associated data when they must remain readable.
- Guarantee nonce uniqueness per key; prefer counters, random 96-bit nonces with rotation limits, or XChaCha-style extended nonces.
- Rotate keys before nonce birthday bounds become realistic for your volume.
- Never ignore authentication failures or “best effort” decrypt paths.
- Keep version identifiers and key IDs authenticated so downgrade or key-confusion tricks fail.
- Prefer constant-time library implementations and avoid comparing tags manually in application code.
- Document which fields are AAD versus encrypted so future refactors do not drop coverage.
Where teams still get AEAD wrong
The algorithm name on a diagram is not the control. Failures usually come from static nonces in mobile apps, truncating tags, encrypting without authenticating key identifiers, or decrypting in one layer and verifying in another after business logic already ran.
In multi-tenant systems, binding a tenant ID in AAD prevents ciphertext from being replayed under another tenant’s context even if storage access is shared.
The practical takeaway
AEAD is the modern default for symmetric protection: encrypt the secret bytes, authenticate everything that must not change, and reject anything that fails the tag. If your design still says “AES plus a checksum,” upgrade the composition—not just the marketing label.
Related security terms
Advanced Encryption Standard (AES)
The block cipher most often used inside AES-GCM AEAD suites.
ChaCha20-Poly1305
A popular stream-cipher AEAD used widely in TLS 1.3 and mobile stacks.
Nonce
The per-message value AEAD schemes require to be unique under a given key.
HMAC
A classic MAC often used in older encrypt-then-MAC designs that AEAD largely replaces.
TLS 1.3
Modern TLS uses only AEAD cipher suites for record protection.
Frequently asked questions
What is AEAD in simple terms?
AEAD encrypts data and also proves it was not altered. It can authenticate extra fields—like headers—without encrypting them, so recipients detect tampering of both payload and metadata.
What is associated data (AAD)?
Associated data is information that must be integrity-protected but not necessarily secret—protocol version bytes, packet headers, key identifiers, or tenant IDs. Changing AAD invalidates the authentication tag.
Why prefer AEAD over encrypt-then-MAC?
AEAD APIs package the correct composition in one call, reducing ordering mistakes, padding-oracle exposure, and incomplete verification. Hand-rolled combinations remain easy to get wrong.
Which AEAD algorithms are commonly used?
AES-GCM, AES-CCM, and ChaCha20-Poly1305 dominate modern protocols. Choice often depends on hardware AES support versus constant-time software performance on devices without AES-NI.
What happens if an AEAD nonce is reused?
For GCM and several other schemes, nonce reuse with the same key can leak plaintext relationships and authentication-key material. Treat uniqueness as a hard requirement.
Does AEAD replace digital signatures?
No. AEAD proves possession of a shared symmetric key and protects a message. It does not provide non-repudiation or public verifiability the way signatures do.
Is ciphertext authentication checked before decryption?
Secure implementations verify the tag and reject the message before releasing plaintext. Never process unverified decrypted bytes.
References
Explore authoritative guidance and frameworks related to authenticated encryption with associated data (aead).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.