Quiz Entry - updated: 2026.07.14
What does AEAD (Authenticated Encryption with Associated Data) combine, and why is it now the default?
AEAD is one cipher operation that provides confidentiality (encryption), integrity (MAC), and authentication of unencrypted associated data — all under a single key, in one pass. AES-GCM and ChaCha20-Poly1305 are the modern defaults.
The two components of AEAD:
- Encryption — keeps plaintext confidential (e.g. AES in CTR mode).
- Authentication — produces a tag that detects any tampering with ciphertext OR with associated data (AD) that's transmitted in the clear (e.g. a TCP header, packet length, sequence number).
Why AEAD replaced encrypt-then-MAC:
- One operation instead of two — fewer chances for developers to misuse the API.
- No padding-oracle attacks — these plagued CBC-mode encrypt-then-MAC implementations (POODLE, Lucky 13).
- Performance — AES-GCM uses AES-NI + PCLMULQDQ; ChaCha20-Poly1305 is fast on devices without AES hardware (mobile, embedded).
Common AEAD ciphers:
| Cipher | Hardware-accelerated on | Notes |
|---|---|---|
| AES-GCM | x86 (AES-NI), ARMv8 (Crypto Ext) | TLS 1.3 default for desktops/servers |
| ChaCha20-Poly1305 | All CPUs (constant-time SIMD) | TLS 1.3 default for mobile, slow on devices without AES-NI |
| AES-CCM | Same as AES-GCM | Used in IPsec, WPA2 (CCMP), Bluetooth LE |
| AES-OCB / AES-SIV | — | Less common; SIV resists nonce reuse |
Tip: Never roll your own encrypt-then-MAC in 2025 — always use an AEAD primitive (libsodium's secretbox, crypto/cipher.AEAD in Go, the JCE GCM mode in Java). Most "we encrypted but didn't authenticate" vulnerabilities disappear when you switch to AEAD.