AEAD (Authenticated Encryption with Associated Data).

Authenticated Encryption with Associated Data (AEAD) is the modern building block of symmetric cryptography. An AEAD scheme takes a key, a nonce, a plaintext, and arbitrary associated data (AD) and produces a ciphertext plus an authentication tag; on decryption it returns the plaintext only if the tag verifies, otherwise refusing. The associated data is authenticated but not encrypted, letting protocols bind unencrypted context such as packet headers, sequence numbers, or version metadata to the ciphertext without ever sending them encrypted.

Compared to encrypt-then-MAC or MAC-then-encrypt compositions, AEAD eliminates whole classes of bugs and is what every modern protocol — TLS 1.3, QUIC, IPsec ESP-GCM, Signal, Noise, WireGuard, JWE — uses. History shows why this matters: the Lucky 13 (2013) and POODLE (CVE-2014-3566) attacks both exploited the fragile MAC-then-encrypt CBC construction in TLS, and the move to AEAD record protection closed those doors. The formal model was defined by Rogaway in 2002 and standardised as RFC 5116, with concrete schemes registered by IANA.

The dominant AEAD schemes are AES-GCM (hardware-accelerated via AES-NI and PCLMULQDQ) and ChaCha20-Poly1305 (RFC 8439, fast in software on mobile CPUs). Both fail catastrophically if a (key, nonce) pair repeats — GCM nonce reuse can leak the authentication key. Where unique nonces cannot be guaranteed, nonce-misuse-resistant AES-GCM-SIV (RFC 8452) limits the leak to whether two plaintexts were equal. Always prefer a vetted AEAD over a homebrew encrypt-and-MAC composition.

flowchart LR
  K[Key] --> ENC
  N[Nonce] --> ENC
  P[Plaintext] --> ENC[AEAD encrypt]
  AD[Associated data<br/>headers · IDs] --> ENC
  ENC --> CT[Ciphertext]
  ENC --> TAG[Auth tag]
  CT --> DEC[AEAD decrypt]
  TAG --> DEC
  AD --> DEC
  K --> DEC
  N --> DEC
  DEC --> V{Tag valid?}
  V -->|Yes| OUT[Return plaintext]
  V -->|No| REJ[Reject · no plaintext leaked]