Authenticated Encryption

Core Idea

Authenticated encryption (AE) combines confidentiality and integrity in a single primitive, guaranteeing that ciphertext cannot be read or tampered with. AEAD (AE with Associated Data) additionally authenticates unencrypted metadata (headers, routing info). The correct generic composition is encrypt-then-MAC (encrypt first, then MAC the ciphertext). MAC-then-encrypt and encrypt-and-MAC have led to devastating attacks (padding oracles, BEAST, Lucky13). Dedicated AEAD constructions (GCM, ChaCha20-Poly1305, OCB) integrate encryption and authentication for efficiency and resistance to misuse. AE is the modern standard — standalone encryption without authentication is considered a design error.

Explainer

For decades, cryptographic textbooks taught encryption and authentication as separate concerns. Encryption hides the message; MACs ensure integrity. In practice, you need both — but how you combine them matters critically. Authenticated encryption (AE) integrates confidentiality and integrity into a single primitive, eliminating the composition pitfalls that have caused some of the most devastating attacks in the history of deployed cryptography.

The history of composition failures is instructive. MAC-then-Encrypt (compute MAC on plaintext, then encrypt both) was used in TLS through version 1.2. The problem: the receiver must decrypt before checking the MAC, and the decryption process can leak information through error behavior. CBC-mode decryption produces different error types for valid and invalid padding, creating a padding oracle that an attacker can exploit to decrypt the entire ciphertext byte by byte. The BEAST, Lucky 13, and POODLE attacks all exploited this pattern in real TLS implementations. Encrypt-and-MAC (encrypt plaintext, separately MAC plaintext) risks leaking plaintext information through the MAC tag, since MACs are not required to hide their input. Only Encrypt-then-MAC (encrypt plaintext, MAC the ciphertext) is generically secure: the MAC is verified before any decryption occurs, so invalid ciphertexts are rejected without processing, eliminating oracle attacks entirely.

Modern cryptography avoids these pitfalls by using dedicated AEAD (Authenticated Encryption with Associated Data) constructions that integrate both operations. AES-GCM combines CTR-mode encryption with a polynomial MAC (GHASH) computed over the ciphertext and any unencrypted associated data. ChaCha20-Poly1305 pairs the ChaCha20 stream cipher with the Poly1305 MAC, offering excellent performance on platforms without hardware AES acceleration. Both are AEAD schemes: a single function call takes a key, nonce, plaintext, and associated data, and produces a ciphertext with an integrated authentication tag. Decryption either succeeds (tag verifies, plaintext returned) or fails atomically (tag invalid, nothing returned) — no partial decryption leakage.

The "associated data" in AEAD is a crucial feature. Some data must be authenticated (tamper-proof) but not encrypted (visible to intermediaries). Network headers, database row identifiers, and protocol version numbers are examples: they provide context that must be bound to the ciphertext but readable by routing infrastructure. AEAD binds all of this — the encrypted payload plus the unencrypted associated data — under a single authentication tag. Modifying any bit of either the ciphertext or the associated data invalidates the tag. This comprehensive binding is why AEAD is the mandatory encryption mode in TLS 1.3, IPsec, QUIC, and essentially every modern security protocol. Standalone encryption — encryption without built-in authentication — is now considered a deprecated practice.