Authenticated Encryption (AEAD)

Before AEAD, developers combined encryption and a MAC manually - and made mistakes: MAC-then-Encrypt (vulnerable to padding oracle), Encrypt-and-MAC (data leaks through the MAC), wrong key order. Lucky Thirteen, BEAST, POODLE all exploited wrong combinations. AEAD merged both properties into an atomic primitive that is harder to misuse.

• TLS 1.3 banned all non-AEAD cipher suites - only AES-GCM and ChaCha20-Poly1305 remain
• WireGuard chose ChaCha20-Poly1305 as its sole algorithm - no negotiation, no downgrade, the code fits in 4000 lines
• Signal encrypts each message with a separate key using ChaCha20-Poly1305 - forward secrecy at the message level

GCM: CTR + GHASH in one primitive

Galois/Counter Mode (GCM) became the AEAD standard after 2007. The idea: take CTR for confidentiality, add GHASH for integrity, combine them into an atomic primitive. An attacker cannot modify the ciphertext undetected - the 128-bit authentication tag will break.

GCM has two parts: AES-CTR encrypts the data (with nonce/counter), GHASH authenticates the ciphertext plus Additional Authenticated Data (AAD). AAD is data that must be authenticated but not encrypted - an IP header, protocol version, or session ID. If the AAD changes, the tag is invalid.

GHASH operates over the Galois field GF(2^128). It is polynomial hashing - each data block is multiplied by the authentication key H = AES(key, 0^128) in the field. Intel implemented the PCLMULQDQ instruction for GF(2^128) multiplication. On a modern CPU AES-256-GCM delivers 20+ Gbit/s.

The nonce in GCM must be unique for every message under a given key. If a nonce is reused, an attack recovers the authentication key H with two XOR operations. TLS generates the nonce from a sequence number to guarantee uniqueness. With a random 96-bit nonce the birthday bound is 2^48 messages before a likely collision.

ChaCha20-Poly1305: AEAD without AES hardware

2014. Daniel J. Bernstein and Tanja Lange. ChaCha20-Poly1305 became an official cipher suite in TLS 1.2 (RFC 7539) and mandatory in TLS 1.3. The reason: billions of Android devices lack AES-NI hardware - on those, GCM runs 3x slower than ChaCha20.

ChaCha20 is a stream cipher based on ARX (Add-Rotate-XOR) operations. Twenty rounds of transformation on a 4x4 matrix of uint32. Fully constant-time with no lookup tables - no timing side-channel as software AES without hardware support has. Poly1305 is a MAC based on one-time polynomial hashing over a prime field.

WireGuard uses exclusively ChaCha20-Poly1305. One cipher suite, no negotiation, minimal attack surface. Google Chrome switched to ChaCha20-Poly1305 as the preferred cipher for mobile connections in 2014. Signal Protocol standardized it for all messages.

GCM vs ChaCha20-Poly1305: with AES-NI (desktop, server) GCM is faster. Without AES-NI (mobile, IoT, older ARM) ChaCha20 is faster. Both are equally secure when used correctly. TLS 1.3 supports both. The choice depends on the target platform.

CCM: AEAD for IoT and constrained devices

Counter with CBC-MAC (CCM) is an AEAD mode for resource-constrained environments. It uses AES as the only primitive for both layers: CBC-MAC for authentication and CTR for encryption. It requires a single pass over the data (unlike EAX, which needs two).

CCM is a mandatory cipher suite in IEEE 802.15.4 (Zigbee, Thread), Bluetooth Low Energy (AES-CCM), and IEEE 802.11i (Wi-Fi WPA2 with CCMP). On microcontrollers without floating-point units, CCM is optimal: integer-only operations, one AES engine serves both functions.

CCM is unsuitable for streaming: the data length must be known to form the CBC-MAC header. GCM works with streaming. For TLS (where record size is known) both work. For large files without a known size, use GCM or ChaCha20-Poly1305.

AEAD pitfalls: how to break a correct primitive

AEAD primitives are secure only when used correctly. Three classes of mistakes destroy security even with the right algorithm.

Timing side-channel during tag verification is a real attack. If `tag_received == tag_computed` is checked byte by byte and returns false on the first mismatch, an attacker measures response time and guesses the tag one byte at a time. Defense: constant-time comparison (Python `hmac.compare_digest`, C `timingsafe_memcmp`).

Lucky Thirteen (2013) - a timing attack on MAC-then-Encrypt. SSL/TLS CBC+HMAC checked padding before the MAC during decryption. Padding length affected response time. The attack recovered data in 223 requests. Switching to AEAD (GCM) eliminated the entire attack class.

Related Topics

AEAD is the final step in symmetric encryption before the protocol layer:

• Block Cipher Modes — GCM is built on top of CTR
• TLS — TLS 1.3 uses only AEAD
• HMAC and MAC — MAC-then-Encrypt alternative that AEAD replaces

Key Ideas

• AEAD provides confidentiality + integrity atomically: decryption without integrity verification is impossible
• GCM = AES-CTR + GHASH. Hardware AES-NI delivers 20+ Gbit/s. Nonce uniqueness is critical
• ChaCha20-Poly1305: constant-time without lookup tables, fast on mobile devices without AES-NI
• CCM for IoT: one AES primitive for both functions, but requires knowing data length in advance

Вопросы для размышления

• How do you manage nonce uniqueness in a distributed system where many nodes encrypt data with the same key?
• When should CCM be chosen over GCM despite its limitations?
• What happens if an attacker intercepts the nonce - does that change the algorithm choice?

Связанные уроки

• crypto-15-block-cipher-modes — GCM is built on top of CTR mode
• crypto-21-hmac-mac — HMAC is the alternative to a built-in AEAD tag
• crypto-32-tls — TLS 1.3 uses only AEAD cipher suites
• crypto-33-signal-protocol — Signal uses ChaCha20-Poly1305
• net-23-https-tls