Parag Mali - tag: aead

The Standard Was Boring; That Was the Point: A Field Guide to HPKE (RFC 9180)

noreply@paragmali.com (Parag Mali) — Mon, 13 Jul 2026 08:42:43 GMT

**"Encrypt to a public key" sounds like the most basic promise in cryptography, yet the industry standardized it four incompatible ways.** ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2, and SEC 1 all shipped a version of ECIES; two conforming implementations could produce ciphertexts that would not decrypt for each other, none came with shared test vectors, and one standard openly documented that an attacker could forge a second valid ciphertext for the same plaintext and named it "benign malleability" [@sec1], [@maea10]. HPKE (RFC 9180, 2022) is the boring, correct fix: one KEM-DEM construction where a Key Encapsulation Mechanism *generates* a shared secret and its encapsulation, an HKDF key schedule with every public key bound in derives the working keys, and an AEAD seals the data [@rfc9180]. It is IND-CCA2-proven, machine-checked across all four modes (`base`, `psk`, `auth`, `auth_psk`), and shipped with per-ciphersuite test vectors [@lipp20], [@abhklr20]. Because the primitive is correct by construction, HPKE has no known catastrophic real-world break; the entire discipline is knowing its four modes and its non-goals. It does *not* provide forward secrecy against recipient compromise in any mode, `auth` mode is *not* a signature, and its AEADs are *not* key-committing -- and every real HPKE incident to date is one of those non-goals assumed away or a check an implementation dropped [@rfc9180], [@ghsa]. It is the sealing primitive behind Encrypted Client Hello (RFC 9849), MLS, Oblivious HTTP, and Oblivious DNS; the post-quantum path is to swap the KEM (X-Wing / ML-KEM), not to redesign the scheme [@rfc9849], [@xwing]. The math held; the risk moved to the interface.

1. An Elementary Task the Industry Got Wrong Four Times

"Encrypt this to their public key" is the first promise public-key cryptography ever made. It is the one-line pitch of RSA, the thing every engineer assumes was solved and made boring decades ago, a settled corner of the field you reach for without thinking. Yet for roughly twenty-five years there was no single correct way to do it.

At least four "standard" versions of the Elliptic Curve Integrated Encryption Scheme (ECIES) shipped: ANSI X9.63 in 2001, IEEE 1363a in 2004, ISO/IEC 18033-2 in 2006, and SECG's SEC 1 version 2 in 2009 [@maea10], [@rfc9180]. They disagreed on the key-derivation function, the message authentication code, whether elliptic-curve points were compressed or uncompressed, and which optional fields went into the hash. Two conforming implementations, handed the same curve and message, could produce ciphertexts that would not decrypt for each other.

None of the four came with shared test vectors, so two libraries had no ground truth against which to check that they agreed. And one standard openly documented that an attacker could take a valid ciphertext and manufacture a second, different valid ciphertext for the same plaintext. It named the phenomenon "benign malleability" and deemed it harmless [@sec1].

The hard part of "encrypt to a public key," it turned out, was never the cryptography. It was getting everyone to do the same correct thing, with a proof that it was correct and a way to check that two implementations interoperated. That failure was tolerable when public-key encryption was a batch operation between parties who could negotiate a format. It stopped being tolerable the moment the modern web needed to encrypt to a server it had never spoken to.

Consider what TLS Encrypted Client Hello and Oblivious HTTP actually require. A client must encrypt the sensitive part of its connection -- in Encrypted Client Hello, the server name it is trying to reach -- to a public key it fetched moments earlier, for a server it has exchanged no messages with, with no round trip in which to negotiate anything [@rfc9849], [@rfc9458]. There is no handshake to agree on a KDF or a point encoding. The format has to be right the first time, on the first byte, or the connection reveals exactly what it was trying to hide.

That is the setting Hybrid Public Key Encryption was built for. HPKE, specified in RFC 9180 by the IRTF's Crypto Forum Research Group in February 2022, is the boring, correct answer [@rfc9180]. Its headline achievements sound almost too unglamorous to matter: it publishes test vectors, and it comes with a proof that it is secure against chosen-ciphertext attack.

Those two boring facts are exactly why HPKE matters. Once you accept them, the interesting question is not whether HPKE is secure but a sharper one, worth carrying through every section that follows: you have a stranger's public key and one shot to send them a secret, with no handshake and no reply -- what does HPKE buy you, and what does it silently refuse to give?

This is Part 19 of a field guide for people who design protocols, and it is the part where the primitives from earlier parts -- authenticated encryption, key derivation, elliptic curves, the KEM-DEM idea, digital signatures -- stop being separate ingredients and compose into a single shipped building block. By the end you will be able to look at any "encrypt to a recipient's public key" design and name, on sight, which of HPKE's modes it is using and which of HPKE's non-goals it is quietly assuming away.

The fix is so unglamorous it is tempting to skip straight to the API. Do not: the shape of HPKE is written in the failures of the four standards it replaced, and you cannot use it safely without seeing what "done right" was correcting. Start with the one idea all four were circling and none quite pinned down: the difference between encrypting a key and encapsulating one.

2. Encapsulate the Key, Do Not Encrypt It

RFC 9180 describes what it does differently in a single line, and that line is the whole conceptual pivot of this article. The traditional combination, it says, has been to "encrypt the symmetric key with the public key." HPKE instead will "generate the symmetric key and its encapsulation with the public key" [@rfc9180]. That one-word swap -- from encrypt to encapsulate -- is the difference between the padding-oracle-prone lineage that broke RSA key transport and a clean, composable, provable construction.

The traditional combination has been "encrypt the symmetric key with the public key." HPKE instead will "generate the symmetric key and its encapsulation with the public key." -- RFC 9180

Build the mental model in three moves. Derive only what the rest of the article needs.

Move one: KEM-DEM in one picture

The scheme standardized in RFC 9180 for encrypting arbitrary-length messages to a recipient's public key. It is built from three interchangeable ingredients -- a Key Encapsulation Mechanism (KEM), a Key Derivation Function (KDF), and an Authenticated Encryption with Associated Data (AEAD) scheme -- named together as a ciphersuite.

The word "hybrid" means it splits the work between public-key and symmetric cryptography, and the split follows the KEM-DEM pattern. The KEM does the public-key half; the DEM does the symmetric half.

A public-key primitive that does not transport a key you chose. Called with the recipient's public key, `Encap(pkR)` *generates* a fresh random shared secret together with an encapsulation `enc` of it, returning the pair `(shared_secret, enc)`. The recipient runs `Decap(skR, enc)` to recover the same shared secret. You never pick the key; the public-key operation produces it. The symmetric half of a hybrid scheme: an AEAD that bulk-encrypts the actual payload under a key derived from the KEM's shared secret. In HPKE the DEM is a single AEAD scheme, and its authenticity tag is intrinsic rather than bolted on.

If you have read Part 14 on getting RSA right, this is the same KEM-DEM skeleton, now instantiated on elliptic curves rather than RSA. The reason to generate the key rather than encrypt one is the entire lesson of that part: the moment you encrypt an attacker-influenced key under a public-key operation, you invite a decryption oracle to leak information one query at a time. A KEM removes the attacker's chosen input from the public-key step. There is nothing to pad, and nothing to probe.

flowchart TD subgraph LEFT["Encrypt the key (RSA and ElGamal key transport)"] A1["Choose a random symmetric key k"] --> A2["Encrypt k under the recipient public key"] A2 --> A3["Ship wrapped k plus the symmetric ciphertext"] end subgraph RIGHT["Encapsulate the key (KEM-DEM, HPKE)"] B1["Encap(pkR) generates a fresh shared secret"] --> B2["Returns shared_secret and enc together"] B2 --> B3["Derive keys, then AEAD-seal the payload"] end

Move two: DHKEM, concretely

HPKE's deployed KEM is Diffie-Hellman-based, and it is worth seeing the mechanism once rather than treating it as a black box.

HPKE's Diffie-Hellman-based KEM. `Encap(pkR)` generates an ephemeral key pair, computes a Diffie-Hellman value against the recipient's public key, and derives the shared secret from it; the encapsulation `enc` is the serialized ephemeral public key. The authenticated variants `AuthEncap`/`AuthDecap` additionally fold in a Diffie-Hellman value computed with the sender's *static* key.

Concretely, Encap(pkR) generates an ephemeral pair $(sk_E, pk_E)$, computes $\mathrm{DH}(sk_E, pk_R)$, sets enc to the serialization of $pk_E$, and returns shared_secret = ExtractAndExpand(dh, kem_context), where kem_context already contains both enc and the recipient key $pk_R$ [@rfc9180]. The recipient recomputes the identical Diffie-Hellman value as $\mathrm{DH}(sk_R, pk_E)$ and derives the same secret. This is exactly the ephemeral-static shape that DHIES introduced in the 1990s, now wearing a modern KDF -- and the decision to fold $pk_R$ into kem_context is the first appearance of the idea that later kills benign malleability.

sequenceDiagram participant S as Sender (holds pkR) participant R as Recipient (holds skR) Note over S: generate ephemeral pair skE, pkE Note over S: dh holds DH(skE, pkR) Note over S: enc holds Serialize(pkE) Note over S: shared_secret from ExtractAndExpand(dh, kem_context with enc and pkR) S->>R: send enc (the serialized ephemeral key) Note over R: dh holds DH(skR, pkE), the same value Note over R: recompute the identical shared_secret

Move three: the key schedule and the Context

The shared secret is not used directly. Both sides run it through a key schedule.

The HKDF Extract-then-Expand process that turns the KEM's `shared_secret` into working keys. It *extracts* a pseudorandom key from the shared secret (and, in PSK modes, the PSK), then *expands* that key over a context of the mode identifier, a hash of the pre-shared-key identifier (`psk_id_hash`), and a hash of the application `info` string (`info_hash`) to output the AEAD `key`, a `base_nonce`, and an `exporter_secret`. A symmetric primitive that provides confidentiality and integrity at once: it encrypts a plaintext and authenticates both the ciphertext and some associated data, so any tampering is detected on decryption. In HPKE it is the DEM that seals the payload; AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305 are the standard choices.

The HPKE key schedule is, quite literally, a worked example of the HKDF construction from Part 13: extract a pseudorandom key from the shared secret, then expand it into the specific bytes each downstream primitive needs. Its outputs assemble into a Context. The Context exposes Seal/Open -- a stateful pair in which an incrementing sequence number is combined with base_nonce (by exclusive-or) to give every message a distinct nonce -- and Export.

An HPKE interface that derives fresh, independent secrets of any length from the established context, for keying *other* protocols. It behaves as a variable-length pseudorandom function, so exported secrets are independent of the AEAD key and of each other. Oblivious HTTP and Oblivious DNS use it to key their own message framing instead of calling `Seal` directly.

For a single message you do not need to hold a Context open at all: the single-shot Seal/Open API wraps setup, one encryption, and teardown into one call. Everything above -- encapsulate, derive, seal -- is what those single-shot calls do underneath.

flowchart TD PKR["Recipient public key pkR"] --> ENCAP["Encap"] ENCAP --> SS["shared_secret"] ENCAP --> ENCV["enc (sent to recipient)"] SS --> KS["key_schedule (HKDF Extract-then-Expand)"] MODE["mode identifier"] --> KS PSK["psk_id_hash"] --> KS INFO["info_hash"] --> KS KS --> KEY["AEAD key"] KS --> NON["base_nonce"] KS --> EXP["exporter_secret"] KEY --> CTX["Context"] NON --> CTX EXP --> CTX CTX --> SEAL["Seal / Open (per-message nonce)"] CTX --> EXPORT["Export (key other protocols)"]

The structural model below is a toy, not real cryptography, but it lets you feel the difference from wrapping a chosen key: encap invents a random secret and its encapsulation, folds in the recipient's public key, and shows that a different recipient key yields a different secret from the same encapsulation.

{` // STRUCTURAL MODEL, NOT REAL CRYPTO. It only shows the SHAPE of "generate the key". function toyMix(str) { // a tiny non-cryptographic mixer let h = 2166136261 >>> 0; for (const ch of str) { h ^= ch.charCodeAt(0); h = Math.imul(h, 16777619) >>> 0; } return (h >>> 0).toString(16); } function randInt() { return Math.floor(Math.random() * 1e9); }

// Encap: the PUBLIC-KEY op GENERATES the shared secret. The caller never picks it. function encap(pkR) { const skE = randInt(); // fresh ephemeral secret const enc = 'pkE(' + skE + ')'; // its public value IS the encapsulation const dh = toyMix(enc + '|' + pkR); // stands in for DH(skE, pkR) // kem_context binds BOTH enc and pkR into the derivation -- the anti-malleability trick const shared_secret = toyMix('ss|' + dh + '|' + enc + '|' + pkR); return { shared_secret, enc }; }

const pkR = 'recipient-key-A'; const { shared_secret, enc } = encap(pkR); console.log('enc on the wire = ' + enc); console.log('shared_secret = ' + shared_secret);

// Same enc, a DIFFERENT recipient key -> a DIFFERENT secret. A swapped or mangled // public key simply cannot derive the key that decrypts, because pkR is bound in. const swapped = toyMix('ss|' + toyMix(enc + '|recipient-key-B') + '|' + enc + '|recipient-key-B'); console.log('same enc, key B = ' + swapped); console.log('secrets differ = ' + (swapped !== shared_secret)); `}

Now the payoff, and the first place your understanding should shift.

Key idea: Encapsulate, do not encrypt. Let the public-key operation generate the symmetric key and its encapsulation together (a KEM), then AEAD-encrypt under a derived key (a DEM). Because the composite is secure against chosen-ciphertext attack whenever both halves are, "encrypt to a public key" stops being an ad-hoc scheme you must re-prove each time and becomes a composition of two well-understood parts.

The modularity is the whole point. Cramer and Shoup proved in 2001 that a KEM and a DEM, each secure against chosen-ciphertext attack, compose into a hybrid scheme that is too [@cs01]; a few years later the converse was pinned down, showing both halves essentially have to be that strong for the composite to be [@hhk06]. Those results turn "is this encrypt-to-a-public-key scheme secure?" into two smaller, reusable questions.RFC 9180 notes in passing that its Base mode and the original Cramer-Shoup scheme are both "named HPKE" -- the name has KEM-DEM in its bones [@rfc9180], [@cs01].

Note: RFC 9180 is an Informational IRTF/CFRG document, not a Standards-Track one. Yet it is normatively required by Standards-Track protocols -- MLS (RFC 9420), Oblivious HTTP (RFC 9458), and Encrypted Client Hello (RFC 9849) all cite it as a mandatory dependency. Its category label undersells how much of the modern stack rests on it [@rfc9180].

This clean picture -- encapsulate, derive, seal -- looks obvious in hindsight. It was not. The KEM-DEM idea took two decades to take its final shape, and the Diffie-Hellman instantiation it rests on fragmented into the four broken standards from the last section before anyone consolidated it. To understand why HPKE makes the exact choices it does, walk the twenty-five years it is the endpoint of.

3. From "Encrypt the Key" to "Encapsulate the Key"

The story is a twenty-five-year march from encrypt the key to encapsulate the key, starting, as RFC 9180 notes, in the early days of public-key cryptography [@rfc9180]. Diffie and Hellman defined the idea of a public key in 1976 but did not say how to encrypt a long message to one [@dh76]. The answers accumulated in layers, each fixing the previous one's sharpest failure.

timeline title From encrypt-the-key to encapsulate-the-key, 1976 to 2026 1976 : Diffie and Hellman define public-key cryptography 1993 : PEM (RFC 1421) encrypts the content key under the recipient public key 1999 : DHIES derives the key from Diffie-Hellman instead of encrypting it 2001 : Cramer and Shoup formalize the KEM-DEM pattern 2009 : SEC 1 v2 completes the four-way ECIES split and names benign malleability 2022 : RFC 9180 consolidates KEM-DEM with proofs and test vectors 2026 : Post-quantum hybrid KEMs such as X-Wing drop into the KEM slot

PEM (RFC 1421, 1993): the traditional combination. Privacy Enhanced Mail defined the canonical early hybrid. Pick a content-encryption key, encrypt that key under the recipient's public key, and bulk-encrypt the message symmetrically. RFC 9180 opens by naming this exact tradition and positioning HPKE as the departure from it [@rfc1421], [@rfc9180]. It is the naive model most engineers still carry, and the one the previous section asked you to give up.

ElGamal (1985) and why Diffie-Hellman resists "encrypt a chosen key." ElGamal's public-key encryption predates the hybrid schemes and shows the friction directly [@elgamal85]. To "encrypt" a chosen symmetric key under a Diffie-Hellman public key, you must first encode that key as a group element, then pay a roughly twofold ciphertext expansion -- and the result is malleable rather than secure against chosen-ciphertext attack. That malleability is a reasoned inference here, anchored to DHIES's own claim to offer "stronger security properties than ElGamal," not a verbatim quote [@dhies_ms].

The RSA branch of the same idea failed even more loudly. Encrypting a chosen key under RSA with PKCS#1 v1.5 padding is precisely the construction that Bleichenbacher's attack turned into a decryption oracle, revived two decades later as ROBOT against nearly a third of the top 100 web domains [@rfc8017], [@robot_site], [@robot_eprint]. The part of this series on getting RSA right tells that story in full; both branches teach the same lesson: stop choosing a key and wrapping it.

DHIES and DHAES (Abdalla, Bellare, Rogaway, 1999): derive, do not encrypt. The academic root of ECIES made the decisive move. Instead of encrypting a key, run an ephemeral-static Diffie-Hellman exchange, push the result through a KDF to get an encryption key and a MAC key, then Encrypt-then-MAC the payload. No key is ever encrypted; it is agreed.

The authors proved the scheme secure against chosen-ciphertext attack under the Oracle Diffie-Hellman assumption, with "no random oracles involved," and called it "an attractive starting point for developing public-key encryption standards" [@dhaes], [@dhies_ms].DHIES has no single crisp date: the DHAES manuscript appeared as ePrint 1999/007 in 1999, was later renamed DHIES, and its formal analysis was published at CT-RSA 2001. Cite the range, not one year [@dhaes], [@dhies_ms]. That parenthetical -- "an attractive starting point for developing standards" -- turned out to be prophetic in the worst way.

Cramer and Shoup (2001): the modular abstraction. DHIES hinted at a structure; Cramer and Shoup formalized it. A KEM transports a random key, a DEM encrypts the payload, and the composite is secure against chosen-ciphertext attack if both halves are [@cs01]. A few years later the necessity direction was worked out: for the standard hybrid, both halves essentially have to reach that bar [@hhk06]. This is the theory HPKE would eventually standardize. It existed, complete, in 2001.

Note: By 2001 the field had both a clean, proof-backed academic scheme (DHIES) and the modular abstraction that made its security compositional (KEM-DEM). The striking fact about HPKE is not that someone invented a new idea in 2022. It is that the correct idea sat published and unadopted as a standard for two decades [@cs01], [@rfc9180].

So by 2001 everything HPKE needed already existed: a concrete, provably secure ephemeral-static scheme, and an abstraction that made "encrypt to a public key" a matter of plugging two proven pieces together. What happened over the following eight years was not progress. It was fragmentation. The same good idea was handed to four different standards bodies, and it came out four incompatible ways.

4. The ECIES Zoo

Between 2001 and 2009 the DHIES construction was standardized four times -- ANSI X9.63, IEEE 1363a, ISO/IEC 18033-2, and SEC 1 v2 -- collectively called ECIES, and collectively a mess that RFC 9180 politely calls "numerous competing and non-interoperable standards" [@rfc9180], [@maea10]. This is the hook's promise, paid off in detail. Three defects run through the era, and HPKE was built to close all three.

flowchart TD D["DHIES (Abdalla, Bellare, Rogaway)"] --> A["ANSI X9.63 (2001)"] D --> I["IEEE 1363a (2004)"] D --> S["ISO/IEC 18033-2 (2006)"] D --> C["SEC 1 v2 (2009)"] A --> Z["The ECIES zoo: incompatible KDFs, MACs, point encodings, no shared test vectors"] I --> Z S --> Z C --> Z Z --> H["RFC 9180 (2022): one construction, proven, test-vectored"]

Fragmentation: the "which ECIES?" problem. The four standards disagree on the key-derivation function, the MAC, whether elliptic-curve points are compressed or uncompressed, and whether the optional SharedInfo fields are present. So two conforming implementations often cannot interoperate: an ECIES ciphertext built with the ANSI X9.63 KDF and one built to ISO/IEC 18033-2, for the same curve and message, are byte-incompatible [@rfc9180], [@maea10].The concrete interoperability failure is not hypothetical: swap the KDF or the point-encoding convention between two of the four standards and a ciphertext valid under one is undecryptable under another, for identical inputs [@maea10].

The four standards -- ANSI X9.63 (2001), IEEE 1363a (2004), ISO/IEC 18033-2 (2006), and SEC 1 version 2 (2009) -- differ across enough independent knobs (KDF, MAC, point-encoding, `SharedInfo`) that "ECIES" names a family of mutually unintelligible dialects rather than one scheme. RFC 9180 points readers to the Gayoso Martinez et al. survey "for a thorough comparison." That survey and three of the four standards are paywalled, so this article cites them through RFC 9180's reference section rather than by live link [@rfc9180], [@maea10], [@sec1].

Benign malleability. SEC 1 version 2 documents a specific defect and then waves it off.

A property of the ECIES standards in which an attacker can transform a valid ciphertext into a different valid ciphertext for the *same* plaintext -- concretely, by replacing the ephemeral point $R$ with $-R$, which shares the same x-coordinate. SEC 1 called it "benign malleability" and "generally deemed harmless," and offered binding $R$ into `SharedInfo` only as an *optional* countermeasure. Because a ciphertext can be mauled into a second valid ciphertext, the scheme as written is not strictly secure against chosen-ciphertext attack [@sec1].

The word "benign" is doing a great deal of work. A scheme that lets anyone produce a second valid ciphertext for a plaintext they cannot read is, by definition, malleable, and malleability is exactly what security against chosen-ciphertext attack forbids. SEC 1 made the fix -- include $R$ in the hashed context -- optional. Hold that thought: it is the single design decision the next section shows HPKE making mandatory.

No proofs, and no test vectors. RFC 9180 is blunt about the state it inherited: prior schemes "rely on outdated primitives, lack proofs of IND-CCA2 security, or fail to provide test vectors" [@rfc9180]. The missing test vectors are not a documentation nicety. Without a published set of known-good inputs and outputs, two implementers have no way to discover that their libraries disagree until a ciphertext fails to decrypt in production -- which is precisely how "conformant" implementations drifted apart.

Note: The ECIES era is the standing proof that a primitive can be widely deployed and still be under-specified, unprovable, and mutually incompatible. "We implemented the standard" told you nothing about whether your ciphertext would decrypt on the other side, or whether the scheme met a modern security definition. Both had to be established separately, and neither was [@rfc9180], [@maea10].

The comparison below is the historical spine as a grid. Read the last two columns -- proof status and test vectors -- and the shape of the fix becomes obvious.

Approach	Core idea	Main weakness	Proof and test vectors	Status
RSA key transport (PKCS#1 v1.5)	Encrypt a chosen key under RSA	Padding oracle (Bleichenbacher, ROBOT)	No CCA2 proof; padding fragile	Deprecated in TLS 1.3
ElGamal encryption	Encode a chosen key as a group element	Malleable; roughly 2x expansion	No CCA2 proof	Historical
DHIES / DHAES	Derive the key from ephemeral-static DH	Underspecified as a deployable format	CCA2 proof (ODH); no shared vectors	Academic root of ECIES
ECIES (four standards)	Standardize DHIES	Fragmented; benign malleability	Proof gaps; no shared vectors	Legacy interop only
HPKE (RFC 9180)	KEM-DEM, all public keys bound in	Non-goals must be respected	IND-CCA2 proof; per-suite vectors	Current default
HPKE + X-Wing	Swap DHKEM for a hybrid PQ KEM	Larger ciphertexts; draft-stage	Hybrid PQ proof; draft vectors	Emerging

Every one of these defects points at the same missing discipline: pin one construction, bind the ambiguous inputs so malleability becomes impossible, prove the result, and publish vectors so anyone can check interoperation. That list is not a wishlist. It is, almost line for line, the changelog of RFC 9180. Here is what "done right" actually changed.

5. "Done Right" Was Discipline, Not Genius

There is no eureka moment in this story, and that is the point. HPKE's virtue is not a clever new algorithm -- the algorithm, KEM-DEM, was twenty years old when RFC 9180 shipped. Its virtue is four consolidating decisions, made once, correctly, with the proof and the test vectors published in the same body of work. Each decision closes one of the previous section's defects.

Decision one: abstract the KEM so the primitive is agile. Instead of freezing one curve, one KDF, and one MAC into a single scheme, HPKE is parameterized over a ciphersuite of three identifiers: kem_id, kdf_id, and aead_id [@rfc9180]. This looks like a small thing and is not. Fragmentation was the disease of the ECIES era, where each standards body froze a different combination.

HPKE replaces uncontrolled fragmentation with managed agility: many ciphersuites, but one construction and one set of rules governing all of them. When a component needs replacing -- as the post-quantum transition will require -- you change an identifier, not the scheme.

Decision two: bind every public key into the key schedule. This is the decisive fix, and RFC 9180 states it in one sentence.

"HPKE mitigates malleability problems (called benign malleability) in prior public key encryption standards based on ECIES by including all public keys in the context of the key schedule." -- RFC 9180, Section 9.1

What SEC 1 made optional, HPKE makes mandatory [@rfc9180], [@sec1]. Recall the benign-malleability trick: replace the ephemeral point $R$ with $-R$ to get a second valid ciphertext. In HPKE the public keys are inputs to the derived keys, so a mauled encapsulation derives a different key schedule and simply fails to produce a valid decryption. The attack does not become hard; it becomes impossible to express. The malleability is not patched -- it is designed out.

Decision three: mandate a single AEAD as the DEM. Gone is the ad-hoc two-key Encrypt-then-MAC with per-standard knobs for the cipher, the MAC, and the tag order. HPKE specifies one AEAD scheme per ciphersuite, so authenticity is intrinsic to the primitive rather than assembled by the caller [@rfc9180]. If the series' part on safe authenticated-encryption composition has a single thesis -- compose it wrong and the tag verifies while the forgery goes through -- then HPKE is simply that "compose it correctly" rule frozen into a specification.

Decision four: ship proofs and test vectors, developed alongside the standard. This is the part the ECIES era never had. HPKE began as an individual draft in 2019 and was analyzed as it was written [@hpke_draft]. Lipp's CryptoVerif analysis mechanically checked all four modes; the analysis by Alwen, Blanchet, Hauck, Kiltz, Lipp, and Riepel gave exact security bounds for the authenticated mode and was published at EUROCRYPT 2021; and the two pre-shared-key modes were later closed under the Gap Diffie-Hellman assumption [@lipp20], [@abhklr20], [@psk1480]. Every ciphersuite ships machine-checkable test vectors in the RFC itself [@rfc9180].

The standard security goal for public-key encryption. An adversary who may submit ciphertexts of its choice to a decryption oracle -- adaptively, even after seeing the challenge -- still cannot tell which of two chosen plaintexts a challenge ciphertext encrypts. It is the bar the ECIES standards could not prove and that malleability violates, and the bar HPKE's composition meets when its KEM and AEAD do [@cs01], [@hhk06].

Put the four together and your sense of what happened should shift.

Key idea: "Done right" was consolidation, not invention. Abstract the KEM for agility, bind every public key into the key schedule so benign malleability cannot happen, mandate one AEAD instead of ad-hoc Encrypt-then-MAC, and ship machine-checked proofs and per-ciphersuite test vectors in the same document. The innovation is rigor -- which is exactly why HPKE is boring, and why boring is the achievement.

Note: The KEM-DEM theory was published in 2001 and simply not adopted as the standard until 2022. HPKE is the merge of a two-decade-old proof track with a standards track: it did not out-think the ECIES authors so much as out-discipline them, pinning one construction and refusing to ship it without proofs and vectors [@cs01], [@rfc9180].

There is even a small tell that HPKE was designed to be built on, not just used directly.HPKE reserves an export-only AEAD identifier (the value 0xFFFF) for ciphersuites that never call Seal and only ever use the Export interface -- a strong hint that the authors expected HPKE to be keyed into other protocols rather than used standalone [@rfc9180].

Four decisions turn a fragmented, unprovable family into one boring, correct primitive. But "one primitive" is not "one behavior." HPKE ships a small menu -- four modes -- and choosing the wrong one is the first and most common way to misuse it. The menu is where the design stops being about the math and starts being about what you are trying to authenticate.

6. The Four Modes: HPKE's Core Menu

RFC 9180, Section 5.1, defines exactly four modes, and the difference between them reduces to a single question: what extra secret or identity gets folded into the key schedule? Get the answer wrong and you either fail to authenticate a sender you needed to, or -- worse -- come to believe you authenticated one you did not [@rfc9180]. There are four modes, never three: the pre-shared-key-plus-authenticated combination is a real, distinct mode that is easy to forget.

Mode	ID	Extra input	What it authenticates	Use when
`mode_base`	0x00	none	Only that the ciphertext is for this recipient key	You have just the recipient's public key
`mode_psk`	0x01	a pre-shared key	Recipient, plus possession of the PSK	A symmetric secret already exists out of band
`mode_auth`	0x02	sender's static key	That a specific sender key holder sent it	The recipient must know which sender key sealed it
`mode_auth_psk`	0x03	static key and PSK	Both a sender identity and PSK possession	You need sender identity and a shared secret

mode_base (0x00): nothing extra. The sender is anonymous; the derivation authenticates only that the ciphertext was sealed to this recipient's key. It is the default -- and, tellingly, the mode that every flagship deployment in the next section uses.

mode_psk (0x01): a pre-shared key. A symmetric secret known to both parties is folded into the schedule, so a valid decryption additionally proves the sender possessed the PSK.

Note: mode_psk authenticates possession of the PSK, which means a weak PSK is an authentication that anyone who guesses it can forge. RFC 9180 requires a PSK with at least 32 bytes of entropy, and the reason is not arbitrary: a low-entropy PSK opens a partitioning-oracle attack that the non-goals section quantifies. Treat the PSK as key material, never as a human-chosen secret [@rfc9180].

mode_auth (0x02): the sender's static key. Here Encap/Decap are replaced by AuthEncap/AuthDecap, which fold a Diffie-Hellman value between the sender's static key and the recipient into the shared secret. A valid decryption now proves the message came from the holder of that specific sender key [@rfc9180].

mode_auth_psk (0x03): both. A static sender identity and a shared secret, folded together.

flowchart TD B["mode_base 0x00: nothing extra"] --> KS["key_schedule context"] P["mode_psk 0x01: plus a pre-shared key"] --> KS A["mode_auth 0x02: plus sender static key via AuthEncap"] --> KS AP["mode_auth_psk 0x03: plus PSK and sender static key"] --> KS KS --> OUT["Same construction, four different derived key schedules"]

Now the subtlety that trips up careful engineers. The authenticated modes are a form of signcryption, and they carry a security distinction imported from that theory.

A primitive that combines encryption and sender authentication in one operation, cheaper than encrypt-then-sign. Its authentication is defined relative to *insiders* and *outsiders*: an outsider is any third party, while an insider is a party who holds one of the long-term keys. HPKE's authenticated modes are signcryption, so their guarantees are stated in these terms rather than as a public, third-party-verifiable signature.

The consequence matters: mode_auth is not a digital signature. Because the recipient shares the Diffie-Hellman secret that authenticated the sender, the recipient could have produced the same ciphertext, so it cannot prove to any third party who the author was -- there is no non-repudiation. The analysis by Alwen, Blanchet, Hauck, Kiltz, Lipp, and Riepel makes this precise with an insider-versus-outsider treatment lifted from signcryption theory [@abhklr20], [@signcryption]. If you want a third party to verify authorship, you want the digital-signature part of this series, not HPKE's auth mode.

The security properties proven for each mode, from RFC 9180's Table 6 via Lipp's mechanized analysis, are worth seeing side by side [@rfc9180], [@lipp20]:

Property	Base	PSK	Auth	AuthPSK
Message confidentiality (IND-CCA2)	Yes	Yes	Yes	Yes
Export secrecy (variable-length PRF)	Yes	Yes	Yes	Yes
Sender authentication	N/A	Yes	Yes	Yes
Extra secret assumed	recipient key secret	plus PSK secret	plus sender key secret	plus sender key and PSK

The structural model below makes the "same machinery, different inputs" claim concrete: it builds a stand-in key-schedule context for each mode and shows the derived key differs, though nothing about the construction changed.

{` // STRUCTURAL MODEL, NOT REAL CRYPTO. Shows only that mode changes the derived key. function toyMix(s){let h=2166136261>>>0;for(const ch of s){h^=ch.charCodeAt(0);h=Math.imul(h,16777619)>>>0;}return (h>>>0).toString(16);} const shared_secret = 'ss-from-KEM';

// Real HPKE: Extract a PRK from shared_secret, then Expand over mode + psk_id_hash + info_hash. // This toy just mixes them (plus the sender key for auth modes) to show the mode changes the key. function keySchedule(mode, pskId, senderKey) { const psk_id_hash = toyMix('pskid:' + (pskId || '')); const info_hash = toyMix('info:my-app-v1'); const ss = senderKey ? toyMix(shared_secret + '|auth:' + senderKey) : shared_secret; return toyMix(mode + '|' + psk_id_hash + '|' + info_hash + '|' + ss); }

console.log('base -> ' + keySchedule('0x00', null, null)); console.log('psk -> ' + keySchedule('0x01', 'shared-psk', null)); console.log('auth -> ' + keySchedule('0x02', null, 'sender-static-key')); console.log('auth_psk -> ' + keySchedule('0x03', 'shared-psk', 'sender-static-key')); console.log('all four derive different keys from identical machinery'); `}

Choosing a mode answers "who am I authenticating?" It says nothing about which curve, which KDF, which AEAD, and how not to shoot yourself with the nonce. That is the ciphersuite-and-usage layer -- where the test vectors finally earn their keep, and where the known HPKE implementation advisories actually live.

7. Ciphersuites and Correct Usage

A mode plus a ciphersuite is a complete HPKE configuration. The ciphersuite is three identifiers -- a KEM, a KDF, and an AEAD -- and the correct-usage rules are mostly about a single thing: never let the same nonce protect two messages.

Slot	Options	How to choose
KEM	DHKEM(X25519, HKDF-SHA256); DHKEM(P-256/P-384/P-521, HKDF-SHA256/384/512); DHKEM(X448, HKDF-SHA512)	X25519 unless policy requires NIST curves; encapsulation `enc` is 32 bytes for X25519, 65 for P-256
KDF	HKDF-SHA256, HKDF-SHA384, HKDF-SHA512	Match the KDF hash to the KEM and AEAD strength
AEAD	AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305, Export-only (0xFFFF)	AES-GCM with AES hardware; ChaCha20-Poly1305 without; export-only when you never call `Seal`

The three menus map onto earlier parts of this series. DHKEM's curves are the elliptic curves of the curves part; pick X25519 for new designs, NIST curves only when a compliance regime demands them. The KDF slot is the HKDF of the key-derivation part, used exactly as designed. The AEAD slot is the decision from the AEAD part: AES-GCM where the CPU has AES instructions, ChaCha20-Poly1305 where it does not. The tag is 16 bytes in every case.

The nonce and sequence discipline is the crux. Inside a Context, the per-message nonce is computed as nonce = base_nonce XOR seq, where seq is an incrementing sequence number. The Context is therefore stateful, and the sequence number must never repeat and must never overflow, because AEAD nonce reuse is catastrophic: for AES-GCM it can leak the authentication key, and for any of these AEADs it breaks confidentiality outright [@rfc9180]. This is the same hazard the nonce-reuse part of this series covers for AES-GCM, arriving here as a counter you must not let wrap.

The structural model below computes a few per-message nonces and then deliberately overflows a narrow counter so you can watch a nonce repeat -- which is, in miniature, exactly the implementation bug the misuse section names.

{` // STRUCTURAL MODEL, NOT REAL CRYPTO. Toy 8-bit nonce; real HPKE nonces are 96 bits. const base_nonce = 0xA7; function nonceFor(seq) { return (base_nonce ^ (seq & 255)).toString(16); }

for (let seq = 0; seq !== 5; seq++) { console.log('seq ' + seq + ' -> nonce ' + nonceFor(seq)); }

// A deliberately NARROW counter overflows after 256 messages and REPEATS a nonce. const width = 256; const seqA = 3; const seqWrap = seqA + width; // a later message with the same low 8 bits console.log('seq ' + seqA + ' -> nonce ' + nonceFor(seqA)); console.log('seq ' + seqWrap + ' -> nonce ' + nonceFor(seqWrap) + ' (wrapped)'); console.log('nonce reused after overflow = ' + (nonceFor(seqA) === nonceFor(seqWrap))); `}

Note: Prefer single-shot Seal/Open for independent messages -- it sets up, encrypts once, and tears down, so there is no counter to mismanage. If you hold a Context open, Seal strictly in order, respect the per-ciphersuite AEAD message-count and input-length limits, and never reuse a Context across two independent streams. A repeated or overflowed sequence number is a repeated nonce, and a repeated nonce is the end of your confidentiality [@rfc9180].

Two operational notes round out the usage rules. First, the AEAD message-count and plaintext-length limits are per-ciphersuite constants, and single-shot Seal/Open sidesteps the streaming bookkeeping entirely.When you need to protect many messages or key a different protocol's framing, use the Export interface to derive an independent secret rather than looping Seal on one long-lived Context -- this is exactly what Oblivious HTTP and Oblivious DNS do [@rfc9180]. Second, the one default to remember: mode_base with DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, and AES-128-GCM is the interop-safe choice, with ChaCha20-Poly1305 substituted on hardware without AES acceleration.

These rules read like an interop checklist because that is precisely what they are, and the only reason they can be a checklist is the test vectors: you can prove your library agrees with the specification byte for byte before you ship. But a checklist for using HPKE says nothing about where it has already won. The strongest evidence that HPKE is the right default is that the modern privacy stack is built on it.

8. Deployments as the Proof

The best argument that HPKE is state of the art in 2026 is not a benchmark. It is a deployment list. Every "encrypt to a party you have never spoken to" corner of the modern IETF stack runs on HPKE, and they almost all run on the same mode.

Deployment	Specification	What HPKE does	Mode and API
Encrypted Client Hello	RFC 9849 (2026)	Encrypts the inner ClientHello, including the server name	`mode_base`, `SetupBaseS`/`SetupBaseR`
Messaging Layer Security	RFC 9420 (2023)	Encrypts path secrets to tree nodes in TreeKEM	`mode_base`, `SealBase`
Oblivious HTTP	RFC 9458 (2024)	Encapsulates requests and responses to a gateway	`mode_base` plus `Export`
Oblivious DNS over HTTPS	RFC 9230 (2022)	Encrypts DNS queries to a target through a proxy	`mode_base` plus `Export`

Encrypted Client Hello. ECH encrypts the sensitive inner ClientHello -- including the server name a censor would want to read -- to the server's HPKE public key, published in an ECHConfig and fetched ahead of time. It uses SetupBaseS on the client and SetupBaseR on the server [@rfc9849].Currency pin: ECH is now Standards-Track RFC 9849, published in March 2026 by Rescorla, Oku, Sullivan, and Wood, and formerly known as draft-ietf-tls-esni. It is an RFC, not a draft, and its text references HPKE throughout [@rfc9849].

Messaging Layer Security. MLS uses HPKE inside TreeKEM: when a group member updates the ratchet tree, it encrypts the new path secrets to the public keys of the relevant tree nodes, using SealBase [@rfc9420]. Group-scale forward secrecy and post-compromise security come from the tree and the ratchet, not from HPKE.

Oblivious HTTP and Oblivious DNS. Both split trust between a relay and a gateway so that no single party sees both who you are and what you asked. The client seals its request to the gateway's HPKE key; the relay forwards ciphertext it cannot read; the gateway decapsulates and, crucially, uses Export to key the response rather than looping Seal [@rfc9458], [@rfc9230]. Oblivious DNS, in 2022, was the first shipped RFC deployment of HPKE.

flowchart LR C["Client seals request with SetupBaseS"] --> REL["Relay sees ciphertext and client address, not content"] REL --> GW["Gateway runs SetupBaseR, decrypts, Export-keys the reply"] GW --> TGT["Target sees the request, never the client address"]

Privacy Pass and its Private Access Tokens belong on the list too, at one remove: some deployments run token issuance over Oblivious HTTP (RFC 9578 does not require it), and therefore over HPKE [@rfc9578], [@rfc9458].

Two observations reinforce the article's spine. First, every marquee deployment uses mode_base: sender authentication and forward secrecy are supplied at the protocol layer -- by the TLS handshake, by the MLS ratchet -- leaving HPKE to be the boring sealing primitive it was designed to be. Second, Oblivious HTTP and Oblivious DNS reach for Export to key their own framing instead of looping Seal, exactly the extensibility the export interface was built for. The deployments did not stretch HPKE; they used the parts the design anticipated.

DHKEM is classical-only, which means every HPKE ciphertext sealed today is exposed to "harvest now, decrypt later": an adversary can store it and decrypt it once a quantum computer can solve the elliptic-curve Diffie-Hellman problem. The fix is the payoff of Decision one -- swap the KEM, do not redesign HPKE. The leading candidate is X-Wing, a hybrid KEM combining X25519 and ML-KEM-768 that stays secure if *either* component holds, and it comes with a dedicated "Use in HPKE" mapping [@xwing], [@xwing_draft], [@fips203]. The cost is size: an X-Wing encapsulation is roughly 1120 bytes against 32 for DHKEM(X25519) [@xwing_draft06]. Draft-stage ciphersuites also include a pure ML-KEM option, a generic hybrid-KEM framework, and a combined post-quantum suite with a SHA-3-based KDF [@mlkem_draft], [@hybrid_draft], [@barnes_pq]. One caveat matters for the modes section: X-Wing is *not* an authenticated KEM, so the post-quantum path powers `base` and `psk` but not yet `auth` or `auth_psk` [@xwing_draft06].

HPKE won the IETF privacy stack. But "won" invites the question a careful engineer actually asks: won against what, and when would I still reach for something else? The honest comparison comes next -- along with the one construction people keep miscategorizing as HPKE.

9. Competing Approaches, and One That Is Not HPKE

HPKE is the right default for new protocol design, but it is not the only encrypt-to-a-public-key tool, and it is not always the right one. Because all of these building blocks cost about the same -- roughly two elliptic-curve scalar multiplications for the sender, plus an ephemeral value and an AEAD tag of overhead -- the honest comparison is not speed. It is security model, agility, and proof discipline.

Tool	Construction	Agility and modes	Proof and shared vectors	Best suited for
HPKE (RFC 9180)	KEM-DEM (DHKEM + KDF + AEAD)	Full agility; four modes	Machine-checked; per-suite vectors	New protocol design
libsodium `crypto_box` / seal	Fixed X25519 + XSalsa20-Poly1305	None; mutual-auth, repudiable	No mechanized proof; partial vectors	Both ends yours, zero knobs
JOSE `ECDH-ES` (RFC 7518)	Ephemeral-static ECDH + Concat KDF	Some agility; encryption only	No mechanized proof; partial vectors	JWE and JWT stacks
`age`	X25519 + HKDF-SHA256 + ChaCha20-Poly1305	None; file-oriented	No mechanized proof; has vectors	Encrypting files to a key
Raw ECIES	Ephemeral-static ECDH + Encrypt-then-MAC	Per-standard knobs	Proof gaps; no shared vectors	Legacy and blockchain interop

libsodium crypto_box and sealed boxes. One fixed suite -- X25519, XSalsa20, Poly1305 -- simple and misuse-resistant, but with no agility, no formal mode menu, and no HPKE-grade test vectors; raw crypto_box also makes the caller manage nonces, and it is deliberately repudiable and mutually authenticated [@nacl]. Reach for it when you own both ends and want zero knobs.

JOSE and COSE ECDH-ES. Ephemeral-static ECDH with the Concat KDF, native to JWE and JWT [@rfc7518]. It has no auth or psk modes, uses Concat-KDF rather than HKDF, and ships nothing like HPKE's vectors. It is chosen by platform gravity, and a COSE-HPKE binding is emerging to bring HPKE into that world [@cose_hpke].

age. Wraps a random file key to X25519 recipients with HKDF-SHA256 and ChaCha20-Poly1305 -- the same primitive family as DHKEM(X25519) plus an AEAD, but fixed and file-oriented [@age]. Reach for it to encrypt files to a public key.

Raw ECIES survives only for interop with existing deployments, such as blockchain wallets and legacy PKI [@sec1]. And RSA-KEM (RFC 5990) is worth one line: it proves the KEM-DEM pattern generalizes beyond Diffie-Hellman, but RFC 9180 defines no RSA-KEM ciphersuite, so it stays a niche [@rfc5990].

Now the boundary marker, because it is the single most common miscategorization in this space.

Apple's PQ3 protocol for iMessage is *KEM-based* -- as Apple describes it, the design combines a hybrid post-quantum KEM (ML-KEM/Kyber-1024 with P-256 ECDH) through HKDF-SHA384, inside a triple-ratchet message scheme [@apple_pq3] -- but it is **not** an RFC 9180 HPKE deployment, and it never invokes HPKE. It solves a different problem: stateful, forward-secret, *interactive* messaging with post-compromise security, where HPKE is single-shot public-key encryption to a static key. PQ3 belongs here only to mark the single-shot-versus-ratchet boundary and to keep it off the HPKE deployment list, where it does not belong. Do not cite it as evidence that HPKE ships in iMessage; it does not.

The ranking has a pattern. The fixed-suite tools win on simplicity, ECDH-ES wins on platform gravity, and everything else loses to HPKE for new design, because HPKE has the agility, the modes, the proofs, and the vectors. That makes HPKE sound like a strict upgrade. It is not. Its power comes from a set of things it deliberately refuses to do -- and mistaking those refusals for oversights is where every real HPKE incident begins.

10. The Refusals That Look Like Features

HPKE's non-goals are not gaps someone forgot to fill. Several are impossibilities for a single-shot public-key primitive, and RFC 9180 states them plainly so that no one mistakes the boundary for a bug. Knowing them is the entire discipline this article is teaching.

No forward secrecy against recipient compromise, in any mode. RFC 9180 is explicit: HPKE ciphertexts "are not forward secret with respect to recipient compromise in any mode," because only long-term secrets are used on the recipient's side [@rfc9180]. This is structural, not an oversight.

The property that compromising a long-term key does not expose past messages. HPKE has none with respect to recipient compromise: because a single-shot ciphertext is encrypted to a static recipient key, anyone who later obtains that key can decrypt every ciphertext ever sent to it. Forward secrecy must come from a ratchet or key rotation *outside* HPKE -- which is exactly why MLS and TLS layer it on top.

auth mode is not a signature. As the modes section showed, the authenticated modes are signcryption with insider and outsider guarantees, not third-party non-repudiation. The recipient who shares the Diffie-Hellman secret could have produced the same ciphertext, so it cannot prove authorship to anyone else [@abhklr20], [@rfc9180]. If you need a portable proof of who signed, use a digital signature.

Not key-committing by default. HPKE's AEADs bind a ciphertext to a plaintext, but not to a unique key.

A property by which a ciphertext can be opened successfully under exactly one key. HPKE's standard AEADs are not key-committing by default, which enables a partitioning-oracle attack: an attacker who can submit ciphertexts and observe success or failure can binary-search a low-entropy secret. The eventual fix is a committing AEAD, whose properties are codified in RFC 9771 [@aead_props].

The concrete danger is a low-entropy PSK. RFC 9180, applying the partitioning-oracle result of Len, Grubbs, and Ristenpart, notes that an attacker can recover a PSK drawn from a set of size $m \cdot k$ in roughly $m + \log k$ oracle queries [@rfc9180], [@lgr20]. That logarithmic search is precisely why the PSK requirement is a floor on entropy, at least 32 bytes, and not a note about password strength. The committing-AEAD countermeasure is standardized as a set of properties in RFC 9771, awaiting a committing aead_id [@aead_props].

No replay, reordering, downgrade, or metadata protection. HPKE does not detect a replayed ciphertext, enforce message ordering across independent contexts, prevent ciphersuite downgrade, or hide the length or existence of a message. Every one of these is deliberately left to the surrounding protocol [@rfc9180].

Classical-only by default. This is the single primitive-level gap -- and, as the deployment section showed, the only non-goal you close by swapping a component rather than redesigning the scheme.

It is worth being precise about what is and is not finished. The core security question is closed: sufficiency and necessity together establish that the KEM-DEM composite reaches IND-CCA2 exactly when its halves do, and all four modes have been machine-checked [@cs01], [@hhk06], [@lipp20], [@abhklr20], [@psk1480].

The residual gaps are about model and API coverage, not the core: the tightest authenticated-mode proof covers single-shot use rather than many messages, some results live in the random-oracle model rather than the standard model, and the post-quantum composition result is tightest for the authenticated mode, with the psk and auth_psk modes since covered by the PSK-modes analysis and a fully general standard-model post-quantum proof across all four modes still open [@abhklr20], [@psk1480]. Even the definition of IND-CCA for KEMs has known subtleties the analyses had to navigate [@rfc9180], [@bhk09].

Key idea: The math is finished; the risk moved to the interface. HPKE has no known catastrophic break, so its hazards are misuse of its four modes and its non-goals -- and the post-quantum swap, which changes the KEM and not the scheme, is the proof that the architecture was the achievement. The discipline is knowing what HPKE deliberately does not do.

Note: HPKE's most important non-goals look like features waiting to be used: there is no forward secrecy against recipient compromise in any mode, auth is not a signature, and the AEADs are not key-committing. Assuming any one of the three is present is where real incidents begin [@rfc9180].

Every non-goal above is a sentence a designer might wrongly assume was a yes. So the honest failure catalog for HPKE is not a list of broken math -- there is none -- it is a list of those wrong assumptions, made in real code. Here they are, named.

11. The Failure and Misuse Catalog

HPKE itself has no known catastrophic real-world break, and that absence is the finding, not a gap in the research. This is a deliberately hedged absence-of-evidence claim: it rests on three machine-checked analyses and on the public advisories to date being implementation bugs, not design flaws -- never a claim that HPKE is "proven secure" for all time [@lipp20], [@abhklr20], [@psk1480]. The catalog is two things: the predecessor ECIES defects HPKE fixed, and the misuse patterns that appear when a non-goal is assumed away.

Misuse	Root cause	Non-goal assumed away	Fix or lesson
Sequence counter overflow	Fixed-width counter wraps, nonce repeats	AEAD nonce uniqueness is the caller's job	Wide counter; single-shot; the hpke-rs `u64` fix
Static-key forward-secrecy illusion	Expecting past secrecy from a static key	No FS against recipient compromise	Ratchet or rotate keys above HPKE
Low-entropy PSK	Guessable PSK enables partitioning oracle	AEADs are not key-committing	PSK with at least 32 bytes of entropy
Bad ephemeral randomness	Weak CSPRNG in `Encap`	HPKE assumes good randomness	Use a vetted CSPRNG
`auth` treated as a signature	Insider can forge to a third party	`auth` is signcryption, not non-repudiation	Use a digital signature for authorship
Out-of-order or reused `Open`	Ordering not enforced by HPKE	No reordering or replay protection	`Seal` in order; put ordering in the AAD
Export-only misuse	Calling `Seal` on an export-only suite	Interface contract not enforced	Error, do not truncate; the hpke-rs fix

The first advisory: hpke-rs, GHSA-g433-pq76-6cmf. In February 2026 the hpke-rs and hpke-rs-rust-crypto crates received a high-severity advisory bundling four fixes, and the reason it vindicates this article's spine rather than refuting it is that every fix maps onto a non-goal RFC 9180 had already flagged [@ghsa], [@rfc9180], [@hpke_rs]:

Sequence-number overflow leading to nonce reuse. The context counter could overflow; the fix widened it to a 64-bit integer. This is exactly the scenario the earlier structural model wraps in miniature, and exactly the AEAD nonce-uniqueness hazard the usage section warned about. It was reported by Kobeissi.
Export-only misuse and silent truncation. Calling Seal/Open on an export-only suite, and requesting an over-long Export, previously truncated silently; both now return errors. Reported by Arciszewski.
Missing X25519 zero and low-order key check. The library did not reject all-zero keys; it now errors on them, closing a small-subgroup foot-gun.
A post-quantum KEM-identifier mapping bug. A confusion in the draft X-Wing KEM-id mapping -- harmless in effect, but a foretaste of the ciphersuite-management care the post-quantum transition will demand.

The second advisory: @hpke/core / hpke-js, CVE-2025-64767. Three months earlier, in November 2025, the @hpke/core package -- the core of the hpke-js library in the survey below -- drew a critical advisory (GHSA-73g8-5h73-26h4, CVSS 9.1) for reusing AEAD nonces. The root cause was a concurrency race rather than a counter overflow: the public SenderContext Seal() API let two concurrent asynchronous seal() calls read the same sequence number, so both derived the same nonce and reused it in the AEAD, forfeiting confidentiality and integrity outright. Versions @hpke/core 1.7.4 and earlier are affected; the fix shipped in 1.7.5. The lesson is the misuse table's first row reached from a new direction -- nonce uniqueness is the caller's job -- so a single Context must never have Seal called on it concurrently: serialize per-context sealing, or prefer single-shot. It is a second, independent instance of the exact nonce-reuse hazard the usage section named, arrived at by a race instead of an overflow [@hpke_core_cve], [@rfc9180], [@hpke_js].

Notice what is not on either advisory: no broken cipher, no discrete-log break, no flaw in the KEM-DEM composition -- only dropped or mishandled checks and a concurrency race, each mapping onto a non-goal or requirement the specification had already named.

The rest of the catalog is misuse in application code, and it maps onto the table above. Expecting forward secrecy from a static recipient key yields none, in any mode [@rfc9180]. A low-entropy PSK turns mode_psk into a partitioning oracle, so the PSK needs at least 32 bytes of entropy [@rfc9180], [@lgr20]. Bad ephemeral randomness can collapse base-mode confidentiality outright, because a predictable ephemeral key undoes the encapsulation.

Treating auth as a signature walks into the insider-versus-outsider trap [@abhklr20], and out-of-order Open or context reuse breaks because applications, not HPKE, must preserve Seal order and put ordering in the associated data [@rfc9180]. The predecessor ECIES defects -- benign malleability, missing proofs, missing test vectors -- round out the list, each already closed by the four design decisions.

HPKE has no catastrophic break because the risk moved up a layer. Master the four modes and the non-goals and you have a boring, safe default. The math held; the risk moved to the interface.

Read the catalog back to front and a single pattern falls out: every entry is a non-goal treated as a goal, or an implementation dropping a check the specification demanded. None is a broken cipher. That means the "how to use HPKE safely" guide is not a research problem. It is the non-goals, turned into rules.

12. A Practical Decision Guide

Everything above collapses into a short decision procedure and a shorter list of things never to do.

flowchart TD START["Encrypt to a public key"] --> Q1{"New protocol needing agility, modes, proofs?"} Q1 -->|Yes| HPKE["Use HPKE"] Q1 -->|No| Q2{"Both ends yours, zero knobs?"} Q2 -->|Yes| BOX["libsodium sealed box"] Q2 -->|No| Q3{"JWE or JWT stack?"} Q3 -->|Yes| JOSE["ECDH-ES, or COSE-HPKE as it matures"] Q3 -->|No| Q4{"Encrypting files?"} Q4 -->|Yes| AGE["age"] Q4 -->|No| ECIES["Matched ECIES, legacy interop only"] HPKE --> M{"Which mode?"} M -->|Only the recipient key| BASE["mode_base"] M -->|A shared secret exists| PSK["mode_psk, PSK at least 32 bytes"] M -->|Need a sender identity| AUTH["mode_auth"] M -->|Both| AUTHPSK["mode_auth_psk"]

Which building block? A new protocol or standard that needs agility, proofs, and modes takes HPKE. Both ends under your control with no options wanted takes a libsodium sealed box. The JWE and JWT world takes ECDH-ES, or COSE-HPKE as it matures [@cose_hpke]. Encrypting files takes age. Interop with an existing ECIES deployment takes a matched ECIES configuration and nothing new [@rfc9180].

Which HPKE mode? Only the recipient's public key in hand: mode_base, the deployment default. A pre-shared secret already exists: mode_psk, with a PSK carrying at least 32 bytes of entropy. The recipient must know that a specific sender key sealed the message: mode_auth. Both a sender identity and a shared secret: mode_auth_psk. Never reach for an authenticated mode expecting a third-party-verifiable signature.

Which ciphersuite? The interop-safe classical default is DHKEM(X25519, HKDF-SHA256) with HKDF-SHA256 and AES-128-GCM, substituting ChaCha20-Poly1305 where AES is unaccelerated. If you only ever export, use the export-only AEAD (0xFFFF). If you are planning for quantum resistance, track the X-Wing and ML-KEM drafts, budget roughly 1.1 KB per encapsulation, and remember that the post-quantum suites give you base and psk but not yet auth [@xwing_draft06].

A worked path to shipping. Start with a single-shot Seal/Open for one message, which removes the entire counter-management problem. Reach for Export only when you are keying another protocol's framing. And before you trust your integration, reproduce one of RFC 9180's published test vectors end to end: if your library produces the specified bytes, you have proof it interoperates -- the very check the ECIES era could not run. The mature libraries below make this easy.

Library	Language	Notes
OpenSSL 3.2+	C	Native HPKE via `OSSL_HPKE_CTX` [@openssl_blog], [@openssl_api]
BoringSSL	C	HPKE used in the Chrome and ECH stack [@boringssl]
Cloudflare CIRCL	Go	Early production HPKE; powers OHTTP and ODoH [@cloudflare]
rust-hpke	Rust	RFC 9180-conformant crate [@rust_hpke]
hpke-rs	Rust	Formally oriented; ships a draft X-Wing KEM id [@hpke_rs]
hpke-js	JavaScript	Browser, Node.js, and Deno; full RFC 9180 suites; require `@hpke/core` 1.7.5 or later (fixes CVE-2025-64767) [@hpke_js], [@hpke_core_cve]

Note: Use mode_base single-shot with DHKEM(X25519, HKDF-SHA256), HKDF-SHA256, and AES-128-GCM -- or ChaCha20-Poly1305 without AES hardware. Use Export to key your own framing rather than looping Seal. Track X-Wing and ML-KEM for the post-quantum transition, and budget about 1.1 KB per encapsulation when it lands [@rfc9180], [@xwing_draft06].

The list of nevers is short and worth memorizing: never expect forward secrecy from a static recipient key; never treat auth as a signature; never reuse a Context across independent streams or let the sequence counter overflow; never use a low-entropy PSK; never open one ciphertext under multiple keys and assume it committed to one; and never skip your library's test-vector check.

Run your library against RFC 9180's Appendix A vectors for the exact ciphersuite you ship. A mismatch on the first byte tells you -- before any traffic flows -- that your point encoding, your `info` handling, or your KDF wiring disagrees with the standard. This is the single check the four ECIES standards could never offer, and it is the reason "conformant" now implies "interoperable."

The checklist is short because the lesson is one sentence. Before restating it, clear away the confident-but-wrong beliefs that keep regenerating the misuse catalog in code review.

13. The Misconceptions, Corrected

HPKE gets misused mostly because a handful of confident, wrong sentences keep getting said in design meetings. Here they are, corrected.

No -- not with respect to recipient compromise, in any mode. RFC 9180 states that HPKE ciphertexts are not forward secret against recipient compromise, because only long-term secrets are used on the recipient's side [@rfc9180]. Forward secrecy has to come from a ratchet or key rotation layered above HPKE, which is exactly what MLS and TLS do. No. `auth` mode is signcryption, not a third-party-verifiable signature: the recipient cannot prove authorship to anyone else, for the reason the modes section works through. If you need portable proof of who signed, use a digital signature [@abhklr20]. A `Context` is stateful: an incrementing sequence number derives each per-message nonce. Seal strictly in order, never reuse a context across independent streams, respect the per-ciphersuite AEAD message-count limit, and never let the sequence counter overflow -- any of those repeats a nonce, which is catastrophic [@rfc9180]. For independent messages, prefer single-shot `Seal`/`Open` and avoid the bookkeeping entirely. Not by default -- DHKEM is classical-only. The migration path is to drop a hybrid KEM such as X-Wing (X25519 with ML-KEM-768) into the KEM slot, secure if either component holds [@xwing], [@fips203]. Those suites are still draft-stage, add roughly 1.1 KB per encapsulation, and are not authenticated KEMs yet, so they cover `base` and `psk` but not `auth` [@xwing_draft06]. `crypto_box` is one fixed suite (X25519, XSalsa20, Poly1305), deliberately repudiable and mutually authenticated, with manual nonce handling for the raw API [@nacl]. It is excellent when you own both ends and want no options. HPKE wins for new protocol design, because it brings algorithm agility, four formal modes, machine-checked proofs, and test vectors [@rfc9180]. No -- PQ3 is KEM-based but not HPKE; it is a ratcheted, interactive scheme rather than single-shot encryption, as the earlier PQ3 aside details [@apple_pq3]. Do not list it as an HPKE deployment. Only if you use low-entropy pre-shared keys or open one ciphertext under multiple candidate keys. HPKE's AEADs are not key-committing by default, which is why a weak PSK enables a partitioning oracle; keep the PSK entropy at 32 bytes or more [@rfc9180], [@lgr20]. A committing AEAD, whose properties are codified in RFC 9771, may eventually arrive as a new `aead_id` [@aead_props].

Every correction points at the same root: the primitive was never the risk. It is time to say the sentence the whole article was built to earn.

14. The Math Held; The Risk Moved to the Interface

Return to where this started: an elementary task -- encrypt to a public key -- that the industry got subtly wrong four incompatible times, with no proofs and no shared test vectors, one standard shrugging off a second valid ciphertext as "benign" [@sec1], [@maea10]. HPKE is what that task looks like when it is finally done right.

The evidence has accumulated into a single claim. HPKE is one KEM-DEM construction: a Key Encapsulation Mechanism generates a shared secret and its encapsulation, an HKDF key schedule with every public key bound in derives the working keys, and an AEAD seals the payload.

It is proven secure against adaptive chosen-ciphertext attack under standard assumptions, machine-checked across all four modes, test-vectored per ciphersuite, and it designs benign malleability out by making the public-key binding mandatory rather than optional [@rfc9180], [@cs01], [@lipp20], [@abhklr20]. The consequence is the whole thesis: HPKE has no known catastrophic break, so the discipline it demands is not "how do I make it secure" but "do I know its four modes and its non-goals?"

Every entry in the misuse catalog proved the point. Forward secrecy expected from a static key, a signature expected from auth mode, safety expected from a non-committing AEAD, a fresh nonce expected from an overflowed counter -- each was a non-goal assumed away, not a broken cipher [@rfc9180], [@ghsa].

And the post-quantum migration is the architecture's final vindication: the one primitive-level gap, quantum resistance, is closed by swapping the KEM for a hybrid like X-Wing, not by redesigning the scheme [@xwing]. That is the exact payoff of having abstracted the KEM in the first place. It echoes this series' running lesson from the KEM-DEM and digital-signature parts: the math held, and the interface is where the work -- and the risk -- actually lives.

So carry one question out of this article and apply it to any encrypt-to-a-public-key design you review.

Which of the four modes is this, and which of HPKE's non-goals am I about to assume it has?

The primitive was never the weak link, and the post-quantum swap shows it never will be. That is why this is Part 19 of a field guide to protocol design, not a chapter about any one cipher. HPKE is the clean seam where the primitives of the earlier parts -- authenticated encryption, key derivation, elliptic curves, KEM-DEM, signatures -- become a protocol. The math is finished, the vectors are published, and the only thing left to get wrong is you.

The Tag Verified, the Cipher Held, the Forgery Went Through: A Field Guide to Message Authentication and Safe Composition

noreply@paragmali.com (Parag Mali) — Sat, 11 Jul 2026 01:12:01 GMT

A MAC makes forgery hard; three deployment assumptions keep it hard, and every famous break -- Flickr [@flickr-advisory], Lucky Thirteen [@cve-2013-0169], POODLE [@cve-2014-3566], the SSH plaintext-recovery attack [@apw-2009], and 184 nonce-repeating HTTPS servers [@woot16-bock] -- broke one of those assumptions, not the math. Pick the right family (PRF-based HMAC and KMAC take a reusable key and need no nonce; Wegman-Carter GMAC and Poly1305 run at line rate but demand a one-time key [@wc-1981]), verify in constant time, and always Encrypt-then-MAC over the ciphertext with an independent key and a strongly unforgeable tag [@bn-2000]. This guide traces the primitive from Carter-Wegman universal hashing in 1979 [@cw-1979] to committing AEAD in 2025 [@rfc-9771], names every failure by root cause, and ends with a decision tree and a paste-in review checklist. The one rule underneath all of it: authenticate the ciphertext, the length, and the context -- not just the message.

1. A Forgery Without a Broken Cipher

In 2009, two researchers forged valid Flickr API signatures without knowing Flickr's secret key, without finding a single MD5 collision, and without touching a cipher [@flickr-advisory]. Flickr had done what feels obviously correct -- prepend a secret to each request and hash the result -- and that one instinct silently handed signing power to anyone who had ever seen a single signed URL. The hash worked exactly as designed. The way Flickr used it was the vulnerability.

That gap -- between a primitive that is sound and a deployment that is not -- is the subject of this article, and it is worth stating as a claim you can test against every page that follows.

Key idea: A message authentication code makes forgery hard; keeping it hard is the surrounding protocol's job. Every deployed MAC ships a proof, and every proof quietly assumes three things the deployment must supply: (1) the right key discipline for its family, (2) a constant-time verify, and (3) composition over the right bytes, in the right order, binding the right context. Read that way, the entire failure catalogue is one sentence repeated -- the math never broke; a deployment broke one of these three assumptions.

Before we can prove that thesis, we need the object it is about. Informally, a MAC is a small tag you attach to a message so the receiver can tell the message came from someone who holds the shared secret key, and that nobody altered it in transit.

A MAC is a keyed algorithm that takes a secret key and a message and produces a short fixed-size tag. Anyone holding the same key can recompute the tag to verify that the message is authentic and unmodified. Unlike a plain hash, a MAC is keyed, so an attacker without the key cannot produce a valid tag; unlike a digital signature, the same secret both makes and checks the tag, so there is no public verifiability and no non-repudiation.

Now pair Flickr with a second break that fails a different assumption. In 2013, Lucky Thirteen recovered plaintext from TLS connections that used a perfectly correct HMAC -- the attack timed how the MAC was checked, not whether the MAC was strong [@cve-2013-0169]. Two production systems, two respected primitives, two failures -- and in neither case did the cryptography break. Flickr fed the hash the wrong bytes in the wrong construction; TLS checked a correct tag on a timing-leaky path.

Note: MD5 is badly broken for collision resistance, yet the Flickr forgery did not use a collision. HMAC was and is unbroken, yet Lucky Thirteen still bled plaintext. In both cases the primitive met its specification and the deployment violated an assumption the specification silently depended on. Hold onto that pattern -- it is the whole catalogue in miniature.

By the end of this field guide you will have a decision procedure and a review checklist that catch every failure in this article before it ships.The original Flickr advisory by Duong and Rizzo is no longer served from its source host; the citation here points to a 2009 Wayback Machine snapshot, which is the durable primary record [@flickr-advisory]. But a checklist without the underlying model is just cargo-culting. So start with the model. If the hash was not broken, what exactly is a MAC supposed to promise, and against whom?

2. What a MAC Actually Is

Strip away the mystique and a MAC is three algorithms and one game.

The three algorithms are KeyGen, Tag, and Verify. KeyGen samples a secret key $k$. Tag maps a key and a message $m$ to a tag $t$. Verify takes $k$, $m$, and a candidate $t$ and returns accept or reject. The whole design question is: how hard is it for someone without $k$ to make Verify say accept on a message the key-holder never authorized?

"How hard" was made precise in 1988. Shafi Goldwasser, Silvio Micali, and Ronald Rivest gave the first rigorous adversarial definition of authentication -- existential unforgeability under adaptive chosen-message attack -- while analyzing digital signatures, and MACs inherit it directly [@gmr-1988]. The game is deliberately generous to the attacker.

The adversary may ask for tags on any messages it likes, adaptively, as many as it wants. It wins if it then outputs a valid tag on any *new* message it never queried. A MAC is EUF-CMA secure if every efficient adversary wins only with negligible probability. The name is exact: "existential" means the forgery can be on any message the attacker chooses, and "adaptive chosen-message" means it sees each answer before picking its next query.

EUF-CMA is the usual bar, but composition needs a slightly stronger one, and the difference will decide whether a whole protocol stands or falls in Section 6.

SUF-CMA forbids even a *new tag on an old message*. The adversary wins if it outputs any message-tag pair that verifies and was not itself the result of a tag query -- including a second, different valid tag on a message it already asked about. Every SUF-CMA MAC is EUF-CMA, but not conversely: a MAC with malleable tags can be existentially unforgeable yet still let an attacker maul a valid tag into another valid tag.

Formally, if we write the tag oracle as $\mathsf{Tag}_k(\cdot)$ and let $Q$ be the set of message-tag pairs it returned, the strong-forgery advantage is

$$\mathsf{Adv}^{\text{suf-cma}}_{\mathsf{MAC}}(\mathcal{A}) ;=; \Pr!\left[,(m,t) \leftarrow \mathcal{A}^{\mathsf{Tag}_k(\cdot)} : \mathsf{Verify}_k(m,t)=\text{accept} ;\wedge; (m,t)\notin Q,\right].$$

A MAC is good when this probability stays negligible for every efficient $\mathcal{A}$. That single inequality is the promise Flickr's construction could not keep -- an attacker produced an accepted tag on a message that was never in $Q$.

Four primitives live near this definition, and confusing them is the source of real bugs. An unkeyed hash has no $k$, so anyone can recompute it -- it detects accidental corruption, never a motivated forger; this series covers hashes and their length-extension quirk in Part 10.

A MAC is symmetric: the same secret makes and checks the tag. A digital signature is asymmetric -- a private key signs, a public key verifies -- which buys public verifiability and non-repudiation that a MAC deliberately does not provide (Part 3 develops what the authenticated bytes must actually cover). An AEAD bundles a MAC together with encryption so one call delivers secrecy and integrity at once; Part 7 is the decision matrix for choosing among AEADs, and this article is the authentication half underneath it.

Note: Because a MAC key both signs and verifies, a valid tag proves only that someone holding the shared key produced it -- it cannot tell you which party, and it cannot be shown to a third party as proof. If you need "Alice, and only Alice, provably sent this," you need a signature, not a MAC. Reaching for a MAC where you needed non-repudiation is a design error no amount of key length fixes.

The definitions say a good MAC is unforgeable. Yet the very first keyed MACs people built were forgeable in ways the definition had not yet been written to outlaw. Stranger still, the airtight, provably unforgeable answer arrived before the practical, broken ones. Where did the idea come from?

3. Origins: Universal Hashing and One-Time Authentication

Here is the twist that reorders the whole story. The provably secure MAC was invented first, in 1979 and 1981, and then the field spent two decades shipping forgeable ones anyway. Keep that inversion in mind as the arc unfolds.

timeline title Message authentication, 1979 to 2025 1979 : Carter-Wegman universal hashing 1981 : One-time authentication, tag is hash plus one-time pad 1985 : CBC-MAC standardized in FIPS 113 1996 : HMAC nests the hash to stop length extension 2000 : Encrypt-then-MAC formalized by Bellare and Namprempre 2001 : Krawczyk indicts the SSL and SSH orderings 2004 : GMAC revives Wegman-Carter at line speed 2005 : Poly1305 brings it to fast software 2006 : HMAC proven a PRF without collision resistance 2009 : Flickr forgery and the SSH plaintext recovery 2013 : Lucky Thirteen timing oracle 2016 : KMAC keyed sponge and 184 nonce-repeating servers 2018 : TLS 1.3 record layer becomes AEAD-only 2023 : Terrapin breaks a correct channel 2025 : RFC 9771 standardizes commitment vocabulary

The starting point is a purely combinatorial object. Larry Carter and Mark Wegman, at IBM Research, asked what happens if you pick a hash function at random from a carefully built family, rather than fixing one function everyone knows [@cw-1979].

A universal family of hash functions has the property that, for any two fixed distinct inputs, a function drawn uniformly at random from the family maps them to the same output with only small, bounded probability. The bound comes from counting the functions in the family, not from any assumption about how much computing power an attacker has. It is combinatorial security, not cryptographic security -- which is exactly why it needs no unproven hardness conjecture.

Two years later, Wegman and Carter turned that object into an authenticator [@wc-1981]. The construction is startlingly small: draw a secret hash $h$ from a strongly universal family, draw a secret one-time pad $s$, and send

$$t ;=; h(m) ,\oplus, s.$$

The pad $s$ hides the value $h(m)$ completely, like a one-time pad hides a plaintext, and the universal property bounds an attacker's chance of guessing a valid tag for a different message. The result is unconditional: it holds against an adversary with unlimited computing power, assuming nothing about factoring, discrete logs, or the strength of any cipher.

Authenticate a message as the exclusive-or of a universal hash of the message and a fresh secret pad: the tag reveals nothing about the hash key, and forging a tag on a new message requires guessing a value the universal bound keeps small. The security is information-theoretic and tight -- but the pad must be used exactly once. Authenticate a second message under the same pad and the guarantee evaporates.

Take the smallest instance. Fix a prime $p$, keep a secret pair $(a, b)$, and tag a message $m$ as $t = (a\cdot m + b) \bmod p$. An attacker who sees one pair $(m_1, t_1)$ learns one linear equation in two unknowns; every candidate slope $a$ has exactly one consistent $b$, so the tag on any different $m_2$ stays uniform over all $p$ values. The best forgery succeeds with probability $1/p$. Beautiful, and useless twice: a second pair $(m_2, t_2)$ gives a second equation, the line is pinned, and every future tag is computable.

Note: "One-time" is not a restriction bolted onto Wegman-Carter authentication -- it is the security proof. The pad's single use is what buys the information-theoretic guarantee. That makes it a feature in 1981 and a landmine in 2004, when the same construction is revived at network line speed and a fast deployment reuses the pad. Every GMAC and Poly1305 nonce rule you will ever read is this 1981 constraint wearing modern clothes.

So the airtight answer existed. Yet it authenticates only one message per key, which is impractical for a general-purpose MAC.The two ideas are separate papers: the 1979 work introduced universal classes of hash functions as a combinatorial tool [@cw-1979]; the 1981 follow-up applied them to authentication and set equality [@wc-1981]. Universal hashing came first; authentication was the application. If the unconditional construction was this good but this restrictive, what did engineers reach for instead -- and why did the "obvious" keyed hashes they built break?

4. Early Approaches and Why They Broke

When engineers needed a keyed MAC in the 1990s, most reached for the hash they already had and glued a secret to it. The most natural glue is to put the key in front: compute H(secret || message) and ship the digest as the tag. It looks unforgeable -- you cannot compute the hash without the secret. It is also exactly what Flickr shipped, and it is broken by a property of the hash that has nothing to do with its collision resistance.

The property is length extension, and it is a direct consequence of how Merkle-Damgard hashes -- MD5, SHA-1, and most of SHA-2 -- are built [@length-ext-wiki]. Such a hash absorbs the message block by block into an internal state, and it emits that entire internal state as the digest. The digest is therefore a complete, resumable snapshot: given H(secret || message), you can set a fresh hash's state to that value and keep absorbing more bytes, as if you had known the secret all along.

Given the digest of `secret || message` and the length of the secret, an attacker can compute the digest of `secret || message || padding || extra` for attacker-chosen `extra`, without knowing the secret. The attack works because a Merkle-Damgard digest is the hash's full internal state, so it can be resumed. The only wrinkle is the glue `padding` the original hash appended internally, whose bytes are fully determined by the known lengths.

The forgery is mechanical once you see the state as resumable.

sequenceDiagram participant A as Attacker participant V as Verifier A->>V: Observe one signed request, message m and tag t Note over A: The tag t is the full hash state after absorbing key and m A->>A: Resume from t, append glue padding then chosen extra bytes A->>A: Keep hashing to get t2 for the extended message, no key used A->>V: Submit extended message with tag t2 Note over V: Verifier recomputes over key plus the extended message V-->>A: State matches, forged request accepted

The demonstration below builds a toy Merkle-Damgard hash whose digest is its internal state -- the essential property -- and forges a secret-prefix tag with no secret, then shows that nesting the hash (the HMAC idea) shuts the door.

Toy Merkle-Damgard hash: absorb one byte at a time; the digest IS the state. (The mixer is illustrative, not secure -- the STRUCTURE is the point.)

def compress(state, byte): return ((state * 1000003) ^ byte) & 0xFFFFFFFFFFFF # 48-bit toy state

def toy_hash(data, iv=0xA5A5A5A5A5A5): state = iv for byte in data: state = compress(state, byte) return state # digest == resumable internal state

secret = b"opensesame" # attacker does NOT know this... def prefix_mac(msg): # ...but does know len(secret) == 10 return toy_hash(secret + msg)

1) Attacker observes ONE legitimate (message, tag) pair:

seen = b"amount=10" tag = prefix_mac(seen)

2) Attacker resumes from the tag and appends -- the secret is never touched:

extra = b"&amount=1000000" forged = tag for byte in extra: forged = compress(forged, byte)

3) The verifier recomputes over secret + (seen + extra):

print("secret-prefix forgery accepted:", forged == prefix_mac(seen + extra))

The HMAC-style fix: nest, so the outer pass re-absorbs the inner digest.

def nested_mac(msg): inner = toy_hash(secret + msg) return toy_hash(secret + inner.to_bytes(6, "big"))

resumed = nested_mac(seen) for byte in extra: resumed = compress(resumed, byte) print("nested (HMAC-style) forgery accepted:", resumed == nested_mac(seen + extra)) `}

The first line prints True, the second False. That single flip is the difference between the Flickr construction and HMAC, and it is Aha number one for this article.

Note: H(secret || message) over any Merkle-Damgard hash is not a MAC. It authenticates nothing an attacker who has seen one tag cannot forge, regardless of how strong the underlying hash is. MD5's collision weakness is irrelevant here -- the Flickr forgery used no collision at all [@flickr-advisory]. If you find md5(secret + data) or sha256(secret + data) in a code review, you have found a length-extension forgery waiting to happen.

The mirror construction, secret-suffix H(message || secret), resists length extension because the secret is absorbed last.Secret-suffix is not safe either: since an attacker who finds two messages colliding under the raw hash gets a tag collision for free, H(m || k) reduces to the hash's collision resistance, so it dies with MD5 and SHA-1 -- the opposite failure mode from secret-prefix, same verdict [@length-ext-wiki]. Neither ad-hoc glue is a MAC.

The block-cipher world made a parallel mistake. CBC-MAC, standardized as FIPS 113 in 1985, runs a block cipher in CBC mode with a zero IV and keeps the final ciphertext block as the tag [@fips-113]. It carries an unstated assumption: every message is the same fixed length. Bellare, Kilian, and Rogaway turned the failure of that assumption into a theorem in 1994 -- secure for fixed-length messages, trivially forgeable once lengths vary [@bkr-1994].

The splice is mechanical. Query the tag of a one-block message $m_1$ to get $t_1 = E_k(m_1)$; then the two-block message $m_1 ,\Vert, (m_1 \oplus t_1)$ has tag $E_k\big((m_1 \oplus t_1)\oplus t_1\big) = E_k(m_1) = t_1$ -- a valid tag on a message never queried, produced with no key.

Both failures teach the same lesson, and it organizes the rest of this guide: a raw hash is not a MAC, and raw CBC-MAC is not a MAC for variable-length messages. Both fixes point the same direction -- stop exposing resumable internal state, and make the tag depend on length. From here the field split into two lineages. Which one wins?

5. The Evolution: Two Lineages Diverge

The field did not pick one winner. It split into two families that both survive today, and choosing between them is still the single most consequential decision a practitioner makes about authentication. One family keeps a computational assumption and buys a reusable key; the other keeps the 1981 one-time pad and buys blazing speed.

The PRF lineage: HMAC and CMAC

Bellare, Canetti, and Krawczyk fixed the secret-prefix disaster in 1996 by nesting the hash so the attacker never sees a resumable inner state [@bck-1996]. Standardized a year later as RFC 2104, HMAC computes two keyed passes [@rfc-2104]:

$$\mathsf{HMAC}(k, m) ;=; H\big((k \oplus \text{opad}) ,\Vert, H((k \oplus \text{ipad}) ,\Vert, m)\big).$$

The outer hash re-absorbs the inner digest, so a resumed inner state is useless -- length extension cannot reach the output.

RFC 2104 also fixes how the key becomes block-sized before those two XORs: a key longer than the hash's block size is first hashed down to a digest, and a shorter key is zero-padded up to the block size [@rfc-2104]. That is why HMAC accepts a key of any length -- it normalizes every key to exactly one block before mixing in `ipad` and `opad`. flowchart TD K[Secret key k] --> IP[k XOR ipad] M[Message m] --> INNER[Inner hash of ipad key then message] IP --> INNER INNER --> ID[Inner digest, never emitted directly] K --> OP[k XOR opad] ID --> OUTER[Outer hash of opad key then inner digest] OP --> OUTER OUTER --> T[HMAC tag]

The deepest fact about HMAC is also the most misunderstood, and it took another decade to prove. In 2006 Bellare showed HMAC is a pseudorandom function under the sole assumption that the hash's compression function is a PRF -- collision resistance is not required at all [@bellare-2006].

A keyed function is a PRF if no efficient adversary, allowed to query it on inputs of its choice, can distinguish its outputs from those of a truly random function. A PRF makes an immediate MAC: to forge a tag on a fresh message is to predict a value that, by assumption, looks uniformly random, which succeeds only with negligible probability. Unforgeability falls out of pseudorandomness.

This is why the collision breaks of MD5 and SHA-1 never touched HMAC-MD5 or HMAC-SHA-1. Collisions attack collision resistance; HMAC never needed it.

Note: The folklore "HMAC needs a collision-resistant hash" is false, and it has been false since 2006 [@bellare-2006]. HMAC needs the compression function to behave like a PRF -- a different, and for MD5 and SHA-1 still-standing, assumption. This is not a licence to use MD5 in new systems, but it is why the practical world did not catch fire when SHA-1 collisions arrived.

The block-cipher branch got the same repair. CMAC, from Iwata and Kurosawa's OMAC and standardized as NIST SP 800-38B, derives two subkeys from the block cipher and mixes one into the final block, killing the variable-length splice that sank raw CBC-MAC while keeping a single key [@omac-2003] [@sp-800-38b]. It is the block-cipher PRF-MAC, useful where a device already has AES hardware but no hash.

The survival of HMAC-SHA-1 is the cleanest real-world confirmation of the 2006 proof: SHA-1's collision resistance collapsed publicly, yet no HMAC-SHA-1 forgery followed, because the security reduction never invoked collision resistance in the first place [@bellare-2006].

The sponge refinement: KMAC

SHA-3 changed the substrate. A Keccak sponge splits its state into a public rate and a secret capacity, and it never emits the capacity [@fips-202]. That single property makes the HMAC nesting trick unnecessary: you can key a sponge by simply absorbing the key first.

A sponge function absorbs input into a large internal state divided into a public "rate" (the bytes that interact with input and output) and a secret "capacity" (bytes never revealed). Because the capacity is never output, prepending a key and absorbing it yields a keyed authenticator with no length-extension surface and no double hashing -- the key is protected by the same hidden capacity that protects the hash.

NIST SP 800-185 builds KMAC on cSHAKE this way: prepend the key, absorb, squeeze [@sp-800-185]. Keying is native, domain separation is built in through customization strings, and the tag length is a free parameter because the sponge is an extendable-output function. It is, conceptually, the cleanest MAC in the standard catalogue -- but conceptual cleanliness is not deployment.

KMAC is a real, standardized primitive [@sp-800-185], implemented in OpenSSL 3.0 and later (as the `KMAC-128`/`KMAC-256` EVP_MAC) [@openssl-kmac], as well as BouncyCastle [@bouncycastle-kmac] and Botan [@botan-kmac]. It is not academic-only. But its production footprint is thin next to HMAC, GMAC, and Poly1305, for reasons that are historical inertia rather than cryptography: SHA-2 and HMAC are welded into TLS, IPsec, JWT, HKDF, and hardware everywhere, and SHA-3 adoption trails. This guide gives KMAC full conceptual treatment and makes no claim about its market share -- no reliable quantitative figure exists in a primary source.

Both HMAC and KMAC share a decisive operational property: a reusable key, no nonce, an unbounded stream of messages under one secret. That is the easy side of assumption one. The other lineage trades it away for speed.

The Wegman-Carter lineage: GMAC and Poly1305

In 2004 and 2005, two designs dragged the 1981 one-time construction into high-speed networking. Both keep the pattern tag = universal_hash(m) + one_time_pad, and both solve the "fresh pad per message" problem the same way -- derive the pad from a cipher keystream instead of shipping new randomness.

GHASH, the core of GCM, is a polynomial universal hash over the finite field $\mathrm{GF}(2^{128})$: it evaluates $\sum_i m_i \cdot H^{,L-i+1}$ at a secret point $H = E_k(0)$, then masks the result with an AES-encrypted counter block [@mcgrew-viega-2004]. Run GCM with an empty plaintext and you get GMAC, an authentication-only MAC over associated data, standardized in NIST SP 800-38D [@sp-800-38d]. Poly1305 evaluates a message polynomial modulo the prime $2^{130}-5$ under a secret $r$, then adds a one-time pad $s$; deployed as ChaCha20-Poly1305, it draws a fresh $(r, s)$ from the cipher keystream for every message [@rfc-8439].

flowchart TD N[Nonce and key] --> KS[Cipher keystream block] KS --> R[One-time hash key r] KS --> S[One-time pad s] M[Message m] --> P[Polynomial hash of m under r] R --> P P --> ADD[Add the one-time pad s] S --> ADD ADD --> T[Authentication tag] T -.reuse the same nonce.-> LEAK[Two tags cancel the pad, leaking hash of m1 minus hash of m2]

This is where the 1981 constraint re-enters as a deployment contract. The pad is safe only if the $(key, nonce)$ pair never repeats. Reuse it and the pad cancels out of the difference of two tags, exactly as the toy line did in Section 3 -- except now the "hash" is a polynomial an attacker can then start solving.

A one-time Wegman-Carter MAC: tag = poly_hash(m, r) + s (mod p). Use (r, s) ONCE.

p = (1 << 130) - 5 # the Poly1305 prime, 2**130 - 5

def poly_hash(msg, r): acc = 0 for i in range(0, len(msg), 16): chunk = msg[i:i+16] limb = int.from_bytes(chunk, "little") + (1 << (8 * len(chunk))) acc = ((acc + limb) * r) % p return acc

In ChaCha20-Poly1305 both r and s come fresh from the keystream, per message.

r = 0x1bf54941aff6bf4afdb1f2a3c4d5e6f7 s = 0x0102030405060708090a0b0c0d0e0f10

def one_time_tag(msg): return (poly_hash(msg, r) + s) % p

THE MISTAKE: two messages under the SAME (r, s).

m1, m2 = b"transfer 10 dollars now", b"transfer 9999 bucks now" t1, t2 = one_time_tag(m1), one_time_tag(m2)

The pad s cancels in the difference -- a relation that does not depend on s at all:

lhs = (t1 - t2) % p rhs = (poly_hash(m1, r) - poly_hash(m2, r)) % p print("pad cancelled, tag difference is key-independent:", lhs == rhs) `}

It prints True: subtract two tags produced under the same one-time key and the secret pad vanishes, handing the attacker a clean algebraic relation in the hash key. That is the first step of the "forbidden attack" the failure catalogue will name -- and it is why the distinction below is not pedantry.

The master key versus one-time key split is the heart of the fork. HMAC and KMAC take a master key and authenticate forever under it. GMAC and Poly1305 take a one-time key per message; the ChaCha20-Poly1305 keystream manufactures that one-time key so the master key stays put, but the per-message pad is still strictly single-use. Confuse the two and you get a catastrophe, not a slow degradation.

The whole construction catalogue, side by side:

Table 1 -- MAC constructions, and what each one assumes.

Construction	Year	Core idea	Key model	Strength	Weakness	Status
Carter-Wegman one-time [@wc-1981]	1981	$\mathsf{UH}(m) \oplus \text{pad}$	One-time pad per message	Information-theoretic, no hardness assumption	Pad is strictly single-use	Foundational, revived
Secret-prefix $H(k \Vert m)$ [@length-ext-wiki]	1990s	Prepend key, hash	Reusable	Trivial to build	Length-extension forgeable	Superseded, insecure
Secret-suffix $H(m \Vert k)$ [@length-ext-wiki]	1990s	Append key, hash	Reusable	No length extension	Reduces to a hash collision	Superseded, insecure
CBC-MAC [@fips-113]	1985	CBC chain, keep last block	Reusable	First standardized block-cipher MAC	Variable-length splicing forgery	Historical
HMAC [@rfc-2104]	1996	Nested keyed hash	Reusable, no nonce	PRF not collision resistance, length-ext immune	Serial, no line-rate shortcut	Active, default PRF-MAC
CMAC [@sp-800-38b]	2005	CBC-MAC plus final subkey	Reusable, no nonce	Fixes CBC-MAC with one key	Block-cipher birthday ceiling	Active, niche
GMAC / GHASH [@sp-800-38d]	2004	Polynomial hash over $\mathrm{GF}(2^{128})$	One-time pad per message	Carry-less-multiply hardware (PCLMULQDQ/PMULL)	Nonce reuse is fatal	Active, inside GCM
Poly1305 [@rfc-8439]	2005	Polynomial hash mod $2^{130}-5$	One-time key per message	Fast in pure software, cipher-agnostic	One-time key per message	Active, inside ChaCha20-Poly1305
KMAC [@sp-800-185]	2016	Keyed sponge, cSHAKE	Reusable, no nonce	Native keying, domain separation, XOF tag	Lightly deployed	Active, niche

You can now build an unforgeable tag two ways: a reusable-key PRF or a one-time-key universal hash. But a perfect tag attached in the wrong place, in the wrong order, or over the wrong bytes is still useless. How do you combine a MAC with a cipher without reopening the door you just closed?

6. Composition Done Right, and the Verification Contract

SSL chose one order for combining its cipher and its MAC. SSH chose another. Both were quietly indicted by a theorem years before either was broken in the field. This section is where the second aha moment lands: strength was never the variable -- discipline and order were.

Bellare and Namprempre formalized the question in 2000 by splitting integrity into two notions [@bn-2000]. Integrity of plaintexts (INT-PTXT) says an attacker cannot make the receiver accept a plaintext the sender never sent. Integrity of ciphertexts (INT-CTXT) is stronger: the attacker cannot even produce a new ciphertext the receiver will accept. Their result is the load-bearing one: applying the MAC to the ciphertext -- Encrypt-then-MAC -- yields both IND-CCA confidentiality and INT-CTXT, and it is the only one of the three generic orders that reaches those strong notions.

Encrypt the plaintext, then compute the MAC over the resulting *ciphertext* (plus any associated data and length), and send ciphertext and tag together. On receipt, verify the tag *before* touching the ciphertext; if it fails, discard without decrypting. EtM is the only generic composition order that provably delivers integrity of ciphertexts, and it does so only under two preconditions: the MAC must be strongly unforgeable and the encryption and MAC keys must be independent.

Those two preconditions are not decoration. If the MAC is only EUF-CMA rather than SUF-CMA, the guarantee weakens from INT-CTXT down to INT-PTXT, because a malleable tag lets an attacker produce a different valid ciphertext for the same plaintext [@bn-2000]. And the keys must be independent -- reusing one key for both encryption and authentication voids the proof.

A year later Krawczyk sharpened the verdict [@krawczyk-2001]. He proved that any secure-channel protocol required to work with any secure cipher and any secure MAC must use Encrypt-then-MAC, and he built a perfectly secret cipher that becomes totally insecure under MAC-then-Encrypt -- SSL's order -- and under Encrypt-and-MAC -- SSH's order.

"[A]ny secure channels protocol designed to work with any combination of secure encryption ... and secure MAC must use the encrypt-then-authenticate method." -- Hugo Krawczyk, The Order of Encryption and Authentication for Protecting Communications, 2001 [@krawczyk-2001]

Here is the precision that separates an expert from a slogan-repeater: Krawczyk also proved that MAC-then-Encrypt is secure for specific cipher modes, namely CBC and CTR [@krawczyk-2001]. MtE is therefore fragile and not generically secure -- it holds only when you can prove something extra about the exact cipher -- but it was never unconditionally "broken." Say "MtE is broken" in an interview and you are wrong; say "MtE is not generically secure, so do not use it in new designs" and you are exactly right.

flowchart TD subgraph EtM["Encrypt-then-MAC, generically secure"] E1[Plaintext] --> E2[Encrypt] E2 --> E3[Ciphertext] --> E4[MAC the ciphertext] E4 --> E5[Receiver verifies tag first, then decrypts] end subgraph MtE["MAC-then-Encrypt, fragile"] M1[Plaintext] --> M2[MAC the plaintext] M2 --> M3[Encrypt plaintext and tag together] M3 --> M4[Receiver decrypts first, only then verifies] end subgraph EM["Encrypt-and-MAC, fragile"] A1[Plaintext] --> A2[Encrypt] A1 --> A3[MAC the plaintext, tag sent in the clear] A2 --> A4[Receiver decrypts, and the tag leaks plaintext] end

The diagram shows the mechanism behind every padding-oracle and SSH break at once: in the two fragile orders, the receiver must decrypt or parse before it can verify, so the very act of processing attacker-chosen bytes leaks information. Encrypt-then-MAC verifies first and refuses to decrypt a single byte of an unauthenticated ciphertext.

Key idea: Authenticate the ciphertext, not the plaintext. Encrypt-then-MAC over the ciphertext -- with an independent key, a strongly unforgeable tag, and coverage of the associated data and length -- is the only generic order that lets the receiver reject a forgery before it decrypts anything. Every composition break in the catalogue is a system that decrypted or parsed before it verified.

Table 2 -- Composition orders, ranked by what they generically guarantee.

Order	Idea	Generic security	Weakness	Status
MAC-then-Encrypt [@krawczyk-2001]	MAC the plaintext, then encrypt both	Not generic, secure only for CBC or CTR	Decrypt-before-verify padding and timing oracles	Superseded, fragile
Encrypt-and-MAC [@apw-2009]	Encrypt, and MAC the plaintext separately	Not generic	Tag over plaintext leaks, MAC-covered length field abused	Superseded, fragile
Encrypt-then-MAC [@bn-2000]	MAC the ciphertext	IND-CCA plus INT-CTXT	Needs SUF-CMA, independent keys, constant-time verify	Active, canonical
AEAD [@rfc-8446]	EtM internalized plus nonce management	IND-CCA plus INT-CTXT by construction	Key-commitment gap	Active, default
Committing AEAD [@rfc-9771]	AEAD plus key and context commitment	Adds commitment	Still standardizing, cost profiling	Frontier

The order is only half of correct composition. The other half arrived not from a theorem but from a field disclosure. In 2009 Nate Lawson found that Google's Keyczar library compared HMAC tags byte by byte and returned as soon as two bytes differed [@keyczar-2009]. That early exit turns verification time into a side channel: a forged tag that matches more leading bytes takes measurably longer to reject, so an attacker can recover the correct tag one byte at a time by timing responses.

Q0 -- Yes --> ASCON[Ascon, SP 800-232]
Q0 -- No --> Q1&#123;"Is there a ciphertext to authenticate?"&#125;
Q1 -- No --> HMAC[HMAC-SHA-256, reusable key, no nonce]
Q1 -- Yes --> Q2&#123;"Can you guarantee a unique nonce per key?"&#125;
Q2 -- No --> SIV[AES-GCM-SIV, misuse-resistant]
Q2 -- Yes --> Q3&#123;"Is AES-NI hardware available?"&#125;
Q3 -- Yes --> GCM[AES-GCM, rekey before the per-key ceiling]
Q3 -- No --> CHACHA[ChaCha20-Poly1305]

Read the tree as the three assumptions in order. If there is no ciphertext to bind -- key derivation, a token, a one-time password -- use HMAC-SHA-256 with a key of at least 128 bits, a full-length tag, and a constant-time verify; there is no nonce to mismanage, so assumption one is nearly free. This is the right tool for HKDF [@rfc-5869], JWT's HS256 [@rfc-7518], TOTP, HOTP, and PBKDF2.

If there is a ciphertext, do not hand-roll a MAC plus cipher -- reach for an AEAD, which internalizes Encrypt-then-MAC so you cannot mis-order it. Pick ChaCha20-Poly1305 when you lack AES hardware acceleration, especially on mobile and embedded targets, where its per-key budget is effectively unbounded [@rfc-8439]. Pick AES-GCM when you have AES-NI, and rekey before the $2^{23}$-packet ceiling on high-volume links [@rfc-9001]. If you cannot guarantee nonce uniqueness at scale, step down to AES-GCM-SIV, which degrades gracefully instead of catastrophically on reuse [@rfc-8452].

Two niche branches sit off the main tree. Use GMAC for authentication-only data, such as MACsec framing, with a guaranteed-unique nonce [@sp-800-38d] [@ieee-802-1ae]. Use KMAC when you are already in a Keccak or SHA-3 stack, or when you need domain separation or variable-length tags [@sp-800-185]. And on constrained or side-channel-sensitive hardware, use Ascon [@sp-800-232].

Then there are the rules that apply always, regardless of which box the tree lands in: Encrypt-then-MAC or an AEAD that internalizes it; independent encryption and MAC keys; a constant-time compare; a tag of at least 128 bits with documented truncation floors [@rfc-4868]; authentication that covers the associated data, the length, the version, and the session context; a committing AEAD when one ciphertext might be opened under multiple keys [@bellare-hoang-2022]; and a misuse-resistant AEAD when nonce uniqueness cannot be guaranteed [@rfc-8452].

Key idea: Review authentication code against the checklist and its negation. The checklist tells you what a correct design does; the misuse list tells you what every named CVE did instead. Run any authentication path past both -- if it matches even one line of the misuse list, you have found your next vulnerability before an attacker does.

The negation is the misuse catalogue -- each row is a line of the checklist inverted, and it maps one-to-one onto a named break from Section 7.

Table 6 -- Common misuse, the break it produced, and the fix.

Misuse in real code	Named break it caused	Fix
Secret-prefix $H(k \Vert m)$ MAC	Flickr length extension [@flickr-advisory]	Use HMAC or KMAC
Reusing a GCM nonce or Poly1305 one-time key	Joux, Nonce-Disrespecting [@woot16-bock]	Guarantee uniqueness or use AES-GCM-SIV
`==` or `memcmp` tag comparison	Keyczar timing leak [@keyczar-2009]	Use a constant-time compare
MAC-then-Encrypt or Encrypt-and-MAC in new code	Lucky Thirteen, POODLE, SSH recovery [@cve-2013-0169]	Use an AEAD (Encrypt-then-MAC)
Over-truncated tags	Forgery near the $2^{-t}$ floor [@rfc-4868]	Keep the tag at least 128 bits
One shared key for encryption and MAC	Voids the Encrypt-then-MAC proof [@bn-2000]	Derive independent keys
MACing the plaintext instead of the ciphertext	Padding oracles [@vaudenay-2002]	MAC the ciphertext
Forgetting AD, length, version, context	Terrapin [@terrapin-site]	Bind the full context
Treating "MAC verified" as "key committed"	Invisible salamanders [@bellare-hoang-2022]	Use a committing AEAD

Note: Run every authentication path past these ten lines: - Is the tag over the ciphertext (Encrypt-then-MAC), never the plaintext? - Are the encryption and MAC keys independent? - Is the MAC strongly unforgeable (SUF-CMA), not merely EUF-CMA? - Is the tag comparison constant-time (compare_digest, timingSafeEqual, ConstantTimeCompare)? - Is the whole decrypt-and-verify path constant-time, not just the compare? - Is the tag at least 128 bits, with any truncation documented against the birthday bound? - For a one-time-key MAC (GMAC, Poly1305), is nonce uniqueness guaranteed, or are you on a misuse-resistant mode? - Does the authenticated data cover length, version, ordering, and session context? - Is there any H(secret || message) secret-prefix construction? (Replace with HMAC or KMAC.) - Could one ciphertext open under two keys? If so, use a committing AEAD. Any single failure here is a plausible next CVE.

That checklist and its negation are the working payoff of the whole field guide. Before the conclusion ties them back to the thesis, seven specific beliefs produce most of the remaining real-world authentication bugs -- and each is a corollary of the same one sentence.

13. Frequently Corrected Misconceptions

No. As Section 5 established, Bellare's 2006 proof rests HMAC's security on a single property of the underlying compression function -- that it is itself a PRF -- and not on collision resistance [@bellare-2006]. Since a collision attack targets a property the proof never relies on, HMAC-SHA-1 and HMAC-MD5 kept standing when the SHA-1 and MD5 collision breaks landed. Use HMAC-SHA-256 in new systems for margin, but understand that the reason is prudence, not a collision threat. No, and the difference is the most dangerous one to miss. HMAC takes a reusable key with no nonce. GMAC and Poly1305 are Wegman-Carter one-time-key MACs [@wc-1981]: they need a fresh, unique per-message key, and reusing it is catastrophic, not a gentle degradation. The 184 HTTPS servers caught repeating GCM nonces were forgeable precisely because a one-time construction was treated like a reusable one [@woot16-bock]. Same tag length, completely different key contract. No. HMAC exists to defeat length extension on Merkle-Damgard hashes, but a Keccak sponge never emits its capacity, so it has no length-extension surface and keys natively -- just use KMAC [@sp-800-185]. In fact you cannot build HMAC on a SHAKE extendable-output function anyway; Python's `hmac` module notes that XOFs such as SHAKE-128 and SHAKE-256 cannot be used with HMAC [@python-hmac]. KMAC is the SHA-3-native answer. No -- it is fragile, which is a different and more precise claim. Krawczyk proved MAC-then-Encrypt is *not generically secure*, yet also proved it *is* secure for CBC and CTR modes specifically [@krawczyk-2001]. So it was never unconditionally broken; it is simply deprecated for new designs, where a modern AEAD or Encrypt-then-MAC removes the cipher-specific precondition it depends on. Reach for one of those instead, but do not call MtE "broken." Not by itself, and the overstatement matters. A single $(key, nonce)$ reuse immediately leaks a tag relation and the XOR of the two plaintexts [@joux-2006]. Recovering the subkey $H$ outright is a taller order: a single reuse leaves a root-finding equation with several possible solutions for $H$, so narrowing them to the one true value takes at least a second collision, and usually more. So "one reuse recovers the key" is wrong; "one reuse is already a break, and more reuse recovers the key" is right. No -- there is a real-world counterexample. In 2009 Google's Keyczar library did a byte-wise tag comparison with an early exit, and that timing difference let an attacker recover valid tags one byte at a time [@keyczar-2009]. The comparison time leaked the secret the MAC existed to protect. Constant-time compare is a correctness requirement, not an optimization, and every major platform ships a named primitive for it. No. AEAD handles the encrypted channel, but plenty of jobs have no ciphertext to bind and still need authentication. HKDF key derivation [@rfc-5869], JWT's `HS256` [@rfc-7518], TOTP and HOTP one-time passwords, and PBKDF2 are all standalone HMAC. The standalone MAC did not disappear with AEAD; it moved to the places where you are authenticating keys, tokens, or messages rather than protecting a ciphertext.

Every myth here is a corollary of one sentence, which the conclusion now restates with the whole catalogue behind it.

14. The Math Never Broke

Return to Flickr, now fully understood. Two researchers forged valid API signatures with no key, no collision, and no cipher work, because Flickr's secret-prefix H(secret || params) construction handed out its resumable hash state as the tag [@flickr-advisory]. The hash met its specification exactly. The deployment broke assumption three -- the wrong construction over the wrong bytes -- and that was enough.

Line up the rest of the catalogue and the pattern is total. Lucky Thirteen and POODLE broke order and timing, decrypting before verifying [@cve-2013-0169] [@cve-2014-3566]. The SSH plaintext-recovery attack broke order, authenticating the plaintext and acting on a MAC-covered length field [@apw-2009]. The 184 nonce-repeating GCM servers broke key discipline, reusing a one-time pad [@woot16-bock]. Terrapin broke context, leaving the transcript and sequence numbers unbound even though the cipher, the MAC, and the order were all correct [@terrapin-site]. Not one of them broke AES, SHA-2, or a polynomial hash. Every single failure broke the contract around the primitive.

That is the whole thesis, proven by the evidence rather than asserted: a MAC makes forgery hard, and three deployment assumptions -- the right key discipline, a constant-time verify, and composition over the right bytes in the right order binding the right context -- are what keep it hard. The decision tree and the checklist in Section 12 are simply those three assumptions made executable. Carry them, and their negation, into every review.

The frontier moves the bar again: soon "the tag verified" should also mean "this ciphertext commits to one key and one context," the committing-AEAD work this series develops further in Part 7. And the deeper machinery lives in the siblings -- the security definitions of Part 1, the one-time-key generation of Part 2, the canonicalization discipline of Part 3, the block modes of Part 5, the padding oracles of Part 6, and the AEAD decision matrix of Part 7. This part is the authentication spine that runs through all of them.

The math never broke; a deployment broke one of three assumptions. Authenticate the ciphertext, the length, and the context -- not just the message.

The AEAD Decision Matrix: Seven Ciphers, Three Edges, One Choice

noreply@paragmali.com (Parag Mali) — Thu, 09 Jul 2026 15:04:00 GMT

Every modern AEAD makes the same three promises, and they differ only at the sharp edges where those promises stop. Three edges decide a real deployment: the **nonce contract** (catastrophic on reuse, or misuse-resistant), the **performance and hardware profile** (AES-NI plus CLMUL, constant-time software, or a few thousand gates), and **commitment** (does one ciphertext bind to exactly one key?). "Which AEAD should I use?" is not a ranking from worst to best. It is a function: default to AES-GCM or ChaCha20-Poly1305, and escalate to AES-GCM-SIV, AES-CCM, Ascon, OCB3, or AEGIS only when a specific edge demands it. Every famous break -- invisible salamanders, nonce reuse on live TLS, `CCM_8` forgeries -- was a deployment stepping on an edge, not a broken cipher.

1. Two Failures That Should Have Been Impossible

In 2018, a team of cryptographers handed Facebook a single encrypted file that decrypted to two completely different, perfectly meaningful images, and whose authentication tag verified correctly for both, under two different keys [@dodis2018-salamander]. The cipher was AES-GCM, the internet's default authenticated encryption. Nothing about it was broken. That is the unsettling part: AES-GCM did exactly what it promised. It had just never promised the thing everyone assumed it did.

The result defeated Facebook Messenger's abuse-reporting scheme, which relied on the encrypted attachment being bound to the key that produced it. The authors called their construction "invisible salamanders" [@dodis2018-salamander]. Your reflex on reading this -- "but it is authenticated, so how did the tag pass?" -- is the entire subject of this article. The word "authenticated" carries less than you think.

Now the second failure, because one break only shows one edge. In 2016, researchers scanning the live internet found 184 HTTPS servers reusing a (key, nonce) pair under AES-GCM [@bock2016]. A repeated nonce in GCM is not a hygiene slip that costs you a little margin. It instantly leaks the XOR of the two plaintexts, and -- via an attack Antoine Joux had described to NIST a decade earlier, in 2006 -- it lets an attacker forge arbitrary messages [@joux2006]. The confidentiality half of that failure is easy to see for yourself.

{` // A stream-cipher-style AEAD (GCM, ChaCha20-Poly1305) turns the key+nonce // into a keystream, then XORs it with the plaintext. Reuse the nonce and // you reuse the keystream -- so it cancels out of the XOR of two ciphertexts. const keystream = [0x9e, 0x37, 0xb1, 0xf2, 0x4a]; // same (key, nonce) => same keystream const xor = (a, b) => a.map((x, i) => x ^ b[i]);

const p1 = [...'HELLO'].map(c => c.charCodeAt(0)); const p2 = [...'WORLD'].map(c => c.charCodeAt(0));

const c1 = xor(p1, keystream); // ciphertext 1 const c2 = xor(p2, keystream); // ciphertext 2, SAME nonce

// Attacker sees only c1 and c2, never the key or keystream: const leaked = xor(c1, c2); // == p1 XOR p2, the keystream is gone const recovered = xor(leaked, p2); // and if p2 is ever guessed, p1 falls out console.log('c1 XOR c2 leaks P1 XOR P2:', leaked.join(',')); console.log('recovered P1:', String.fromCharCode(...recovered)); `}

Neither of these was a broken cipher. AES-GCM met its specification in both cases. The salamander bound nothing to a key because AES-GCM was never designed to; the TLS servers leaked plaintext because they violated the one contract GCM cannot survive. Both failures were the same shape: a deployment reached for an AEAD and then stepped on the one sharp edge its designers had moved somewhere the deployment could not avoid.

That is the thesis of this field guide. Authenticated encryption with associated data (AEAD) fused confidentiality and integrity so completely that composing them by hand became a solved problem. The remaining hard problem is choosing among AEADs, and that choice turns on three edges: the nonce contract, the performance and hardware profile, and the commitment axis.

Part 1 of this series defined an AEAD's guarantees as IND-CPA plus INT-CTXT; commitment is a robustness property beyond both. Part 6 showed the padding-oracle cost of the botched integrity AEAD was built to remove.The nonce-reuse breaks are widely mis-cited to CVE-2016-0270. That CVE actually names IBM Domino, and the NVD entry itself warns it has been "incorrectly used for GCM nonce reuse issues in other products" [@cve-2016-0270].

Key idea: "Which AEAD should I use?" is not a ranking. It is a function over three edges: pick the construction whose failure mode your deployment can guarantee it will never trigger. The salamander triggered the commitment edge; the TLS servers triggered the nonce edge. Same lesson, two edges.

If "authenticated" does not mean "bound to one key," and "encrypted" does not survive a repeated nonce, then what exactly does an AEAD promise, and where does each promise stop? To answer that, we have to go back to the moment when "encrypt" and "authenticate" were still two separate calls.

2. From Two Calls to One

Here is a question that sounds trivial and is not: you have a cipher and you have a message authentication code (MAC). In which order do you apply them? Most engineers guess. The wrong guess shipped in SSL, IPsec, and SSH, and it took the field a decade of theory to sort out which guess was which.

There are three orderings. Encrypt-and-MAC authenticates the plaintext and appends the tag beside the ciphertext (SSH). MAC-then-Encrypt authenticates the plaintext, then encrypts plaintext and tag together (SSL and, for years, TLS). Encrypt-then-MAC encrypts, then authenticates the ciphertext (IPsec).

In 2000, Mihir Bellare and Chanathip Namprempre proved these are not interchangeable: only Encrypt-then-MAC generically preserves both privacy and integrity for any secure cipher and any secure MAC [@bn2000]. A year later, Hugo Krawczyk showed the authenticate-then-encrypt method used in SSL is not generically secure while Encrypt-then-MAC is [@krawczyk2001]. Part 6 is the sequel: MAC-then-encrypt is exactly the door a padding oracle walks through.

One keyed call that provides confidentiality of the plaintext, integrity of the plaintext, and integrity (but not secrecy) of an extra header called the associated data. The uniform interface was standardized in RFC 5116 [@rfc5116].

The lesson cut deeper than "pick Encrypt-then-MAC." If two correct primitives can combine into an insecure whole, hand-composition is a footgun no matter how good the parts are. The fix was to make a single primitive own both goals, so no protocol designer could botch the join.

Charanjit Jutla showed the way in 2001 with IAPM and IACBC, modes that delivered message integrity in essentially one pass, almost for free [@jutla2001]. The same year, Phillip Rogaway and coauthors published OCB, a one-pass block-cipher mode built for exactly this [@ocb2001]. Then, in 2002, Rogaway named the primitive: real messages carry a header -- routing bytes, version numbers, sequence counters -- that must be authenticated but not encrypted, because intermediaries need to read it. His "Authenticated-Encryption with Associated-Data" formalized that extra input [@rogaway2002-ad].

The header bytes an AEAD authenticates but does not encrypt: routing information, protocol versions, sequence numbers. Tampering with the associated data makes tag verification fail, but the associated data itself travels in the clear [@rogaway2002-ad].

By 2008, David McGrew closed the loop with RFC 5116, which defined the universal interface every construction in this article implements: AEAD-Encrypt(key, nonce, associated_data, plaintext) returns ciphertext || tag, and the matching decrypt either returns the plaintext or a single, uninformative failure [@rfc5116]. One call in, one call out, no way to reverse the order of two primitives because there is only one primitive.

A value that must be unique for every encryption under a given key. The mode, not the label, sets the exact requirement: some AEADs tolerate only uniqueness, others tolerate randomness, and a few tolerate repetition. Nonce generation is the subject of Part 2 of this series. timeline title The road to the AEAD portfolio 2000 : Encrypt-then-MAC proven the safe order 2001 : IAPM and OCB, single-pass native AE 2002 : Rogaway names AEAD and adds associated data 2003 : CCM standardized in RFC 3610 2004 : GCM published by McGrew and Viega 2006 : Joux forbidden attack, SIV misuse-resistance 2008 : RFC 5116 fixes the universal interface 2013 : CAESAR opens, AEGIS announced 2016 : Nonce reuse found on live TLS servers 2018 : Invisible salamanders break message franking 2019 : CAESAR portfolio chosen, OCB2 broken 2021 : Partitioning oracles weaponize non-commitment 2025 : NIST standardizes Ascon-AEAD128

The interface was settled by 2008. But an interface is a promise about shape, not about sharp edges. Two constructions that satisfy AEAD-Encrypt to the letter can fail in completely different ways, and the very first AEADs to ship proved it. The one that reached the most devices did not even win on technical merit. It won because of a patent.

3. The Welded Modes: CCM and GCM

The first AEAD to reach a billion devices was not chosen by a cryptographer. It was chosen, in effect, by a patent lawyer. When IEEE 802.11i (the security amendment that became WPA2) needed an authenticated mode, the elegant candidate was OCB -- but OCB was patent-encumbered, and the working group would not build a wireless standard on it. So 802.11i standardized the plodding, unpatented alternative: AES-CCM. By device count, that decision made CCM one of the most widely deployed AEADs in the world.

AES-CCM = Counter mode + CBC-MAC. Doug Whiting, Russ Housley, and Niels Ferguson specified it in RFC 3610 in 2003, and NIST blessed it as SP 800-38C the next year [@rfc3610][@sp80038c]. It runs the message through CBC-MAC for the tag, then encrypts with counter (CTR) mode: two passes, a strictly serial MAC, and the message length needed up front, which makes streaming awkward. What that price buys is frugality -- nothing but AES, a tiny code footprint, no second primitive to implement.

That profile is why CCM owns the constrained niche -- Bluetooth Low Energy [@bluetooth-core], Zigbee [@ieee802154], and the TLS CCM_8 ciphersuites. IEEE 802.11i also made CCMP the mandatory data-confidentiality protocol for WPA2 [@ieee80211i], and CCM rode WPA2/CCMP into the overwhelming majority of Wi-Fi hardware over the following decade.Zigbee and 802.15.4 use a variant called CCM*, which additionally permits integrity-only or encryption-only operation, unlike the strict RFC 3610 CCM that always does both. So the same plodding, all-AES mode anchors two very different worlds: the smallest constrained devices and the Wi-Fi layer that WPA2 secures. These are the building blocks from Part 5, welded to a MAC.

AES-GCM = Counter mode + GHASH. David McGrew and John Viega published Galois/Counter Mode in 2004, and NIST standardized it as SP 800-38D in 2007 [@mcgrew2004-gcm][@sp80038d]. GCM is everything CCM is not: one pass, fully parallelizable, and, on any CPU with AES-NI and CLMUL, blisteringly fast. It is the internet default, and AES-128-GCM is the single mandatory-to-implement (MUST) AEAD cipher suite in TLS 1.3, per RFC 8446 Section 9.1 -- a status the spec grants to no other AEAD [@rfc8446]. To understand every later failure, you need one fact about how its tag works.

An authenticator of the form $\text{tag} = H_k(\text{message}) + s$, where $H_k$ is a fast keyed universal hash and $s$ is a **one-time** secret mask. It is unforgeable only if $s$ is never reused. Repeat the mask and the algebraic structure of $H_k$ leaks. This is the shared root of both GHASH (AES-GCM) and Poly1305 (ChaCha20-Poly1305) [@bernstein-poly1305].

GCM's tag is a one-time Wegman-Carter MAC. GHASH evaluates a polynomial over the finite field $\mathrm{GF}(2^{128})$, with the ciphertext and associated-data blocks as coefficients, at a single secret point $H = \operatorname{AES}_k(0^{128})$. It then masks the result with a per-nonce keystream block:

$$T = \operatorname{GHASH}_H(A, C) \oplus \operatorname{AES}_k(J_0), \qquad H = \operatorname{AES}_k(0^{128})$$

where $J_0$ is the initial counter block derived from the nonce. The mask $\operatorname{AES}_k(J_0)$ is the one-time secret $s$. It is one-time only because the nonce is unique. Repeat the nonce and you repeat $J_0$, so you repeat the mask, and now two tags share it -- which turns GHASH's linear structure into a system of polynomial equations an attacker can solve.

The universal hash inside AES-GCM: a polynomial in the secret point $H = \operatorname{AES}_k(0^{128})$ evaluated over $\mathrm{GF}(2^{128})$. Because the polynomial is linear in its coefficients, recovering $H$ lets an attacker forge tags for chosen messages [@joux2006]. flowchart LR N["Nonce and counter"] --> CTR["AES counter mode"] K["Key"] --> CTR CTR --> KS["Keystream"] P["Plaintext"] --> X(("XOR")) KS --> X X --> C["Ciphertext"] C --> GH["GHASH polynomial at secret point H"] AD["Associated data"] --> GH K --> H["H is AES of the zero block"] H --> GH GH --> M(("XOR one-time mask")) K --> J["AES of the first counter block"] J --> M M --> T["Authentication tag"]

That single design choice hands GCM two sharp edges the rest of this article pays for. The first is the nonce contract: reuse is not a weakness, it is a detonator.

Note: For every nonce-respecting AEAD -- AES-GCM, ChaCha20-Poly1305, AES-CCM, OCB3, AEGIS, and Ascon -- one repeated (key, nonce) pair is an immediate, total break of confidentiality for those two messages, and, with a second collision, of authenticity for the whole key [@joux2006].One nonce collision leaks $P_1 \oplus P_2$ right away. Uniquely pinning the secret point $H$ for universal forgery generally needs at least two collisions, since a single pair of equations leaves multiple candidate roots. "One repeat is game over for those messages" is correct; "one repeat exposes $H$" is not quite [@bock2016].

The second edge is quieter and just as dangerous, because it is two different numbers people constantly merge into one.

Note: SP 800-38D fixes a per-message plaintext limit of $2^{39}-256$ bits (about 64 GiB), set by 32-bit counter-mode block-space exhaustion, and, separately, a per-key invocation cap of roughly $2^{32}$ messages when nonces are random 96-bit values, driven by the birthday bound on nonce collision [@sp80038d]. These are two different mechanisms, not two readings of one bound (the full derivation is in Section 8). The multi-user bounds that justify TLS 1.3's nonce randomization are tight [@htt2018-gcm]. Enforce both limits. Conflating them is the single most common accuracy error on this primitive.

GCM gave the internet a one-pass, hardware-fast AEAD, and in the same stroke handed it a mode where one repeated nonce is not a bug but a catastrophe. This is the same GCM negotiated inside shipping Windows protocols such as Schannel TLS and SMB 3 encryption [@ms-schannel-tls][@ms-smb-encryption]. Antoine Joux saw the danger in 2006 [@joux2006]. It took the rest of the world ten years, and a scan of the live internet, to believe him.

4. A Trunk With Branches

The family tree of AEAD is not a ladder from worst to best. Draw it that way and none of the modern constructions make sense, because none of them strictly dominates GCM. Draw it correctly and the whole field snaps into focus: it is a trunk with branches. The trunk is linear -- generic composition, then single-pass native AE, then the welded deployed modes CCM and GCM. Then, at GCM, the tree splits, because GCM's edges each forced a separate successor. No later generation wins. That is the entire point.

flowchart TD G0["Generic composition, Encrypt-then-MAC"] --> G1["Single-pass native AE, IAPM and OCB"] G1 --> G2["Welded deployed modes, CCM and GCM"] G2 --> E1["Nonce edge"] G2 --> E2["Hardware edge"] G2 --> E3["Commitment edge"] E1 --> S1["SIV and AES-GCM-SIV, misuse-resistant"] E2 --> S2["ChaCha20-Poly1305, constant-time in software"] E2 --> S4["AEGIS and Ascon, hardware and footprint co-design"] E3 --> S3["Committing transforms, added on top"]

The hardware edge: ChaCha20-Poly1305

GHASH is hard to make constant-time without the CLMUL instruction, and table-based AES is both slow and timing-leaky without AES-NI. Around 2013, that was the reality on most phones and ARM chips: no AES hardware, so GCM was either slow or a cache-timing side channel. Daniel Bernstein's answer kept GCM's exact nonce-respecting contract but threw out the parts that needed special silicon.

ChaCha20 is an ARX cipher -- addition, rotation, XOR -- with no S-box tables to leak timing, so it is constant-time by construction [@bernstein-chacha]. Poly1305 is a one-time Wegman-Carter MAC over a prime field rather than $\mathrm{GF}(2^{128})$, and its one-time key is derived from a ChaCha keystream block [@bernstein-poly1305].Poly1305's one-time key comes from a ChaCha-derived block, not from AES. ChaCha20-Poly1305 never calls AES at all -- a common misconception, since GCM's mask does use AES.

The IETF standardized the pair as an AEAD in RFC 8439 [@rfc8439], and it now protects TLS 1.3, WireGuard, OpenSSH, and the age file-encryption tool [@wireguard-protocol][@openssh-chacha][@age-spec]. Its normative status is widely overstated: in TLS 1.3, ChaCha20-Poly1305 is a recommended (SHOULD) cipher suite, not mandatory-to-implement, per RFC 8446 Section 9.1 -- a default by adoption, not by requirement [@rfc8446]. It is not weaker than GCM; it is the same nonce contract on a different, table-free engine.XChaCha20-Poly1305 extends the nonce to 192 bits, large enough that random nonces essentially never collide. That is a mitigation of nonce-collision anxiety, not misuse-resistance -- reuse the full 192-bit nonce and it fails exactly like GCM.

The nonce edge: misuse-resistance and SIV

Every mode so far detonates on a repeated nonce, and reuse keeps happening in the real world: cloned virtual machines that resume with identical RNG state, counters reset by a crash, embedded devices with weak entropy at first boot. If the operator cannot guarantee uniqueness, the fix is a mode that survives the operator's mistake. In 2006, Phillip Rogaway and Thomas Shrimpton formalized exactly that goal and built the first construction for it [@rs2006].

An AEAD whose failure under a repeated nonce is graceful, not catastrophic. Repeating a `(key, nonce, associated_data, plaintext)` tuple leaks only whether two encryptions were of the *same* message -- message equality -- and nothing else. It never leaks a plaintext XOR and never hands over the authentication subkey [@rs2006][@rfc8452].

The mechanism is a single clean idea: derive the initialization vector synthetically, as a pseudorandom function of the entire message, rather than accepting it from the caller. The tag is the IV.

A construction in which the initialization vector is computed as a MAC over the associated data and the full plaintext, then reused as the authentication tag. Two different messages under a repeated nonce produce different synthetic IVs, so their keystreams differ and nothing leaks [@rs2006]. flowchart TD K["Key"] --> MAC["MAC over associated data and full plaintext"] AD["Associated data"] --> MAC N["Nonce"] --> MAC P["Plaintext"] --> MAC MAC --> IV["Synthetic IV, which is also the tag"] IV --> CTR["Counter-mode encryption"] K --> CTR P --> CTR CTR --> C["Ciphertext"] IV --> T["Tag sent alongside ciphertext"]

That picture also explains the price, which returns as a theorem in Section 8: to compute the IV you must read the whole message first, so SIV cannot emit its first ciphertext byte until it has seen the last plaintext byte. It is inherently two-pass.

Two deployable forms exist. AES-SIV, standardized by Dan Harkins in RFC 5297, targets deterministic authenticated encryption and key wrapping [@rfc5297]. AES-GCM-SIV, from Shay Gueron, Adam Langley, and Yehuda Lindell in RFC 8452, keeps AES-NI and CLMUL speed while adding misuse-resistance, building on the Gueron-Lindell GCM-SIV design [@rfc8452][@gl2015-gcmsiv].AES-GCM-SIV hashes with POLYVAL, a little-endian sibling of GHASH, and derives a fresh message-authentication and encryption key per nonce -- a structure whose tight multi-user bounds were later established by Bose, Hoang, and Tessaro [@bht2018].

"...two authenticated encryption algorithms that are nonce misuse resistant -- that is, they do not fail catastrophically if a nonce is repeated." -- RFC 8452 [@rfc8452]

Read that phrasing carefully, because it is the most misquoted sentence about SIV. "Do not fail catastrophically" is not "do not fail." A repeated nonce in AES-GCM-SIV still leaks message equality: an attacker learns that two ciphertexts encrypt the same plaintext, which is a real and sometimes serious leak. SIV makes reuse survivable, never free.

The elegance detour: OCB3 and the patent that chose a standard

Two edges now had answers, each on its own branch. A third construction sits off to the side -- not because it is worse, but because history was unkind to it. OCB3, finalized by Ted Krovetz and Phillip Rogaway in 2011 and standardized as RFC 7253, is arguably the most elegant AEAD ever standardized: one block-cipher key, one pass, fully parallel, roughly one cipher call per block [@kr2011-ocb3][@rfc7253].

Its mechanism is where the elegance lives. Each block is masked by a key-derived offset -- $\text{Offset}i = \text{Offset}{i-1} \oplus L_{\text{ntz}(i)}$, a Gray-code walk over precomputed $L$ values -- and wrapped as $C_i = \text{Offset}_i \oplus \operatorname{ENCIPHER}(K, P_i \oplus \text{Offset}_i)$, while a single running plaintext checksum, $\text{Checksum} = P_1 \oplus P_2 \oplus \cdots$, produces the tag in the same pass [@rfc7253]. No second key, no separate MAC. It matches or beats GCM in software. And it lost anyway -- not for a technical reason.A widely repeated claim is that OCB3 is inverse-free. It is not. OCB-DECRYPT recovers each block as $P_i = \text{Offset}_i \oplus \operatorname{DECIPHER}(K, C_i \oplus \text{Offset}_i)$, calling the block-cipher inverse $E_K^{-1}$ (RFC 7253 Section 4.3), so a hardware implementation needs both the AES encrypt and decrypt circuits [@rfc7253]. Inverse-free is the property of the CTR, stream, and sponge modes -- AES-GCM, AES-CCM, ChaCha20-Poly1305, AEGIS, and Ascon -- and OCB is precisely the lineage that trades it away for single-primitive elegance.

OCB was patented from birth. When the 802.11i working group picked WPA2's cipher in 2003, it passed over OCB precisely because of those patents and chose the unencumbered CCM instead. Rogaway later granted free licenses for open-source and non-military use, but the damage was done: every major protocol had already standardized on GCM and ChaCha20-Poly1305 in the years the patents were live. In 2021 Rogaway released OCB into the public domain outright -- too late to matter [@kr2021-ocb]. The honest answer to "when should I reach for OCB3 in 2026?" is "almost never, and the reason is a patent grave, not a design flaw."

The dead end: OCB2 and the limits of "provably secure"

There is one more branch, and it is a warning. Between OCB1 and OCB3 sat OCB2, an ISO-standardized refinement with a security proof. In 2019, Akiko Inoue, Tetsu Iwata, Kazuhiko Minematsu, and Bertram Poettering broke it outright: universal forgery and full plaintext recovery, because OCB2 used the XEX* tweakable cipher outside the regime its proof actually covered [@inoue2019-ocb2].

The OCB2 break is the cautionary counterpoint to every "but it has a proof" argument. OCB2 was standardized by ISO/IEC and carried a published security proof, and it was still broken end to end. A proof secures a *model*; if the construction steps outside the model's assumptions, the proof guarantees nothing. Tellingly, the same attack left OCB1 and OCB3 untouched [@inoue2019-ocb2] -- a dead-end twig on a branch whose siblings survived.

Two of GCM's three edges now had dedicated successors, and the family tree looked complete. But every construction so far -- GCM, ChaCha20-Poly1305, even the misuse-resistant SIV family -- quietly shared a third assumption nobody had thought to check: that "authenticated" meant "bound to one key." In 2018, that assumption broke in production, on the desk of a Facebook security engineer holding a single file with two faces.

5. The Commitment Reckoning and the CAESAR Crucible

Now we can explain the salamanders. Recall the mechanism from Section 3: a GCM tag is a one-time Wegman-Carter value, $\operatorname{GHASH}_H(A,C) \oplus \operatorname{AES}_k(J_0)$, and GHASH is linear in its coefficients. An attacker who gets to pick two keys, $k_1$ and $k_2$, can treat "make the tag verify under both" as a system of linear equations over $\mathrm{GF}(2^{128})$ and simply solve it, producing one ciphertext that decrypts to two chosen, meaningful plaintexts and passes verification under each key [@dodis2018-salamander].

Nothing is broken. GCM guarantees confidentiality and integrity; it never promised that a ciphertext binds to a single key. That promise has a name, and until 2018 almost nobody was asking for it.

A graded robustness property beyond confidentiality and integrity. CMT-1 means a ciphertext binds to exactly one *key*; CMT-4 means it binds to the full *context* -- key, nonce, associated data, and message. Bellare and Hoang proved that CMT-1 does not imply CMT-4: committing to the key is strictly weaker than committing to everything [@bh2022-commit]. RFC 9771 standardized the vocabulary [@rfc9771].

Key idea: "Authenticated" never meant "committed." An AEAD's guarantees -- IND-CPA plus INT-CTXT -- say nothing about binding a ciphertext to one key. Commitment is a third, orthogonal axis. That is why every default AEAD was non-committing and nobody noticed for fifteen years: the property was simply outside the definition everyone was proving.

Two ideas define the modern state of the art, and both come from refusing to treat "cipher plus separate hash" as the end of the design space.

The first is robustness as an explicit goal -- against the operator and against the adversary who supplies the key. The operator side is MRAE from Section 4, elevated from a mode into a principle. The adversary side is committing AEAD, and its timeline is a tidy example of a theoretical curiosity becoming an operational threat.

Invisible salamanders (2018) showed a non-committing AEAD could defeat message franking [@dodis2018-salamander]. Then, in 2021, Julia Len, Paul Grubbs, and Thomas Ristenpart turned it into a weapon: partitioning oracle attacks use the missing commitment to recover passwords and other low-entropy keys, crafting one ciphertext that decrypts under many candidate keys and using each success or failure to bisect the key space [@len2021-partition].

Mihir Bellare and Viet Tung Hoang then built the graded CMT-1 through CMT-4 theory and cheap transforms that add full commitment with no ciphertext-size increase [@bh2022-commit]; Ange Albertini and coauthors independently catalogued the abuses and a padding-based fix [@albertini2022], with further theory from John Chan and Phillip Rogaway [@chan2022]. Sanketh Menda and coauthors then showed the gap is portfolio-wide, with context-discovery attacks against CCM, EAX, SIV, GCM, and OCB3 [@menda2023]. RFC 9771 (2025) finally fixed the vocabulary the field had been improvising [@rfc9771].

A vetted AEAD gives you confidentiality and integrity and stops there. Commitment is a third axis nobody put in the definition -- which is exactly why one ciphertext could wear two faces.

The second idea is native co-design: stop bolting a cipher to a hash and instead build the AEAD around the hardware or footprint you actually have. Hongjun Wu and Bart Preneel's AEGIS (2013) is the AES-hardware extreme [@wu2013-aegis].

It keeps a large internal state -- eight 128-bit words in AEGIS-128L -- seeded directly from the key and nonce; the AES round function updates that state as it absorbs associated data and plaintext, encryption squeezes a keystream out of the state, and the tag comes from the finalized state. One primitive, one pass, no separate hash, and the IETF draft records that all variants are inverse-free and built from the AES encryption round [@aegis-draft18].

That structure is why AEGIS outruns GCM on AES silicon, and why nonce reuse is catastrophic: the whole state is a function of (key, nonce), so a repeat lets an attacker unwind it. Its commitment story is a nuance, not a headline -- a 128-bit AEGIS tag delivers only about 64-bit committing security, while a 256-bit tag pushes cross-key collisions out of reach, so AEGIS is partially committing by tag length, neither fully committing nor flatly broken [@aegis-draft18].

At the other extreme, Ascon -- by Christoph Dobraunig, Maria Eichlseder, Florian Mendel, and Martin Schläffer -- uses a single lightweight permutation in a sponge, giving a tiny gate count and a side-channel-friendly structure for constrained hardware [@ascon2021].

flowchart LR KN["Key and nonce"] --> ST["Large internal state, eight 128-bit words"] ST --> UP["AES round function update"] AD["Associated data"] --> UP P["Plaintext"] --> UP UP --> KS["Squeezed keystream"] P --> X(("XOR")) KS --> X X --> C["Ciphertext"] UP --> FIN["Finalized state"] FIN --> T["Authentication tag"] A mode built from one public permutation whose state is split into a "rate" (absorbs input and is squeezed for output) and a "capacity" (the hidden security margin). A single permutation absorbs the key, nonce, associated data, and plaintext, then squeezes keystream and a tag -- no separate cipher and hash. Ascon is a sponge [@ascon2021].

What forced this whole portfolio into existence was a contest. The CAESAR competition (2013-2019), organized by Daniel Bernstein, was a public, multi-year, break-it-in-the-open bake-off [@caesar-home]. Its most important decision was structural: rather than crown a single winner, it selected a portfolio across three use cases -- itself the thesis of this article. The winners were Ascon and ACORN for lightweight use, AEGIS-128 and OCB for high-performance use, and Deoxys-II (first choice) and COLM for defense in depth [@caesar-portfolio].Deoxys-II is built on the TWEAKEY framework for tweakable block ciphers, by Jérémy Jean, Ivica Nikolić, Thomas Peyrin, and Yannick Seurin [@caesar-portfolio].

Note carefully: Deoxys-II is a CAESAR winner, not an also-ran -- it simply was never deployed at scale. The real also-rans are the candidates eliminated during the competition, including MORUS, which took a certificational break from Tomer Ashur, Maria Eichlseder, and coauthors and did not make the final portfolio [@morus2018].

The competition ended in 2019 with no single champion, on purpose. So where does that leave a working engineer in 2026, staring at seven names in a crypto library's documentation? To choose well, you need the current map: exactly what each construction is, where it wins, and where it bites.

6. The 2026 Portfolio, Precisely

The current portfolio has a stable shape: two defaults and five specialists. By deployment, the two internet defaults are AES-GCM and ChaCha20-Poly1305 -- but normatively they are not equals. In TLS 1.3 only AES-128-GCM is mandatory-to-implement (MUST); AES-256-GCM and ChaCha20-Poly1305 are both recommended (SHOULD), the same normative level as each other, per RFC 8446 Section 9.1 [@rfc8446]. Everything else is a deliberate escalation. Here is each construction on its edges.

AES-GCM. Counter mode plus a one-time GHASH tag; one pass, parallel, O(1) online state [@mcgrew2004-gcm]. Excels on any CPU with AES-NI and CLMUL, which is every server and most modern clients. Struggles on hardware without those instructions and, above all, on nonce discipline: reuse is fatal and the two ceilings are easy to breach [@sp80038d]. Adoption: the internet default.

ChaCha20-Poly1305. ARX stream cipher plus a prime-field one-time MAC; constant-time in pure software with no lookup tables [@rfc8439]. Excels precisely where GCM struggles -- phones, embedded ARM, any target without AES hardware. Same nonce contract as GCM, so it struggles on the exact same reuse cliff. Adoption: TLS 1.3, WireGuard, OpenSSH [@wireguard-protocol][@openssh-chacha].

AES-CCM. Counter mode plus CBC-MAC; two passes, serial, needs the length up front, but all-AES and tiny [@rfc3610]. Excels in constrained stacks (BLE [@bluetooth-core], Zigbee [@ieee802154]) and inside WPA2 [@ieee80211i]. Struggles on throughput and streaming, and the truncated CCM_8 tag trades a real forgery budget for eight bytes [@rfc3610]. Adoption: enormous by device count.

AES-GCM-SIV and AES-SIV. Synthetic-IV misuse-resistant modes; two-pass by necessity [@rfc8452][@rfc5297]. Excel when nonce uniqueness cannot be guaranteed: reuse degrades to leaking message equality rather than catastrophe. Struggle on streaming (they must buffer) and still leak equality, so they are survivable, not free. AES-GCM-SIV runs near AES-GCM speed on server hardware, around 0.92 cycles per byte on Broadwell in the original design [@gl2015-gcmsiv]. Adoption: growing where reuse risk is real.

OCB3. One block-cipher key, one pass, fully parallel, roughly one cipher call per block -- technically superb [@kr2011-ocb3][@rfc7253]. Excels on elegance and software speed. Struggles on adoption, for the patent reasons in Section 4; it is nonce-respecting like GCM; and, unlike the CTR and stream modes, it is not inverse-free -- decryption calls the AES inverse circuit (RFC 7253 Section 4.3), a genuine hardware cost [@rfc7253]. Adoption: minimal, despite standardization.

AEGIS. Keystream and authentication driven straight from the AES round function over a large nonce-seeded state; the throughput frontier, around 0.48 cycles per byte for AEGIS-128L on 4 KB messages, faster than CCM, GCM, and OCB [@wu2013-aegis][@aegis-v11]. Excels on raw speed when you control both endpoints. Struggles on maturity and contract: nonce-respecting (catastrophic on reuse, since its whole state is nonce-seeded) and only partially committing -- about 64-bit committing security at a 128-bit tag, stronger at a 256-bit tag [@aegis-draft18].

Critically, AEGIS is still an active Internet-Draft, draft-irtf-cfrg-aegis-aead-18 from October 2025, not an RFC -- it states plainly that it "is not an IETF product and is not a standard," and it expires on 8 April 2026 [@aegis-draft18].

Ascon-AEAD128. A single 320-bit lightweight permutation in a sponge; tiny state, side-channel-friendly [@ascon2021]. Excels on constrained hardware and gate count. Struggles on server throughput, where AEGIS and GCM win. It is nonce-respecting, but -- unlike the CTR and stream modes -- it commits to its inputs without any added transform: the tag is squeezed from the sponge's large hidden capacity after that capacity has already absorbed the key, so one ciphertext binds natively to the key it was produced under. RFC 9771 lists Ascon-AEAD128 as both key-committing and full-committing as-is, not merely as a candidate for a bolt-on fix [@rfc9771]. The currency fact matters here: NIST SP 800-232 is final (August 2025) and standardizes Ascon-AEAD128, a tweaked variant of CAESAR Ascon-128 using a larger data-absorption rate -- widely reported as 128-bit, up from the CAESAR design's 64-bit, with the exact parameter in the SP 800-232 body [@sp800232][@nist-ascon-2023]. It is not byte-identical to CAESAR Ascon [@ascon-site].

A profile only helps if you can actually call the construction, so here is where each one ships as of mid-2026, with each cell cited to that project's official documentation.

Construction	Where it ships (libraries and frameworks)
AES-GCM	OpenSSL/BoringSSL [@openssl-aes][@boringssl-aead], Go `crypto/cipher` [@go-cipher], Java JCA [@java-jca], .NET CNG [@dotnet-aesgcm], WebCrypto (the only AEAD in the browser) [@webcrypto], libsodium (hardware-gated) [@libsodium-aegis]
ChaCha20-Poly1305 / XChaCha20	OpenSSL/BoringSSL [@openssl-chacha][@boringssl-aead], libsodium (default for random-nonce APIs) [@libsodium-aegis], Go `x/crypto` [@go-chacha], WireGuard [@wireguard-protocol], OpenSSH [@openssh-chacha], `age` [@age-spec]
AES-CCM	mbedTLS [@mbedtls-ccm], wolfSSL [@wolfssl-ccm], Wi-Fi [@ieee80211i] / BLE [@bluetooth-core] / Zigbee [@ieee802154] firmware
AES-GCM-SIV	BoringSSL/OpenSSL [@boringssl-aead][@openssl-aes] and several bindings; less universal than the defaults
AES-SIV	`miscreant`-lineage (deterministic / key-wrap) libraries [@miscreant]
OCB3	some libraries (public domain since 2021 [@kr2021-ocb]); rarely a default
AEGIS	libsodium (`crypto_aead_aegis128l` / `aegis256`) [@libsodium-aegis] and a growing set of high-performance libraries; not a TLS suite
Ascon-AEAD128	reference and third-party implementations [@ascon-site]; adoption ramping since SP 800-232 [@sp800232]

Two entries on that map decide real architectures. In the browser, AES-GCM is the only AEAD you can call.WebCrypto's SubtleCrypto.encrypt recognizes RSA-OAEP, AES-CTR, AES-CBC, and AES-GCM, and AES-GCM is the only one of those that authenticates. Browser JavaScript that needs an AEAD without bundling a crypto library therefore has exactly one option [@webcrypto]. And AEGIS, still pre-RFC, is nonetheless callable in production today through libsodium's crypto_aead_aegis128l and crypto_aead_aegis256 APIs -- deployability and standardization are not the same axis [@libsodium-aegis].

Note: Eight constructions -- the seven cipher families, with the SIV line counted in its two deployable forms (AES-GCM-SIV and AES-SIV) -- all linear-time, all vetted, and not one strictly dominates the others. CAESAR chose a portfolio across three use cases on purpose, and NIST added Ascon for the constrained end. There is no "best AEAD," and any article or vendor that names one is hiding an assumption about your deployment [@caesar-portfolio].

Two more items complete the 2026 map. The CAESAR defense-in-depth winners, Deoxys-II and COLM, remain excellent and essentially undeployed [@caesar-portfolio]. And committing transforms -- the fix for the commitment edge -- exist and are cheap, but as of mid-2026 none is mandated in a shipping standard; RFC 9771 supplies vocabulary, not a required construction [@rfc9771][@bh2022-commit].

Laid side by side, those eight look interchangeable. They are not, and the tool that makes the difference legible is a single table built on the three edges.

7. The Decision Matrix

This is the one screen to memorize. Everything in the previous six sections collapses into two tables and a flowchart, all built on the same three edges.

The first table answers the only question that matters at selection time: for each construction, what happens on the first repeated nonce, what hardware does it want, and does one ciphertext bind to one key?

Construction	First repeated nonce	Hardware profile	Commitment
AES-GCM	Catastrophic: leaks P1 XOR P2, enables forgery	AES-NI + CLMUL fast	Not committing
ChaCha20-Poly1305	Catastrophic: same one-time-MAC cliff	Constant-time in software	Not committing
AES-CCM	Catastrophic	All-AES, tiny footprint	Not committing
AES-GCM-SIV	Graceful: leaks message equality only	AES-NI + CLMUL	Not committing
AES-SIV	Graceful: leaks message equality only	All-AES, two-pass	Not committing
OCB3	Catastrophic	Fast one-pass software	Not committing
AEGIS	Catastrophic	AES round function, fastest	Not fully committing
Ascon-AEAD128	Catastrophic	A few thousand gates	Committing from the sponge, no transform

Read down the commitment column and the reckoning of Section 5 gets sharper than a flat "nobody commits." Every deployed CTR, stream, and welded construction -- AES-GCM, ChaCha20-Poly1305, AES-CCM, the SIV family, and OCB3 -- is non-committing by default, which is exactly what the salamander and the portfolio-wide context-discovery attacks exploit [@dodis2018-salamander][@menda2023]. Two constructions break the pattern, and it is no accident that both fuse the tag with the cipher state instead of bolting on a separate hash: AEGIS partially commits through tag length, and Ascon commits natively from its sponge [@aegis-draft18][@rfc9771]. So commitment is not a uniform failure across the portfolio -- the commitment edge is a real axis of variation, with Ascon at the strong end, AEGIS in between, and the CTR, stream, and welded modes needing a bolt-on transform. Read the nonce column and only the SIV family survives a repeat, and only by leaking equality [@rfc8452]. The second table adds the structural and performance facts you need once the edges are settled.

Construction	Passes / parallel	Online state	Nonce	Tag	Reported speed	Inverse-free?	Best suited for
AES-GCM	1 pass, parallel	`O(1)`	96-bit	128-bit	~1 cpb with AES-NI	Yes	The default, server and client
ChaCha20-Poly1305	1 pass	`O(1)`	96-bit	128-bit	Fast in pure software	Yes	Targets without AES hardware
AES-CCM	2 pass, serial	`O(1)`	7 to 13 byte	128-bit (`CCM_8`: 64)	Modest	Yes	Constrained stacks, WPA2
AES-GCM-SIV	2 pass	`O(n)` buffered	96-bit	128-bit	~0.92 cpb on Broadwell	Yes	Nonce-reuse risk
AES-SIV	2 pass	`O(n)` buffered	None or supplied	128-bit	Modest	Yes	Key wrap, deterministic AE
OCB3	1 pass, parallel	`O(1)`	up to 120-bit	up to 128-bit	Fast in software	No (needs AES decrypt)	Elegance (now patent-clear)
AEGIS	1 pass, parallel	`O(1)`	128 or 256-bit	128 or 256-bit	~0.48 cpb (AEGIS-128L)	Yes	Maximum throughput, both endpoints
Ascon-AEAD128	1 pass	`O(1)`	128-bit	128-bit	Small, not server-fast	Yes	New constrained designs

Reported speeds are platform-dependent and should be read against live cross-platform benchmarks rather than a single headline number; the AEGIS and GCM-SIV figures come from their design papers, and the ECRYPT benchmarking project tracks the rest across many CPUs [@wu2013-aegis][@gl2015-gcmsiv][@bench-aead]. One column earns a second look: OCB3 is the only full-treatment construction that is not inverse-free, so it alone needs the AES decrypt circuit in hardware -- the honest cost behind its elegance [@rfc7253].

The tables classify. To choose, turn them into a procedure. The flowchart below is the thesis rendered as a decision tree: branch on the nonce guarantee first (it is the edge that fails hardest), then on hardware, and treat commitment as an orthogonal final step because no default provides it.

flowchart TD Q1{"Can you guarantee a unique nonce per key?"} Q1 -->|No| SIV["AES-GCM-SIV: move on the nonce edge"] Q1 -->|Yes| Q2{"AES-NI and CLMUL on both endpoints?"} Q2 -->|Yes| GCM["AES-GCM"] Q2 -->|No| Q2b{"Server or mobile software, or a constrained device?"} Q2b -->|Software| CC["ChaCha20-Poly1305"] Q2b -->|Constrained| ASC["Ascon-AEAD128"] SIV --> Q3{"Must one ciphertext bind to exactly one key?"} GCM --> Q3 CC --> Q3 ASC --> Q3 Q3 -->|Yes| ADD["Add a key-commitment transform, unless it already commits like Ascon"] Q3 -->|No| DONE["Ship it"]

The argument is now explicit and testable. "Which AEAD?" reduces to "which edge can your deployment guarantee it never triggers?" If you cannot guarantee nonce uniqueness, move right on the nonce edge to the SIV family. If you have no AES hardware, move on the hardware edge to ChaCha20-Poly1305 or, for a constrained device, Ascon. If a ciphertext must bind to exactly one key, you must add something on the commitment edge, because none of the defaults gives it to you. You can even write the function down.

{` // "Which AEAD?" is a function of three edges, not a ranking. function chooseAEAD({ nonceUnique, hasAesHardware, constrained, mustCommitToKey }) { let pick; if (!nonceUnique) { pick = 'AES-GCM-SIV'; // edge 1: cannot guarantee unique nonces } else if (hasAesHardware) { pick = 'AES-GCM'; // the internet default when AES-NI + CLMUL are present } else if (constrained) { pick = 'Ascon-AEAD128'; // edge 2: no AES hardware, only a few thousand gates } else { pick = 'ChaCha20-Poly1305'; // edge 2: no AES hardware, constant-time in software } // edge 3 is orthogonal: most picks do not commit, so you must ADD a transform -- // except Ascon, which already commits natively from its sponge (RFC 9771). const alreadyCommits = pick === 'Ascon-AEAD128'; return (mustCommitToKey && !alreadyCommits) ? pick + ' + key-commitment transform (this construction does not bind to one key)' : pick; }

console.log(chooseAEAD({ nonceUnique: true, hasAesHardware: true, constrained: false, mustCommitToKey: false })); console.log(chooseAEAD({ nonceUnique: false, hasAesHardware: true, constrained: false, mustCommitToKey: false })); console.log(chooseAEAD({ nonceUnique: true, hasAesHardware: false, constrained: false, mustCommitToKey: false })); console.log(chooseAEAD({ nonceUnique: true, hasAesHardware: true, constrained: false, mustCommitToKey: true })); `}

"Which AEAD should I use?" is not a ranking from worst to best. It is a function: pick the one whose failure mode your deployment can guarantee it will never trigger.

The table tells you which edge to move. It does not tell you why you sometimes cannot move all of them at once -- why there is no row that is graceful on reuse and single-pass and fully committing and fastest. That absence is not a gap in the engineering. It is a theorem.

8. The Limits Are Theorems

Everything so far has been a design choice: move an edge here, pay for it there. Now the hard walls -- the places where no cleverness helps, because a proof says so. There are four, and each maps to an edge; the standard graduate references develop these bounds in full [@boneh-shoup][@katz-lindell].

GCM's two ceilings, correctly attributed (the nonce edge). GCM's two limits from SP 800-38D are not conservative engineering guesses; they are where the security proof runs out -- and they come from two different mechanisms people constantly merge into one.

The per-message limit of $2^{39}-256$ bits (about 64 GiB) is 32-bit counter-mode block-space exhaustion, not a GHASH property: with a 96-bit nonce GCM forms the initial counter block $J_0 = \mathrm{IV} \parallel 0^{31} \parallel 1$, the increment function advances only the low 32 bits, so counter mode emits at most $2^{32}-2$ keystream blocks, and $(2^{32}-2)\times 128$ bits $= 2^{39}-256$ bits; exceed it and the counter wraps, repeating a keystream block -- a two-time pad (SP 800-38D Section 5.2.1.1) [@sp80038d].

The per-key cap of roughly $2^{32}$ messages under random 96-bit nonces is a different quantity entirely: the birthday bound on nonce collision, where with $q$ messages the probability of a repeat scales as $q^2 / 2^{96}$, so $q \approx 2^{32}$ keeps it negligible (SP 800-38D Section 8.3) [@sp80038d]. Hoang, Tessaro, and Thiruvengadam proved these multi-user bounds tight, validating the nonce-randomization mechanism TLS 1.3 uses [@htt2018-gcm].

Tag length obeys its own bound: for a one-time Wegman-Carter MAC, forgery probability grows with the number of attempts and shrinks with tag length -- exactly why a 64-bit CCM_8 tag is a genuine, quantifiable forgery budget rather than a free optimization [@rfc3610].

Misuse-resistance cannot be online (the nonce edge, again). This is the deepest limit in the article, and it explains a design decision that otherwise looks like laziness. Rogaway and Shrimpton proved that a deterministic, nonce-misuse-resistant AEAD cannot be online or single-pass [@rs2006]. The reason is forced by the definition: to be misuse-resistant, the ciphertext must depend on the entire plaintext (otherwise two messages sharing a prefix under a repeated nonce would leak that prefix), so the encryptor cannot emit even the first ciphertext byte until it has read the last plaintext byte. There is no implementation trick around it.

Key idea: You cannot have both streaming and misuse-resistance. It is a theorem, not a missing feature: a misuse-resistant AEAD must read the whole message before it can output any ciphertext. That single impossibility is why AES-GCM-SIV is two-pass, and why "just make GCM misuse-resistant without slowing it down" is a request for something that provably does not exist [@rs2006].

Commitment is an orthogonal axis (the commitment edge). A conventional CTR-based AEAD like GCM is provably not key-committing -- the property is simply absent from IND-CPA and INT-CTXT, so no amount of using GCM "correctly" produces it. Worse, commitment is not one property but a lattice: Bellare and Hoang proved CMT-1 (bind to the key) does not imply CMT-4 (bind to the full context), a separation RFC 9771 later codified [@bh2022-commit][@rfc9771].

And the attacks are cheaper than the naive birthday intuition suggests: Menda and coauthors found context-discovery attacks against CCM, EAX, SIV, GCM, and OCB3, including an $O(2^{n/3})$ attack on SIV using Wagner's k-tree algorithm -- well below the $2^{n/2}$ a birthday bound would suggest [@menda2023].

Releasing plaintext early is a strictly weaker world (all edges). The fourth limit is about what your decrypt function is allowed to do before it finishes.

What an implementation exposes if it emits decrypted plaintext before checking the authentication tag. The formal integrity notion for this setting, INT-RUP, is codified in RFC 9771 Section 4.3.10; security that survives releasing unverified plaintext is strictly stronger than standard AEAD security, and most fast one-pass modes satisfy it only weakly -- which is why the safe API contract is verify-then-release: never act on plaintext until the tag checks out [@rfc9771].

Now assemble the thought experiment. Imagine the ideal AEAD: graceful on nonce reuse and fully committing and online/single-pass and fastest at both the server and constrained extremes. The second limit rules out "misuse-resistant and online" together. The third makes commitment an add-on that the CTR, stream, and welded defaults lack -- Ascon, uniquely, commits natively. The performance extremes pull in opposite directions -- AES round function for servers, a few thousand gates for sensors. You cannot have all of it in one construction, and this is not because nobody has been clever enough. It is because the properties provably conflict.

Note: No single construction closes all three edges at once. That is not a temporary state of the art -- it is a set of theorems about online-ness, commitment, and hardware. The portfolio is not a failure to converge on a winner; it is the mathematically necessary shape of the solution [@rs2006][@bh2022-commit].

So that is settled, provably. Which turns the interesting question inside out. Not "which mode wins?" but "can we make the robustness the default instead of the expert's opt-in?" That is exactly where the field is fighting right now.

9. Where AEAD Still Bites

The classical problem is closed. For confidentiality and integrity, the bounds are tight and the constructions are vetted. The entire live frontier is about robustness: turning the properties nobody used to ask for into defaults nobody has to remember. Six problems are open, and every one of them has the same shape.

Committing AEAD by default. Salamanders and partitioning oracles still bite wherever a committing transform is omitted, which today means almost everywhere [@dodis2018-salamander][@len2021-partition]. The frustrating part is that the fix is cheap: Bellare and Hoang give transforms that add full commitment with no ciphertext-size increase, and Albertini and coauthors give a padding-based alternative [@bh2022-commit][@albertini2022]. Yet as of mid-2026, none is mandated by a shipping standard. RFC 9771 gives the field a shared vocabulary for the property but does not require any construction to have it [@rfc9771]. The open question is not "how?" but "why is it still opt-in?"

Misuse-resistance by default. If nonce reuse is a recurring operational reality, why is the misuse-resistant mode the escalation rather than the default? The answer is the theorem from Section 8: defaulting to SIV means defaulting to two-pass, non-streaming encryption, and a great deal of infrastructure assumes it can encrypt a stream as it arrives [@rs2006]. Whether that trade is worth making by default is an active argument, not a settled one.

The release-of-unverified-plaintext trade space. Between "buffer everything and verify first" and "stream plaintext out immediately" is a design space that streaming media, large-file transfer, and constrained receivers all care about, and the security definitions there -- INT-RUP and its relatives -- are still maturing [@rfc9771].

Hardware co-design versus conservative margin. AEGIS already beats AES-GCM on AES-NI hardware, and the appetite for line-rate encryption keeps growing [@wu2013-aegis]. Newer AES-round designs push the throughput frontier even higher, but they trade cryptanalytic maturity for speed, and their standardization status is unsettled -- AEGIS itself is still only an Internet-Draft, not an RFC [@aegis-draft18]. How much margin to spend for how much throughput is an open judgment call.

Post-quantum reality, minus the myth. This one is mostly a matter of correcting a widespread misconception.

For symmetric authenticated encryption the honest answer is: no, and you mostly need to change nothing. Grover's algorithm offers at most a square-root speedup on key search, which halves the effective key length [@grover1996], so a 128-bit key gives about 64 bits of margin against a hypothetical quantum attacker. The remedy is simply to prefer 256-bit keys -- ChaCha20 already uses one, and AES-256 is a configuration flag -- and to size tags with a margin. The post-quantum upheaval lives in key exchange and signatures, not the AEAD record layer, as developed in the post-quantum-cryptography-on-Windows post in this collection. Your record encryption survives the transition largely intact.

Constant-time without special hardware. GHASH is hard to implement in constant time without CLMUL, and table-based AES leaks timing without AES-NI -- the exact side-channel pressure that motivated both ChaCha20-Poly1305 and Ascon [@bernstein-chacha][@ascon2021]. On the smallest devices, where neither special instruction exists and power analysis is a live threat, side-channel-resistant AEAD is still an open engineering problem, and it is much of the reason NIST ran a lightweight competition at all.

None of these has a finished answer. But notice the shape of every one: they are all attempts to move an edge to a place where the deployer cannot step on it by mistake -- misuse-resistance you do not have to remember, commitment you do not have to add, side-channel safety you do not have to hand-tune. Which brings us back to the only rule that actually travels.

10. The Field Guide: Rules and Parameters

Everything above collapses into one default and a short list of deliberate escalations. Follow the ladder and you will never again pick an AEAD by folklore.

Note: Default to AES-GCM with a 96-bit nonce that is unique per key (prefer a counter over a random value), a hard cap well under $2^{32}$ messages per key, at most 64 GiB per message, and a full 128-bit tag. Use ChaCha20-Poly1305 under the same contract when you lack AES hardware. Leave the default only when a specific edge forces you, and only in the direction that edge points [@sp80038d][@rfc8439].

The escalation ladder, each rung mapped to the edge it moves:

Cannot guarantee a unique nonce? Escalate on the nonce edge to AES-GCM-SIV [@rfc8452]. Cloned VMs, counters that reset on crash, weak first-boot entropy -- if any of these is in your threat model, the graceful failure is worth the second pass.
A stack mandates it, or the device is tiny? Use AES-CCM where WPA2, BLE, or Zigbee require it [@rfc3610], and Ascon-AEAD128 for new constrained designs, now that it is a NIST standard [@sp800232].
Deterministic encryption or key wrapping? Use AES-SIV, which needs no nonce at all and is built for exactly this [@rfc5297].
You want one-pass, single-primitive elegance? OCB3 is now patent-clear, though rarely the right call given how entrenched the defaults are [@rfc7253][@kr2021-ocb].
You control both endpoints and need maximum throughput? AEGIS is the fastest option, if you can accept a pre-RFC specification [@aegis-draft18][@wu2013-aegis].
Must a ciphertext bind to exactly one key? Add a key-commitment transform -- for password-based encryption, key rotation, message franking, or multi-recipient encryption -- because no default provides it [@bh2022-commit].

Nonce generation itself is the subject of Part 2 of this series; do not re-derive it here, but do treat "unique per key" as a hard contract, not a hope. On Windows, the CNG architecture post in this collection shows AES-GCM exposed through the BCryptEncrypt API with an authenticated-cipher-mode information structure -- a concrete example of the parameters below appearing in a real API.

Pair the ladder with the support map from Section 6 when you check feasibility: browser JavaScript means AES-GCM through WebCrypto, and a target with no AES hardware means ChaCha20-Poly1305 or, if it is also tiny, Ascon-AEAD128 [@webcrypto].

The exact operational contract, per construction:

Construction	Nonce	Tag	Per-key limit	Per-message limit	On nonce reuse
AES-GCM	96-bit, unique	128-bit	~`2^32` msgs (random nonce)	`2^39 - 256` bits, ~64 GiB	Catastrophic
ChaCha20-Poly1305	96-bit, unique	128-bit	~`2^32` msgs (random nonce)	~256 GiB	Catastrophic
AES-CCM	7 to 13 byte	up to 128-bit (`CCM_8`: 64)	Set by nonce length	Set by length field	Catastrophic
AES-GCM-SIV	96-bit	128-bit	Improved (per-nonce derived keys)	~64 GiB	Graceful: message equality
AES-SIV	None or supplied	128-bit	Large	Large	Graceful: message equality
OCB3	up to 120-bit	up to 128-bit	Large	Large	Catastrophic
AEGIS	128 or 256-bit	128 or 256-bit	Large (wide nonce)	Large	Catastrophic
Ascon-AEAD128	128-bit	128-bit	Per SP 800-232	Per SP 800-232	Catastrophic

The only two numeric limits you must hard-code are GCM's, because they are the ones people breach silently: cap messages per key well under $2^{32}$ and messages under 64 GiB each [@sp80038d]. ChaCha20-Poly1305's own ~256 GiB per-message ceiling comes the same way, from its 32-bit block counter over 64-byte blocks ($2^{32}\times 64$ bytes $= 2^{38}$ bytes), per RFC 8439 [@rfc8439]. AES-GCM-SIV's per-nonce key derivation buys better multi-user bounds, which is the whole reason RFC 8452 derives fresh keys rather than reusing one [@bht2018][@rfc8452].

Every rung of that ladder has a mirror image: a misuse pattern that punishes the deployment for stepping on the edge it ignored. Each row below maps a real-code mistake to the named break that catches it.

Misuse seen in real code	Edge it triggers	Named break
Reusing a `(key, nonce)` in GCM or AEGIS	Nonce	Nonce-Disrespecting Adversaries, 2016
Assuming an AEAD binds a ciphertext to one key	Commitment	Invisible salamanders; partitioning oracles
Truncating the tag to save bytes (`CCM_8`)	Integrity budget	Wegman-Carter forgery bound
Treating AES-GCM-SIV reuse as "free"	Nonce	SIV leaks message equality
Hand-rolling Encrypt-and-MAC	Composition	Bellare-Namprempre; Krawczyk
Conflating GCM's two ceilings	Nonce	The two SP 800-38D limits

The evidence for each is in the sections above: nonce reuse on live servers [@bock2016], the salamander and its weaponization [@dodis2018-salamander][@len2021-partition], the tag-length forgery budget [@rfc3610], the SIV equality leak [@rfc8452], the composition theorems [@bn2000][@krawczyk2001], and the two ceilings [@sp80038d]. One extra caution on attribution: the live-TLS nonce-reuse break is repeatedly mis-cited to CVE-2016-0270, which actually names IBM Domino and which the NVD itself flags as commonly misapplied to other products [@cve-2016-0270].

Search your codebase for any AEAD decryption that runs under an attacker-influenced key: password-based encryption, key wrapping, token decryption, or multi-recipient envelopes. If a decrypt path lets the caller supply or guess the key and then branches on whether decryption succeeded, you are exposed to a partitioning oracle and need a key-commitment transform on top of the AEAD [@len2021-partition][@bh2022-commit].

That ladder is your inoculation against folklore. But folklore is sticky, so let us take the most common misconceptions head-on.

11. Seven Beliefs That Get Deployments Broken

No. For every nonce-respecting mode -- AES-GCM, ChaCha20-Poly1305, AES-CCM, OCB3, AEGIS, and Ascon -- a single repeated `(key, nonce)` is an immediate, total break: it leaks the XOR of the two plaintexts, and a second collision hands over the authentication subkey for universal forgery [@joux2006][@bock2016]. Only the SIV family degrades gracefully, and only to leaking message equality [@rfc8452]. No. It makes reuse *survivable*, not free. A repeated nonce still leaks message equality -- an attacker learns that two ciphertexts encrypt the same plaintext -- which can matter a great deal in the right context. Use it as a safety net, not a license to stop managing nonces [@rfc8452][@rs2006]. No to both misreadings. It is a different trade-off on the hardware edge, not a weaker cipher: constant-time in pure software with no lookup tables, which makes it the *stronger* choice on hardware without AES-NI, where table-based AES leaks timing. And it is not mandatory-to-implement in TLS 1.3 -- it is a *recommended* (SHOULD) cipher suite, while only AES-128-GCM is the MUST, per RFC 8446 Section 9.1 [@rfc8446]. Recommended, not weaker, not mandatory. No. Random 96-bit nonces are collision-safe only up to roughly $2^{32}$ messages per key, by the birthday bound. That per-key invocation cap is a different number from the per-message limit of about 64 GiB; enforce both, and prefer a counter over a random nonce when you can [@sp80038d][@htt2018-gcm]. No. Most AEADs are not key-committing. One AES-GCM ciphertext can be built to decrypt to two different meaningful plaintexts under two different keys, with the tag valid both times -- the invisible-salamanders result. If a ciphertext must bind to one key, add a commitment transform [@dodis2018-salamander][@bh2022-commit]. No. AEGIS leads on raw throughput, but it is nonce-respecting (catastrophic on reuse), not fully key-committing, and still an active Internet-Draft rather than an RFC -- it states plainly that it "is not a standard" and expires on 8 April 2026. Fastest is not the same as best for your deployment [@aegis-draft18][@wu2013-aegis]. No. Symmetric authenticated encryption survives the quantum transition. Grover's algorithm only halves effective key length [@grover1996], so prefer 256-bit keys and size tags with margin. The post-quantum upheaval is in key exchange and signatures, not the AEAD record layer. Separately, note that NIST's Ascon-AEAD128 is a tweaked variant of the CAESAR Ascon-128, not byte-identical [@sp800232].

The Function, Not the Ranking

Seven ciphers, one interface, three edges. Every break here was a deployment triggering an edge its designers deliberately moved elsewhere. The invisible salamanders triggered the commitment edge that AEAD never promised to close [@dodis2018-salamander]. The 184 TLS servers triggered the nonce edge that GHASH cannot survive [@bock2016]. The CCM_8 forgery budget is the tag-length edge priced in bits [@rfc3610]. The SIV equality leak is the residue of the one edge SIV does close -- even the fix has a seam [@rfc8452]. And OCB3's near-total absence is the patent grave, an edge that was never technical at all [@kr2021-ocb].

Put them together and the thesis is earned rather than asserted. "Which AEAD should I use?" is not a ranking from worst to best, because Section 8 proved there is no best -- no single construction can be misuse-resistant and single-pass and fully committing and fastest at once. It is a function: pick the construction whose failure mode your deployment can guarantee it will never trigger.

Master the three edges and you can place any construction on the map, predict any misuse before it ships, and evaluate whatever the next competition invents -- key-derivation-bound AEADs, the TLS record layer's next mode, or a lightweight winner that does not exist yet. The names will change. The edges will not.

One Number, Used Twice: How a Repeated Nonce Hands Over Your Private Key -- and How Determinism Takes It Back

noreply@paragmali.com (Parag Mali) — Thu, 09 Jul 2026 10:13:36 GMT

Reuse one number and you can lose everything. A **repeated** ECDSA signing nonce leaks your private key with grade-school algebra: two signatures under the same nonce, one subtraction, one modular inverse, and the key falls out. That is how the Sony PlayStation 3 master key was recovered [@f0f]. A **repeated** AES-GCM initialization vector is just as fatal: it instantly leaks $P_1 \oplus P_2$ and hands an attacker the material to forge authenticated ciphertext [@joux] [@nda]. The fix for both is one counter-intuitive move: stop trusting runtime randomness for the once-per-operation number. Derive it (RFC 6979, EdDSA, hedged signatures) [@rfc6979] [@rfc8032], or make a repeat non-catastrophic (AES-GCM-SIV) [@rfc8452]. One distinction separates understanding from folklore: a *biased* nonce is a *different*, statistical attack needing many signatures, not one [@ns] [@ladderleak].

1. One Number, Used Twice

In December 2010, on stage at the 27th Chaos Communication Congress in Berlin, three researchers working under the name fail0verflow explained how they had recovered the master private key that anchors the entire PlayStation 3 chain of trust [@f0f]. There was no brute force, no exotic side channel, no supercomputer grinding for months. There were two signatures and the kind of algebra you learned before you were old enough to drive. Sony had signed its code with ECDSA, the elliptic-curve digital signature algorithm, and Sony had signed every firmware image with the same secret per-signature number.Two events that are often merged into one: fail0verflow disclosed the constant-nonce flaw at 27C3 in December 2010; George Hotz, known as geohot, separately published an extracted PS3 root key in January 2011 [@geohot]. The talk revealed the mechanism; the key release came afterward. Keep them distinct.

Sit with how strange that is. The console's security rested on a signature scheme that most cryptographers would call sound. AES was not broken. The elliptic curve was not broken. The signature math was not broken. One input was reused, and the entire trust anchor fell out of a schoolbook manipulation that a motivated teenager could reproduce on paper.

Now the mirror image, in a completely different primitive. In 2016, a team scanning the live internet found 184 public HTTPS servers repeating a different one-time number -- the AES-GCM initialization vector -- and reported that this "fully breaks the authenticity of the connections" [@nda]. Not the confidentiality of a lab toy: the authenticity of real TLS sessions on the open web, letting an attacker forge messages the server would accept as genuine.

Same disease, entirely different organ. One is a signature that proves who you are; the other is the cipher that guards most of the web's traffic. Both staked everything on a number that was supposed to be used correctly exactly once.

That shared bet is the subject of this article. Both primitives depend, silently, on a value that must be unique and unpredictable -- once, per key. The precise question: what, exactly, does each stake on that number, and what is the exact cost of getting it wrong? For the repeat case, the answer is total and immediate -- and the algebra is short enough to print in full.

In cryptography, reusing one number can cost you everything.

That is the punchline, and by the end you will have earned it rather than taken it on faith -- the full key-recovery algebra, Antoine Joux's cipher attack, the statistical cousin that needs only a fraction of a leaked bit, and the deterministic designs that dissolve the whole failure family. But how can two signatures undo an entire console's chain of trust? To see it, we first have to meet the number both of these primitives are quietly betting everything on.

2. The Secret Number Both Primitives Depend On

Two algorithms, designed decades and a world apart -- a discrete-logarithm signature and a block-cipher mode of authenticated encryption -- turn out to share a single point of failure. Before we can watch it break, we need to know where the number comes from and why it has to exist at all.

The signature side is the older lineage. ElGamal's 1985 signature scheme introduced a per-signature secret exponent [@elgamal], and when the United States standardized the Digital Signature Algorithm as FIPS 186 in 1994 [@fips186], that per-signature secret came along for the ride. Its elliptic-curve descendant, ECDSA, keeps it. The value is called the signing nonce, written $k$, and it is regenerated fresh for every single signature.

The per-signature secret scalar in (EC)DSA. For each signature the signer draws a new $k$ in the range $[1, n-1]$, where $n$ is the order of the curve's base point. It must be unique, secret, and uniformly distributed -- exactly once per key. It is never transmitted, yet every signature is computed from it.

The cipher side is younger. When NIST standardized Galois/Counter Mode in SP 800-38D in 2007, the specification required that the initialization vector -- the $\text{IV}$, GCM's nonce -- be distinct for every message encrypted under a given key [@sp80038d]. Same structural demand, opposite secrecy requirement: the signing nonce must be secret, while the GCM nonce may be completely public. What both must be is fresh.

The per-message value GCM mixes in so that encrypting under a fixed key never repeats its keystream. Uniqueness under a given key -- not secrecy -- is the entire contract. A public counter is a perfectly good GCM nonce; a *repeated* one is a catastrophe.

Now put the two governing equations side by side. An ECDSA signature on a message whose hash (as an integer) is $z$, under private key $d$, is the pair $(r, s)$:

$$r = (k \cdot G)_x \bmod n, \qquad s = k^{-1},(z + r,d) \bmod n$$

Here $G$ is the fixed base point, $n$ its prime order, $d$ the private key, and $r$ is the x-coordinate of the curve point $k \cdot G$ reduced modulo $n$. The AES-GCM authentication tag on ciphertext $C$ with additional data $A$ is:

$$T = E_K(J_0) \oplus \mathrm{GHASH}_H(A, C), \qquad H = E_K(0^{128})$$

$E_K$ is AES under key $K$; $J_0$ is a pre-counter block derived from the IV; $\mathrm{GHASH}_H$ is a polynomial hash over the field $\mathrm{GF}(2^{128})$ keyed by the secret subkey $H$, which is simply AES applied to the all-zero block.

Look at what both equations hide inside them. The signing equation multiplies the private key $d$ by the public $r$ and masks it behind $k$. The tag equation masks the keyed hash behind the one-time pad $E_K(J_0)$, which is a deterministic function of the nonce. In each case, one freshly chosen value is the only thing standing between a routine operation and a full disclosure. That gives us the single shared contract, short enough to fit on one line: the number must be unique and unpredictable, exactly once, per key.

This is the in-depth sequel to [Part 2](/blog/predictable-or-repeated-the-only-two-ways-cryptographic-rand), which surveyed the two ways cryptographic randomness betrays you -- predictability and repetition -- across many primitives at breadth. Part 2 owns the general taxonomy; this post goes deep on two specific victims, the ECDSA nonce and the GCM IV, and derives the exact algebra of each collapse. We will not re-teach the two-knobs framework here; we will spend it.

None of this was a secret to the designers. Bellare, Goldwasser, and Micciancio analyzed the danger of a poorly generated DSA nonce as early as their 1997 CRYPTO paper, "The DSS case" [@bgm], showing that a linear-congruential nonce generator breaks the scheme.Terminology drifts across modes, so fix it now: a nonce need only be unique (CTR, GCM); an IV for CBC must additionally be unpredictable; a salt is unique and public and feeds a KDF. The mode dictates which property is load-bearing. Part 2 and the block-cipher-modes installment work through the distinctions; here we only need "fresh, once, per key." The contract was understood from the beginning; nobody misunderstood the rule. They simply could not always keep it.

The contract says "never repeat." So begin with the crudest possible violation -- the same number, twice -- and watch precisely how much it costs.

3. Two Signatures, One k, and Your Private Key

This is the entire thesis compressed into one page of algebra -- no lattice, no side channel, no probability, just subtraction and one division. How little work does complete key recovery actually take?

Start from the fact that makes it possible. The first signature component, $r = (k \cdot G)_x \bmod n$, depends only on the nonce $k$ and the fixed public base point $G$. It does not depend on the message. So if you sign two different messages under the same $k$, both signatures carry the identical $r$. That repeated $r$ is the visible tell -- a fingerprint an attacker can spot by scanning a signature log, with no secret knowledge at all.This is exactly what fail0verflow read off the PlayStation 3: every firmware signature carried the same $r$, the public fingerprint of a constant $k$. You do not need to break anything to notice it; you just look for two signatures with a matching first half.

Now write the two signing equations under that shared $k$:

$$s_1 = k^{-1}(z_1 + r,d) \pmod n, \qquad s_2 = k^{-1}(z_2 + r,d) \pmod n$$

Subtract the second from the first. The private key appears only inside the identical $r,d$ term, so it cancels completely:

$$s_1 - s_2 = k^{-1}\big((z_1 + r,d) - (z_2 + r,d)\big) = k^{-1}(z_1 - z_2) \pmod n$$

Every quantity on the right except $k$ is public: the two message hashes $z_1, z_2$ and the two signature halves $s_1, s_2$. So solve for the nonce directly:

$$k = (z_1 - z_2),(s_1 - s_2)^{-1} \bmod n$$

One subtraction on top, one modular inverse on the bottom. With $k$ in hand, substitute back into the first equation -- multiply through by $k$, subtract $z_1$, and divide by the public $r$:

$$s_1 k = z_1 + r,d \implies d = (s_1 k - z_1),r^{-1} \bmod n$$

That is the private key. Count the cost to the attacker: two signatures, a handful of modular operations,Constant work here means a fixed number of field operations, independent of the key size. A 256-bit curve is no harder to break this way than a 160-bit one, because the attack never touches the key's length. and the recovery is certain -- not probable, not "on average," but exact, every time, the moment the repeat occurs. It solves a two-by-two linear system that the reuse handed over for free.

flowchart TD A["Two signatures made under the same nonce k"] --> B["They share the same r, because r depends only on k and G"] B --> C["Subtract the two s equations"] C --> D["The r times d term cancels, leaving k as the only unknown"] D --> E["One modular inverse recovers k"] E --> F["Put k back into either s equation"] F --> G["The private key d falls out, with certainty"]

You do not have to take the algebra on faith -- here is the whole attack as runnable code over a toy curve order, recovering the private key from public values alone:

{` // Recover the ECDSA private key d from two signatures sharing nonce k. function egcd(a, b) { if (b === 0n) return [a, 1n, 0n]; const [g, x, y] = egcd(b, a % b); return [g, y, x - (a / b) * y]; } function modInv(a, n) { a = ((a % n) + n) % n; const [g, x] = egcd(a, n); if (g !== 1n) throw new Error('no inverse'); return ((x % n) + n) % n; }

const n = 1103n; // toy prime "curve order" (real curves use ~256-bit n) const d = 937n; // the SECRET key the attacker must not know const k = 421n; // the reused nonce (identical for both signatures) const r = 668n; // r = (k*G).x mod n -- SHARED because k is shared const z1 = 123n, z2 = 456n; // two different message hashes

// Victim signs both messages with the SAME k: const s1 = (modInv(k, n) * (z1 + r * d)) % n; const s2 = (modInv(k, n) * (z2 + r * d)) % n;

// Attacker sees only public (r, s1, z1, s2, z2). Recover k, then d: const kRec = ((((z1 - z2) % n) + n) % n) * modInv((((s1 - s2) % n) + n) % n, n) % n; const dRec = ((((s1 * kRec - z1) % n) + n) % n) * modInv(r, n) % n;

console.log('shared r :', r.toString()); console.log('recovered k :', kRec.toString(), '(true k =', k.toString() + ')'); console.log('recovered d :', dRec.toString(), '(true d =', d.toString() + ')'); console.log(dRec === d ? 'PRIVATE KEY RECOVERED from two signatures.' : 'mismatch'); `}

Key idea: Two signatures sharing one nonce equal certain, instant, total key recovery -- by hand, with pure algebra. Reuse is not a slope that gradually weakens security; it is a cliff. "Reuse one number equals everything" is a literal statement about ECDSA, not a rhetorical flourish.

This is not a museum piece. The PlayStation 3 fell to exactly this -- a constant $k$ across every firmware signature, two images sharing one $r$, the master key recovered [@f0f]. Section 5 catalogs the rest of the real-world chain, from that constant-nonce break down to biases of less than a single bit.

Certainty from a literal repeat is the easy case -- easy for an attacker to run, and, as we will see, easy for a defender to eliminate. So attackers asked a sharper and far more dangerous question. What if the nonces are never equal, only slightly, invisibly skewed?

4. From Repeat to Bias: The Hidden Number Problem

You do not need the nonces to be equal. You only need them to be a little bit predictable -- and then to collect enough of them. This is where the story turns, because it dismantles the comforting fix you probably just thought of. If a literal repeat is the danger, surely "make sure the nonces are always different" closes it? It does not come close.

Here is the shift in viewpoint. In Section 3, a repeat gave us an exact equation and we solved it. Now suppose each nonce is merely skewed -- say the top few bits are always zero, or the generator leans slightly toward small values. No two nonces are equal, so the certainty attack never triggers. But each signature is now a noisy linear equation relating the public data to the secret key $d$ modulo $n$, with the unknown nonce constrained to a smaller range than it should occupy. One such equation tells you almost nothing.

Stack hundreds or thousands of them as the rows of a lattice, though, and the secret $d$ shows up as one unusually short vector hiding in that grid. A reduction algorithm hunts it down, and the key reads straight out.

The problem of recovering a hidden integer -- here, the private key -- from many samples that each reveal only a few most-significant bits of a related product modulo $n$. Dan Boneh and Ramarathnam Venkatesan introduced it in 1996, and it is the framework underneath every biased-nonce attack on (EC)DSA [@hnp]. An integer grid of points formed by adding and subtracting a fixed set of basis vectors. Biased-nonce recovery constructs a lattice whose unusually short vector encodes the secret key; a reduction algorithm finds that vector. We stay conceptual here -- the internals of LLL and the closest-vector problem belong to their own discussion.

The genealogy is worth knowing, because each step needed less leakage than the last. Boneh and Venkatesan framed the Hidden Number Problem in 1996 [@hnp]. Around 2000, Daniel Bleichenbacher showed that even a tiny statistical bias in DSA nonces is exploitable through a Fourier-analytic version of the same idea.Bleichenbacher's seminal biased-nonce result was never published as a standalone paper. It survives as a 2000 IEEE P1363 presentation and a 2005 CRYPTO rump-session talk, "Experiments with DSA," and is reconstructed through the reference lists of later work such as Nguyen-Shparlinski and LadderLeak. A standalone Bleichenbacher paper on this would be a fabrication; the history genuinely has this shape.

Nick Howgrave-Graham and Nigel Smart made the lattice attack practical in 2001, recovering keys from partially known nonces [@hgs]. Phong Nguyen and Igor Shparlinski then proved rigorous polynomial-time ECDSA key recovery from just a few leaked nonce bits per signature in 2003 [@ns]. Two decades on, LadderLeak pushed the frontier to its logical extreme, breaking ECDSA with less than one bit of nonce leakage per signature [@ladderleak].

Now the distinction that everything downstream depends on. The biased case is not the repeat case with weaker numbers. It is a different kind of attack with a different cost profile, and conflating them is the single most common way this topic gets mistold.

Note: A repeated nonce leaks the key from two signatures, with certainty (Section 3). A biased nonce leaks nothing usable from any single signature; it takes many signatures -- hundreds, thousands, or more -- aggregated by a lattice or Fourier reduction before the key emerges. "One biased signature reveals your key" is false. Keep the two cases apart or you will misquote the entire failure family.

Laid out side by side, the contrast is stark:

	Repeated nonce	Biased nonce
Leak per signature	The entire nonce (matches another)	A few bits, or a fraction of one
Signatures needed	Two	Many (hundreds to millions, per bias)
Method	Subtraction and one modular inverse	Lattice reduction or Fourier analysis (HNP)
Result	Certain and exact	Statistical, high-probability
Work	Schoolbook algebra by hand	Serious computation on aggregated data
Defeated only by	Distinct nonces	Removing the bias, not just repeats

flowchart TD A["Many signatures, each nonce slightly biased"] --> B["Each is a noisy linear equation in the secret d"] B --> C["Stack the equations as rows of a lattice"] C --> D["The secret d hides in one unusually short vector"] D --> E["Lattice reduction finds that short vector"] F["Read the private key d straight out of it"] E --> F

The lesson lands hard. If even a fraction of one bit of bias, harvested across enough signatures, surrenders the key, then "never literally repeat $k$" is nowhere near enough of a rule, and "use a better random number generator" is a treadmill, not a fix. The only question left is how bad this got in real, shipped hardware -- devices built by careful engineers who knew all of this.

5. The Catastrophes in the Wild: ECDSA

The theory is alarming; the field results are worse. What follows is the evolution told as a body count, and the number to watch is the leak the attacker needed. It shrinks with almost every entry, from an entire repeated nonce down to a fraction of a single bit, and every generation still won.

The 2010 PlayStation 3 break sits at one end: a constant nonce across all firmware signatures, the maximum possible leak, two signatures sufficient [@f0f]. In 2013 the Android SecureRandom defect produced repeated and predictable signing nonces on mobile devices; because Bitcoin wallets sign transactions with ECDSA, attackers drained the vulnerable ones [@bitcoin]. Google's own writeup traced the root cause to improper initialization of the underlying PRNG in the Java Cryptography Architecture [@securerandom].The often-repeated figure of roughly 55 BTC stolen in the 2013 Android incident comes from secondary news reporting [@hackernews]. The primary bitcoin.org advisory [@bitcoin] names the flaw and the affected wallet apps but states no loss total. Treat the number as reported, not official.

Then the leak starts shrinking. Minerva (2020) attacked real smart cards and cryptographic libraries that leaked the bit-length of the nonce through timing -- a whisper of bias, not a repeat -- and recovered keys from "just 500 signatures for simulated leakage data, 1200 for real cryptographic library data, and 2100 for smartcard data" [@minerva].

TPM-Fail (disclosed 2019, published at USENIX Security 2020) turned a timing side channel in Intel's firmware TPM (CVE-2019-11090) and an STMicroelectronics TPM (CVE-2019-16863) into nonce-bit leakage. It recovered an ECDSA key from the Intel fTPM in 4 to 20 minutes and, remotely, "the authentication key of a virtual private network (VPN) server in 5 hours" [@tpmfail] [@moghimi].

LadderLeak (2020) then broke ECDSA with less than one bit of nonce leakage per signature, exploiting a Montgomery-ladder side channel in OpenSSL [@ladderleak], a result published at ACM CCS 2020 [@ladderleak_doi]. And in 2024, PuTTY's use of P-521 exposed a structural bias so clean it needs almost no data at all (CVE-2024-31497) [@putty].

"The first 9 bits of each ECDSA nonce are zero. This allows for full secret key recovery in roughly 60 signatures." -- the PuTTY P-521 disclosure [@putty]

Sixty signatures. An attacker who had watched roughly sixty SSH handshakes, or collected sixty signed Git commits, could reconstruct the user's private key. The affected PuTTY versions ran from 0.68 through 0.80 (fixed in 0.81), and the same biased generator shipped in FileZilla, WinSCP, TortoiseGit, and TortoiseSVN [@putty]. Collect them into one table and the trend is impossible to miss:

Year	Target	Repeat or bias	Leak per signature	Signatures needed	Source
2010	Sony PS3 firmware	Repeat (constant k)	The entire nonce	2	[@f0f]
2013	Android Bitcoin wallets	Repeat / predictable k	Nonce reused or guessable	A few	[@bitcoin] [@securerandom]
2020	Minerva (cards, libraries)	Bias (nonce bit-length)	Timing reveals length	500 to 2100	[@minerva]
2019-2020	TPM-Fail (Intel, STMicro TPMs)	Bias (timing)	Nonce high bits via timing	Many	[@tpmfail] [@moghimi]
2020	LadderLeak (OpenSSL ladder)	Bias (sub-bit)	Less than one bit	Many	[@ladderleak]
2024	PuTTY P-521 (CVE-2024-31497)	Bias (structural)	First 9 bits fixed at zero	~60	[@putty]

flowchart LR A["1996 HNP framework: bias is exploitable in principle"] --> B["2010 PS3: a constant nonce, the whole value repeats"] B --> C["2013 Android: predictable and repeated nonces"] C --> D["2020 Minerva and TPM-Fail: a few biased bits via timing"] D --> E["2020 LadderLeak: less than one bit per signature"] E --> F["2024 PuTTY P-521: nine fixed bits, about 60 signatures"]

Note: Read the arc left to right and one lesson dominates: the leakage an attacker needs keeps shrinking, from an entire repeated nonce to less than a single bit. No generator is perfectly unbiased, and -- as Part 2 argued -- you can never prove one is. Any residual bias, given enough signatures, eventually surrenders the key. "Harden the random number generator" buys time; it does not close the hole. That conclusion is the synthesis of the whole table, and it is what forces the search for a structural answer.

Every entry above is a signature scheme bleeding out its private key through the nonce. You would be forgiven for thinking this is an ECDSA problem. It is not. The exact same structural flaw -- one number that must be used once and is fatal on reuse -- was hiding inside a completely different primitive, the cipher that protects most of the traffic on the modern web.

6. The Other Primitive: AES-GCM's Forbidden Attack

Different math, a different decade, a different threat model -- and the exact same fatal dependency on one number used once. The puzzle here is sharper: AES-GCM's nonce is public, so how can reusing a value the attacker already knows leak a forgery key? The answer is Antoine Joux's forbidden attack, and it mirrors the signature story beat for beat.

Recall the tag from Section 2: $T = E_K(J_0) \oplus \mathrm{GHASH}_H(A, C)$, where $H = E_K(0^{128})$. Two facts about that formula are load-bearing. First, $H$ depends only on the key, so it is fixed for the whole life of that key. Second, $E_K(J_0)$ depends only on the key and the nonce, through the pre-counter block $J_0$. Reuse the nonce and $E_K(J_0)$ comes back identical.

The secret 128-bit value $H = E_K(0^{128})$ -- AES applied to the all-zero block -- that keys GCM's polynomial authenticator over $\mathrm{GF}(2^{128})$. It never changes for a given key, and recovering it lets an attacker forge authentication tags at will.

Now reuse one $(\text{key}, \text{IV})$ pair on two messages. Two things break, and they break separately.

The confidentiality break, from a single collision. GCM encrypts with counter mode: the ciphertext is the plaintext XORed with a keystream generated from $J_0$. Same key, same IV means the same $J_0$, means the same keystream. So for two messages encrypted under the reused pair, $C \oplus C' = P \oplus P'$. The keystream cancels and the XOR of the two plaintexts falls out immediately, from just one collision, with no further work. If the attacker knows or guesses one plaintext, the other is fully revealed. Here is that leak as runnable code:

{` // Reuse one (key, IV) in a keystream mode -> C XOR C' leaks P XOR P'. // GCM encrypts with AES-CTR: same (key, IV) reproduces the SAME keystream. function xor(a, b) { return a.map((x, i) => x ^ b[i]); } const bytes = s => Array.from(new TextEncoder().encode(s)); const hex = a => a.map(x => x.toString(16).padStart(2, '0')).join('');

// A fixed keystream stands in for AES-CTR(key, IV): identical for both messages. const keystream = [0x9e,0x37,0x5a,0xc1,0x02,0xbb,0x44,0xd0,0x71,0x6f,0x88,0x2a];

const P1 = bytes('transfer=10 ').slice(0, keystream.length); const P2 = bytes('transfer=9999').slice(0, keystream.length);

const C1 = xor(P1, keystream); // ciphertext 1 const C2 = xor(P2, keystream); // ciphertext 2, SAME keystream

// Attacker never sees the key or keystream -- only C1 and C2: const leak = xor(C1, C2); // == P1 XOR P2, the keystream cancels console.log('C1 XOR C2 :', hex(leak)); console.log('P1 XOR P2 :', hex(xor(P1, P2)), '(identical -> keystream is gone)');

// If the attacker also knows P1, then P2 falls out immediately: console.log('recover P2:', new TextDecoder().decode(new Uint8Array(xor(leak, P1)))); `}

The authenticity break, from the tag difference. This is Joux's contribution. Write the two tags under the reused pair and XOR them. The identical blind $E_K(J_0)$ cancels exactly:

$$T \oplus T' = \mathrm{GHASH}_H(A, C) \oplus \mathrm{GHASH}_H(A', C')$$

Every block of $A, C, A', C'$ is observable on the wire, and $\mathrm{GHASH}_H$ is a polynomial in $H$ over $\mathrm{GF}(2^{128})$ with those blocks as coefficients. So the right-hand side is a known polynomial in the one unknown $H$, and it equals the observed left-hand side. Move everything to one side and you have a polynomial equation whose roots are candidate values for $H$; factoring it over $\mathrm{GF}(2^{128})$ yields that candidate set [@joux].

Recover $H$ and, since $E_K(J_0) = T \oplus \mathrm{GHASH}_H(A, C)$ falls out too, the attacker can compute a valid tag for any ciphertext they like under that nonce. That is a universal forgery.

Antoine Joux's 2006 attack on GCM: reusing a $(\text{key}, \text{IV})$ pair cancels the tag's $E_K(J_0)$ blind, turning the difference of two tags into a known polynomial over $\mathrm{GF}(2^{128})$ whose roots are candidates for the subkey $H$. The name reflects that GCM's unique-IV rule is not a suggestion -- breaking it is forbidden [@joux]. flowchart TD A["Tag T equals E_K(J0) XOR GHASH_H of the message"] --> B["J0 comes from the IV, H comes only from the key"] B --> C["Reuse the same key and IV on a second message"] C --> D["E_K(J0) is identical in both tags, so it cancels under XOR"] D --> E["T XOR T-prime is a known polynomial in H over GF(2 to the 128)"] E --> F["Its roots are the candidate values for the subkey H"] F --> G["Two or more collisions pin H, enabling universal forgery"]

Note: A single $(\text{key}, \text{IV})$ collision leaks $P_1 \oplus P_2$ immediately and unconditionally -- confidentiality is gone at once. Recovering the subkey $H$ is a separate step: one collision yields a set of candidate roots, and pinning $H$ uniquely generally needs two or more collisions. "One reuse instantly recovers the authentication key" overstates it. "One reuse instantly destroys confidentiality and opens the road to forgery" is exact.

This is not confined to whiteboards. In 2016 the Nonce-Disrespecting Adversaries team scanned live TLS and "identified 184 HTTPS servers repeating nonces, which fully breaks the authenticity of the connections" [@nda].Joux's result is his 2006 public comment to NIST, whose embedded document title reads "Authentication Failures in NIST version of GCM" [@joux]. It is sometimes miscited as IACR ePrint 2006/187 -- but that number is a different paper, on HMAC and NMAC, by Kim, Biryukov, Preneel, and Hong [@eprint187]. Cite the NIST comment, not the ePrint. These were production HTTPS endpoints, not lab toys, and their nonce reuse let anyone forge authenticated records against them.The canonical live-TLS evidence for GCM nonce reuse is that paper [@nda], not CVE-2016-0270, which concerns IBM Domino rather than OpenSSL. If you see that CVE cited as the OpenSSL GCM-reuse bug, it is a misattribution.

Two primitives, one disease: a once-per-operation number that is death on reuse. If the flaw is structural rather than a coding slip, then "be more careful with your randomness" cannot be the cure -- Section 5 already showed that treadmill has no end. The fix has to be architectural. What would that even look like?

7. Make the Number Deterministic

The cure for a randomness disaster turned out to be less randomness. That sentence should feel wrong -- we have spent five sections watching bad randomness destroy keys, so surely the answer is better randomness. It is not, and seeing why is the moment the whole subject clicks into place.

Go back to what actually failed. The signing equation needs a $k$ that is unique and unpredictable. Every real break came from the runtime source of that $k$: a constant, a repeated PRNG output, a biased generator, a timing leak. So Thomas Pornin's RFC 6979 asks a disarming question -- what if we never draw $k$ from a runtime source at all? Instead, derive it, deterministically, from two things the signer already holds: the private key and the message [@rfc6979].

A signature whose per-message nonce is computed as a pseudorandom function of the private key and the message, using no runtime randomness at all. The same $(\text{key}, \text{message})$ pair always yields the same nonce, and therefore the same signature. RFC 6979 specifies this for (EC)DSA; EdDSA builds it into the scheme [@rfc6979] [@rfc8032].

Concretely, RFC 6979 runs an HMAC-based deterministic random bit generator, seeded from the private key $x$ and the message hash, and rejection-samples its output into the valid range $[1, n-1]$. The two helper encodings simply turn the key and the hash into fixed-width byte strings so the HMAC has well-defined inputs:

h  = H(message)                              # hash the message
V  = 0x01 0x01 ... 0x01                       # hlen bytes of 0x01
K  = 0x00 0x00 ... 0x00                       # hlen bytes of 0x00
K  = HMAC(K, V || 0x00 || int2octets(x) || bits2octets(h))
V  = HMAC(K, V)
K  = HMAC(K, V || 0x01 || int2octets(x) || bits2octets(h))
V  = HMAC(K, V)
loop:
    T = ""                                     # accumulate qlen bits of output
    while bitlen(T) < qlen:                    # one HMAC block if qlen <= hlen; more if longer
        V = HMAC(K, V);  T = T || V
    k = bits2int(T)
    if 1 <= k <= n-1:  return k               # in range -> use it
    K = HMAC(K, V || 0x00);  V = HMAC(K, V)    # else reseed and retry

Look at what this buys. The generator is seeded by the private key and the message, and nothing else, and two consequences close the generation side of the Part-A attack surface.

The repeat case dies because two different messages produce two unrelated nonces, while the same message reproduces the same signature harmlessly -- there is no runtime generator whose collision could hand you a shared $k$. The bias case dies wherever the bias was born in a generator: with no runtime generator in the loop, there is nothing to skew and no entropy pool to under-initialize. Every Section-5 break that lived in the generator -- the repeated $k$ on the PS3, the predictable $k$ from a weak SecureRandom -- has simply been removed from the design, because there is no generator left to fail.

Deterministic signers "do not need access to a source of high-quality randomness." -- RFC 6979 [@rfc6979]

And the compatibility story is almost too good: a verifier cannot even tell. The verification equation is unchanged, because a signature is still just a valid $(r, s)$ pair; only the signer's method of choosing $k$ changed. Deployments can switch to deterministic signing unilaterally. You do not have to take the "same input, same output" claim on trust either:

{// Deterministic nonce k = PRF(private key, message). // Real RFC 6979 uses HMAC-DRBG; this toy uses a small deterministic mixer // only to show the SHAPE: same (key,msg) => same k; different msg => unrelated k. const MASK = (1n << 64n) - 1n; const n = (1n << 61n) - 1n; // toy prime modulus, k in [1, n-1] function rotl(x, r) { return ((x << r) | (x >> (64n - r))) & MASK; } function prf(key, msg) { // deterministic, consults no RNG let h = 1469598103934665603n; // 64-bit offset basis for (const ch of (key + '|' + msg)) { h = (h ^ BigInt(ch.charCodeAt(0))) & MASK; h = (h * 1099511628211n) & MASK; // FNV-style multiply h = rotl(h, 13n) ^ (h >> 7n); // extra diffusion so 1 char avalanches } return (h % (n - 1n)) + 1n; // map into [1, n-1] } const sk = 'private-key-0xA1B2'; console.log('k(pay Bob 10) :', prf(sk, 'pay Bob 10').toString()); console.log('k(pay Bob 10) :', prf(sk, 'pay Bob 10').toString(), '<- identical, no RNG consulted'); console.log('k(pay Bob 11) :', prf(sk, 'pay Bob 11').toString(), '<- unrelated'); console.log('No source of runtime randomness was consulted.');}

The same idea has a sibling that was born deterministic. EdDSA, and its popular instantiation Ed25519, does not bolt determinism on -- it designs the runtime randomness out from the start, computing its per-signature secret as a hash of a key-derived prefix and the message [@rfc8032].That is why Ed25519 has no separate "use RFC 6979" mode: there is no runtime nonce anywhere in the scheme to bias or repeat. Determinism is not an option you enable; it is the definition.

Standards bodies followed the evidence: FIPS 186-5, the current US signature standard, now approves deterministic ECDSA "as specified in IETF RFC 6979" [@fips1865] [@fips1865pdf]. There is even a quiet operational bonus. A deterministic signer is testable: you can ship known-answer test vectors and check byte-for-byte that an implementation is correct, which a randomized signer can never offer.

Key idea: The fix for a randomness failure was to remove the randomness. Derive the nonce from the private key and the message, and there is no runtime generator left to repeat or bias -- both failure modes vanish together.

Determinism looks like a clean, total victory. It is narrower than that, and the boundary matters. What it closes is the generation side of Part A. It does nothing for the usage side: recall that Minerva, TPM-Fail, and LadderLeak never touched a generator -- they read the nonce's leading bits out of the timing of the scalar multiplication $k \cdot G$, and that leak is present no matter how $k$ was chosen [@minerva] [@tpmfail] [@ladderleak]. Determinism fixes generation, not usage; the defense against that class is a constant-time scalar multiplication, a separate discipline that RFC 6979 neither provides nor promises. Worse, determinism can even add exposure: by making signing perfectly repeatable, we hand a fault-injection attacker a perfectly repeatable target, a hazard RFC 6979's own security considerations acknowledge [@rfc6979]. If Go's standard library knows this well enough to refuse pure determinism on purpose, we had better find out what it is afraid of.

8. The Catch, and the Hedge

Here is a fact that should stop you: Go's standard library signs ECDSA non-deterministically on purpose, and its source code says so in a comment. After seven sections arguing that runtime randomness is the enemy, one of the most widely used standard-library signers refuses to remove it. That is not carelessness. It is a second threat model.

Determinism closed the randomness door, but it opened a different one. A deterministic signer computes the same signature every time for a given input, which means an attacker who can run it twice on the same message gets two identical computations to compare -- and comparison is exactly the lever a fault attack pulls.

An attack that induces a hardware fault -- a voltage glitch, a clock glitch, a laser pulse -- during a computation, then compares the faulty output against a correct one to solve for the secret. Against a *deterministic* signer the attacker can obtain a correct signature and a faulted signature for the identical input, which is precisely what makes the difference exploitable.

This is not hypothetical. Aranha, Orlandi, Takahashi, and Zaverucha proved that de-randomized Fiat-Shamir schemes -- EdDSA among them -- are vulnerable to differential fault attacks [@hedged]. And the standard itself agrees: FIPS 186-5 warns that fault attacks are "of particular concern for ... deterministic signature schemes, as well as embedded or IoT devices and smartcards" [@fips1865pdf]. The very property that made determinism testable and repeatable -- same input, same output -- is what hands a fault attacker a fixed target to hammer.

The resolution is not to retreat to randomized signing, which reintroduces every repeat and bias failure. It is to take a small step back toward randomness, on purpose and in a controlled way: hedged signatures.

A signature whose nonce is derived from the private key, the message, *and* a fresh random value $r$: $k = H(sk, m, r)$. If the random source fails, the construction degrades to the deterministic -- still safe -- case. If a fault is injected, the fresh $r$ means the signer is no longer a fixed, replayable target.

Read that definition twice, because it is the whole trick. Hedging is not "randomized signing with extra steps." It is a design that is safe whichever thing goes wrong. Lose your entropy source entirely and you fall back to RFC 6979's determinism, which we already proved kills repeat and bias. Keep your entropy and you also get a moving target that defeats the fault attack determinism exposed. The randomness is present but no longer load-bearing.

"Signatures generated by this package are not deterministic, but entropy is mixed with the private key and the message, achieving the same level of security in case of randomness source failure." -- Go `crypto/ecdsa` [@goecdsa]

That is why Go hedges by default, and it is not alone. BoringSSL's FIPS module passes "a SHA512 hash of the private key and digest as additional data into the RBG ... a hardening measure against entropy failure" [@boringssl]. RFC 6979 itself sanctions hedged variants in its Section 3.6 [@rfc6979], and FIPS 186-5 specifies an "Extra Random Bits" method that draws a nonce at least 64 bits longer than needed so any statistical bias becomes negligible [@fips1865pdf].

The honest caveats: hedging still consumes some entropy, and its security proofs cover specific fault classes rather than all conceivable faults. It is a well-chosen trade, not a free lunch.

The right mental model is three parallel choices selected by threat model, not a podium with one winner:

Property	Randomized	Deterministic (RFC 6979 / EdDSA)	Hedged
RNG needed at signing time	Full	None	Some (not load-bearing)
Immune to repeats	No (RNG can collide)	Yes	Yes
Immune to bias	No	Yes	Yes
Resists fault injection	Yes (moving target)	No (fixed target)	Yes
Known-answer test vectors	No	Yes	No
Standardized	Yes	Yes (RFC 6979, FIPS 186-5)	Yes (RFC 6979 3.6; FIPS 186-5)
Shipped by default in	Legacy code	Many libraries	Go `crypto/ecdsa`, BoringSSL FIPS
Best when	Rarely the right pick	No fault threat in scope	Hardware, embedded, smartcard, HSM

Note: For any new (EC)DSA signer -- especially on hardware, embedded, smartcard, or HSM targets where fault injection is realistic -- hedge it: derive the nonce from the key, the message, and a little fresh entropy. You keep repeat and bias immunity even if the random source fails, and you deny the fixed target a fault attack needs.

So the signature side does not settle on a single champion. It settles on a matched set of choices, each correct for a different adversary. That is a satisfying place to land -- but it is only half the patient. What is the symmetric-encryption analogue for the cipher we left bleeding in Section 6?

9. Fixing the Cipher: Nonce-Misuse-Resistant AEAD

The signature fix was "derive the number." The cipher's fix rhymes: derive the IV from the message itself, so that the worst a repeat can leak is the fact that two messages were byte-for-byte identical. Same instinct, symmetric setting.

The idea predates AES-GCM-SIV. Phillip Rogaway and Thomas Shrimpton gave it a provable-security treatment in 2006, defining deterministic authenticated encryption and the Synthetic IV construction that realizes it [@rs_eprint] [@rs_doi]. It was standardized as AES-SIV in RFC 5297 [@rfc5297].

An initialization vector computed *from the message* -- together with the key and associated data -- rather than drawn at random. Because the IV is a function of the plaintext, two different plaintexts get different IVs automatically, and only byte-identical messages ever collide. An authenticated cipher that, if a nonce is ever repeated, leaks at most whether two identical $(\text{key}, \text{nonce}, \text{plaintext}, \text{associated data})$ inputs were the same -- never the key, never arbitrary plaintext. Reuse degrades it gracefully rather than catastrophically.

The modern instantiation is AES-GCM-SIV (RFC 8452) [@rfc8452]. It computes a keyed hash of the entire plaintext and associated data using POLYVAL, and folds that into a synthetic IV that doubles as the authentication tag; the synthetic IV then seeds ordinary AES-CTR encryption.POLYVAL is a little-endian relative of GHASH, chosen deliberately so AES-GCM-SIV can reuse the same carry-less multiplication hardware that already accelerates AES-GCM. The parallel to GCM is by design, not coincidence.

Two more refinements matter: fresh message-authentication and message-encryption keys are derived per nonce from the master key, which also pushes back the birthday bound that limits plain GCM and raises the safe message limit to roughly $2^{50}$ per key [@gcmsiv_spec]. The price is structural and unavoidable: because the tag depends on the whole plaintext, you cannot emit the first ciphertext byte until you have read the last plaintext byte. AES-GCM-SIV is inherently two-pass and not online.

flowchart TD A["Master key and nonce"] --> B["Derive per-message auth and encryption keys"] P["Plaintext and associated data"] --> C["POLYVAL hash under the derived auth key"] B --> C C --> D["Synthetic IV, which doubles as the authentication tag"] D --> E["Seed AES-CTR encryption with the synthetic IV"] B --> E E --> F["Output ciphertext and tag"]

Now state precisely what "misuse-resistant" earns you, because the phrase invites overclaiming. On a nonce repeat, AES-GCM-SIV discloses only whether the two messages "were equal or not," which RFC 8452 identifies as "the minimum amount of information that a deterministic algorithm can leak" [@rfc8452]. Compare that to Section 6, where a single GCM repeat surrendered $P_1 \oplus P_2$ and set up universal forgery. The SIV construction converts a catastrophe into a whisper.

On nonce reuse, a misuse-resistant AEAD discloses only "whether the messages were equal or not ... the minimum amount of information that a deterministic algorithm can leak." -- RFC 8452 [@rfc8452]

Note: "Misuse-resistant" does not mean reuse is harmless. On a repeat, AES-GCM-SIV still leaks that two identical messages were sent under the same nonce -- the provable minimum, but not nothing. You get graceful degradation, not immunity. It is a safety net, not a license to reuse nonces deliberately.

There is a parallel path worth knowing, though it solves a slightly different problem. XChaCha20-Poly1305 extends the nonce to 192 bits, which makes random nonce selection collision-safe and lets systems stay stateless without a counter [@xchacha]. That is genuinely useful, but it is not true misuse resistance: an exact nonce repeat still breaks Poly1305 the way any keystream reuse does. A big nonce makes accidental collisions astronomically unlikely; it does not make a deliberate repeat safe. Collect the options:

Scheme	Passes / online	On nonce reuse	Misuse-resistant?	Nonce size	Notes
AES-GCM	1 pass, online	Catastrophic (Section 6)	No	96-bit	Fastest with a reliable unique counter
AES-GCM-SIV	2 pass, not online	Leaks only message equality	Yes	96-bit	POLYVAL and per-nonce keys [@rfc8452]
AES-SIV	2 pass, not online	Leaks only message equality	Yes	Vector input	Deterministic key-wrap [@rfc5297]
XChaCha20-Poly1305	1 pass, online	Random reuse unlikely; exact reuse breaks	No	192-bit	Stateless random nonces [@xchacha]

Two families, one move. On the signature side we stopped trusting runtime randomness by deriving the number; on the AEAD side we stop trusting it by making a repeat non-catastrophic. It feels, at last, like the problem is solved. It is not -- and the reasons are not missing features anyone can build. Some of them are walls that no amount of engineering can move.

10. Theoretical Limits and the Open Frontier

Some of the walls we keep hitting are not missing features that a cleverer engineer will one day supply. They are proofs that you cannot have everything at once.

First: an online cipher cannot be misuse-resistant. To leak only equality on a repeat, the first bit of ciphertext must depend on the *entire* plaintext, which forces a second pass -- so "streaming" and "misuse-resistant" cannot both hold [@rfc8452]. Second: pure determinism cannot resist faults. The very repeatability that kills nonce reuse is the property a fault attack exploits, so resisting faults means reintroducing some randomness to hedge [@hedged]. Neither wall is a missing feature. Both are theorems. There is no single perfect primitive -- only a matched pair chosen per threat model.

Those two impossibilities explain the shape of everything in Sections 7 through 9. AES-GCM-SIV is two-pass because it has to be. Hedged signatures exist because determinism alone cannot cover the fault case. We did not fail to find the one perfect design; the one perfect design is provably not there.

A third limit is epistemic, and it is the quiet engine under this entire article.

Note: You can never prove a generator is unpredictable; you can only fail to prove it predictable. That asymmetry -- argued in Part 2 -- is why "harden the random number generator" was never a structural fix. LadderLeak made the point unforgettable by winning with less than one bit of bias [@ladderleak]. Deriving the number sidesteps the unprovable question entirely: there is nothing left to certify.

And the biased-nonce frontier is still descending: LadderLeak's sub-one-bit result is the current floor, not a proven bottom [@ladderleak]. The theoretical minimum bias that remains exploitable is an open question, and history says to bet on "smaller than you think."

Then there is the genuinely open ground, where the same disease is re-emerging one abstraction level up. In threshold and multi-party ECDSA, several parties must jointly produce a nonce that is unbiased and secret from all of them, even when some participants misbehave. That is the Hidden Number Problem wearing a new coat: get the joint nonce generation subtly wrong and the biased-nonce attacks come straight back [@threshold]. On the AEAD side, none of the four ciphers we surveyed is key-committing, and that gap is exploitable.

An authenticated cipher whose ciphertext binds to exactly one key, so it cannot be decrypted to a different valid plaintext under a different key. None of AES-GCM, AES-GCM-SIV, AES-SIV, or XChaCha20-Poly1305 is key-committing, which is precisely what enables partitioning-oracle attacks.

Julia Len, Paul Grubbs, and Thomas Ristenpart showed that this non-committing property turns certain systems into partitioning oracles that recover passwords and keys [@len]. There is no drop-in standard for committing AEAD yet -- an active research front. It is worth being precise about what is not open, though: AES-GCM-SIV and AES-SIV already sit exactly at the minimum-leakage lower bound for the misuse case, because "leaks only equality" is provably optimal for any deterministic scheme [@rfc8452]. That specific gap is closed; you cannot do better, and you do not need to.

Step back and the emotional arc completes. We began thinking nonce reuse was sloppy hygiene, discovered it was a cliff, thought determinism sealed the cliff, learned determinism opened a fault door, and now find that some of the remaining doors are welded shut by theorems while others open onto genuinely unexplored rooms. None of that theory, however, changes what an engineer should actually do on Monday morning. After all of it, what do you type?

11. What a Practitioner Does Today

Everything above collapses into a decision tree that fits on an index card. You do not need to re-derive Joux's polynomial in a code review; you need two questions for signing and two for encryption.

For signing: for any (EC)DSA or DSA signer, derive the nonce with RFC 6979 or a hedged variant rather than drawing it at runtime [@rfc6979]. For greenfield systems, prefer Ed25519, which is deterministic by construction [@rfc8032]. If fault injection is a realistic threat -- smart cards, HSMs, IoT silicon an attacker can hold -- hedge, so an entropy failure degrades to safe determinism and a glitch still faces a moving target [@hedged] [@boringssl] [@goecdsa]. And never compute a nonce as rand() mod n from a raw PRNG without the anti-bias margin FIPS 186-5 specifies as Extra Random Bits [@fips1865pdf]. On hardware whose timing an attacker can measure -- smart cards, TPMs, co-located VMs -- pair all of this with a constant-time scalar multiplication: RFC 6979 fixes how $k$ is generated, not how it is used, so the Minerva, TPM-Fail, and LadderLeak timing leaks close only when $k \cdot G$ itself runs in constant time [@minerva] [@tpmfail] [@ladderleak].

For AEAD: if you can guarantee a unique nonce -- a reliable, non-resetting counter -- AES-GCM is the fastest choice, provided you cap invocations per key against the birthday bound and rekey before you approach it [@sp80038d] [@rfc8452]. If nonce uniqueness is even slightly uncertain -- multiple writers sharing a key, VM snapshots that replay state, forked or stateless workers -- reach for AES-GCM-SIV [@rfc8452] or the 192-bit-nonce XChaCha20-Poly1305 [@xchacha]. For deterministic key-wrapping, AES-SIV is purpose-built [@rfc5297].

flowchart TD S["Signing (EC)DSA or DSA"] --> Q1{"Fault injection in scope, such as smartcard or HSM or IoT"} Q1 -->|Yes| H["Hedge: nonce from key, message, and fresh entropy"] Q1 -->|No| G{"Greenfield design"} G -->|Yes| ED["Prefer Ed25519"] G -->|No| R6["Deterministic RFC 6979"] A["Choosing an AEAD"] --> Q2{"Reliable unique nonce counter"} Q2 -->|Yes| GCM["AES-GCM, cap invocations and rekey"] Q2 -->|No| MR["AES-GCM-SIV or XChaCha20-Poly1305"]

The same choices read cleanly as a do-and-do-not table:

Situation	Call this	Never this
Signing, general	RFC 6979 deterministic or hedged	`rand() mod n` from a raw PRNG
Signing, greenfield	Ed25519	Home-rolled DSA nonce logic
Signing, hardware or embedded	Hedged (key, message, entropy)	Pure determinism on a fault-exposed device
Signing, measurable hardware	Constant-time scalar multiplication	Variable-time scalar multiplication an attacker can time
AEAD, reliable counter	AES-GCM, capped per key and rekeyed	AES-GCM past its invocation limit
AEAD, uncertain uniqueness	AES-GCM-SIV or XChaCha20-Poly1305	Plain AES-GCM with hopeful nonces
Deterministic key-wrap	AES-SIV (RFC 5297)	A data-plane GCM key reused for wrapping

These abstractions land on concrete Windows components. Signature and nonce generation run through the Cryptography API: Next Generation stack, whose internals the [CNG architecture article](/blog/cng-architecture-bcrypt-ncrypt-ksps) works through. TLS record nonces are the responsibility of [SChannel](/blog/rotating-every-cipher-schannel-and-the-twenty-year-algorithm), the platform's TLS implementation. And every one of those values ultimately draws on the [Windows RNG](/blog/a-key-is-only-as-unguessable-as-the-dice-that-made-it-inside), whose seeding and clone-defense decide whether the "unique and unpredictable, once, per key" contract actually holds in practice. Read those three together and this article's rules become a specific call stack.

Note: Signing: derive the nonce (RFC 6979), prefer Ed25519, hedge on hardware. AEAD: use AES-GCM only with a guaranteed-unique counter and an invocation cap; otherwise reach for AES-GCM-SIV or a 192-bit-nonce cipher. One instinct sits under both: never trust a runtime draw to be unique and unpredictable "just once."

Sign the same message twice, with the same key, and compare the two signatures. If they are byte-for-byte identical, the signer is deterministic (RFC 6979 or Ed25519). If they differ, it is randomized or hedged. Ed25519 in most libraries will match exactly; Go's `crypto/ecdsa` will not, by design. That one comparison tells you which row of the Section 8 table you are standing in -- and whether an entropy failure at runtime would be survivable.

Two rules for two primitives, resting on a single instinct. That instinct is strong enough to design around -- but a handful of persistent myths still surface in code review and threat models, and each one hides a real misunderstanding of the mechanism. Let us dismantle them one at a time.

12. Frequently Asked Questions

No, and this distinction matters more than almost anything else here. A *repeated* nonce leaks the key from *two* signatures with certainty, through the subtraction in Section 3. A *biased* nonce is statistical: each signature is one noisy equation, and recovery needs *many* of them aggregated by a lattice or Fourier reduction [@ns] [@ladderleak]. One biased signature on its own leaks nothing you can use. "One biased signature reveals your key" is the single most common misstatement in this area. Not against every adversary. Determinism removes the repeat and generation-side bias failures completely (it does not stop a side-channel leak of $k$ during the scalar multiplication $k \cdot G$, which needs a *constant-time* implementation, not determinism), but it turns the signer into a fixed, replayable target for differential fault analysis -- proven for de-randomized Fiat-Shamir schemes including EdDSA [@hedged], and flagged by FIPS 186-5 as a special concern for deterministic schemes on embedded and smartcard devices [@fips1865pdf]. That is exactly why hedged signatures exist. No. It degrades gracefully instead of catastrophically. On a repeat it discloses only whether two messages were identical -- the provable minimum for any deterministic scheme -- never the key and never arbitrary plaintext [@rfc8452]. "Graceful" is not "free." Do not reuse nonces on purpose in the belief that the SIV mode makes it costless. No, and precision matters. A single collision instantly leaks $P_1 \oplus P_2$ and destroys confidentiality [@joux]. Recovering the authentication subkey $H$ is a *separate* step: one collision yields a set of candidate roots, and pinning $H$ uniquely generally needs two or more collisions [@joux]. Live TLS servers doing this were found forgeable in 2016 [@nda], but the mechanism is "confidentiality gone at once, forgery after enough collisions," not "one reuse equals the key." Because you cannot certify unpredictability, only fail to falsify it -- and sub-bit bias is still fatal across enough signatures. LadderLeak won with less than one bit of leakage [@ladderleak]. Hardening the generator raises the bar; it does not change the structure. Deriving the number does. Only within the birthday bound, and only if uniqueness genuinely holds. Random 96-bit nonces start colliding near $2^{48}$ messages, which is why usage caps per key exist [@rfc8452]. Worse, multi-writer keys, VM clones, and process forks silently re-emit the same nonce no matter how carefully you generated it. If uniqueness is uncertain, switch to AES-GCM-SIV [@rfc8452] or XChaCha20-Poly1305's 192-bit nonce [@xchacha]; this reuse has been observed in the wild [@nda]. No. Lattice- and Fiat-Shamir-based post-quantum signatures inherit the same sensitivity to per-signature randomness; several are precisely the de-randomized Fiat-Shamir schemes shown vulnerable to fault attacks [@hedged]. Migrating to post-quantum cryptography re-instantiates nonce discipline -- it does not retire it.

13. One Cure for Two Catastrophes

Return to that stage in Berlin in 2010, but now you can see the whole shape of the thing. The PlayStation 3 master key did not fall to a broken cipher or a weak curve; it fell to one number, used twice, and two signatures' worth of subtraction [@f0f]. The same shape swept real Bitcoin wallets when Android's generator repeated nonces [@bitcoin].

Then the required leak kept shrinking -- bit-length timing on smart cards [@minerva], side channels in TPMs [@tpmfail], less than a single bit in LadderLeak [@ladderleak], nine fixed bits and sixty signatures in PuTTY [@putty] -- and the very same disease surfaced in a cipher, where 184 live TLS servers reusing a GCM nonce were shown forgeable [@nda].

Every one of those failures shares a single sentence. Both primitives bet everything on a number that had to be unique and unpredictable exactly once, and both collapsed the moment that bet was lost. And the cures share a single sentence too. Deterministic signing derives the number from the key and the message so there is nothing left to repeat or bias [@rfc6979], while a constant-time scalar multiplication closes the side-channel leaks that determinism never touched; hedged signing keeps a sliver of entropy so a fault has no fixed target [@hedged]; misuse-resistant encryption derives the IV from the message so a repeat leaks only that two messages matched [@rfc8452].

Key idea: Two primitives, one disease, one cure: stop trusting runtime randomness for the once-per-operation number. Derive it, or make a repeat non-catastrophic. Everything else in this article is a footnote to that sentence.

Part 2 of this series taught the two ways randomness betrays you; this was the promised descent into what those betrayals actually cost and how the field designed them away. The punchline you were promised at the start has been earned line by line: in cryptography, reusing one number can cost you everything -- so build systems that never require you to trust yourself to use it only once.

The Ciphertext Was Unbreakable. The Attacker Rewrote It Anyway: A Field Guide to Block Cipher Modes

noreply@paragmali.com (Parag Mali) — Wed, 08 Jul 2026 21:51:08 GMT

A block cipher only enciphers one fixed-size block. A "mode of operation" is the wrapper that turns it into a scheme for real messages -- and every mode answers only one of two questions: can the attacker *read* it (confidentiality), or can the attacker *change* it (integrity)? The five SP 800-38A modes -- ECB, CBC, CFB, OFB, CTR -- are all malleable, so an attacker who cannot decrypt your ciphertext can still predictably edit the plaintext, and ECB additionally leaks structure outright (the penguin, Adobe's 153 million passwords). This field guide hands you one lens -- *which question did this mode answer, and was its IV/nonce contract honored?* -- and uses it to walk each mode's exact contract, a named failure catalog (Vaudenay, BEAST, Lucky Thirteen, POODLE, Sweet32, Efail, GCM nonce reuse), and the fix: authenticated encryption, whose dominant AES instances (GCM equals CTR plus GHASH, CCM equals CTR plus CBC-MAC) are literally these modes plus a MAC. It closes with the 2024-2026 state of the art (IR 8459, the ECB sunset, Ascon, nonce-misuse-resistant AES-GCM-SIV) and a decision guide for using these primitives correctly.

1. Two Lines of Code

A bank encrypts the message "transfer $9" with AES and a 256-bit key and sends the ciphertext across a network an attacker completely controls. He cannot read a single byte of it. AES is unbroken and will stay unbroken. Yet by flipping a few bits he cannot even decrypt, he turns the message into "transfer $9,000,000," and the receiver accepts the change as authentic. The encryption was never broken. It simply answered the wrong question.

How can a ciphertext be unreadable and freely editable at once? The trick is not a flaw in AES but a property of the mode -- the wrapper that stretches a one-block cipher across a longer message. Many modes turn the cipher into a keystream generator and combine it with the plaintext by XOR, so $C = P \oplus \text{keystream}$. Rearrange the algebra: $P = C \oplus \text{keystream}$. An attacker who XORs a chosen delta into the ciphertext XORs exactly that delta into the recovered plaintext. He needs no key, reads nothing, and the receiver decrypts a perfectly well-formed forgery. That is one half of the story: the integrity question was never answered.

The other half is uglier, because it fails the first question too. In 2013, attackers exposed roughly 153 million Adobe account records. The passwords were not hashed. They were encrypted, with 3DES in ECB mode and no salt [@troyhunt-adobe-2013]. ECB enciphers each block independently, so identical passwords produced identical ciphertext. Combined with the unencrypted password hints Adobe stored beside them, enormous numbers of passwords were reconstructed without anyone ever breaking 3DES [@troyhunt-adobe-2013]. The cipher was fine. The mode leaked the plaintext.

Two stories, one shape. In each, the cipher did exactly what it promised and the attacker still won. That is because a mode of operation answers up to two independent questions, and the five most famous modes answer only one:

Can the attacker read it? That is confidentiality.
Can the attacker change it? That is integrity.

The five modes standardized for decades -- ECB, CBC, CFB, OFB, CTR -- answer only the first question. ECB answers even that one wrongly. Every named break in this field, past or future, reduces to one diagnostic sentence: which of the two questions did this mode answer, and was its IV/nonce contract honored? Hold that sentence in your head and the whole subject becomes legible.

flowchart TD Mode["A block cipher mode of operation"] Mode --> C["Question 1: can the attacker READ it? (confidentiality)"] Mode --> I["Question 2: can the attacker CHANGE it? (integrity)"] C --> Cans["Answered only if the IV or nonce contract is honored"] I --> Ians["Never answered by the five SP 800-38A modes"] Cans --> BreakA["Break type A: violated IV/nonce contract (BEAST, GCM nonce reuse)"] Ians --> BreakB["Break type B: missing integrity answer (Efail, bit-flipping, truncation)"]

This is Part 5 of a field guide for protocol designers. It leans on two earlier parts without re-deriving them: Part 1 gave us the security definitions this article keeps invoking -- IND-CPA, IND-CCA2, INT-CTXT -- and Part 2 gave us the discipline of generating initialization vectors and nonces. Here we spend those definitions on a single primitive: the block cipher mode.

If AES was never broken in either story, what actually failed? To answer, you first have to know what a block cipher can and cannot do on its own, and why a mode was mandatory from the very first day it shipped.

2. A Cipher That Only Speaks in Blocks

A block cipher is smaller than you think. DES (1977) enciphers exactly 64 bits at a time. AES (2001) enciphers exactly 128. Feed it more and it simply refuses. It is a keyed permutation on one fixed-size block and physically cannot accept a message longer than that.

A keyed, invertible permutation on one fixed-size block of bits, written $E_k : \{0,1\}^n \to \{0,1\}^n$ for a key $k$ and block size $n$ (64 bits for DES, 128 for AES). It maps one $n$-bit input to one $n$-bit output and back. It has no notion of a message, a length, or a stream.

Because real messages are almost never exactly one block long, every use of a block cipher needs a wrapper: a rule for chopping the message into blocks, deciding what each block's input should be, and stitching the outputs back together. That wrapper is the mode of operation.

The algorithm that lifts a one-block cipher to messages of arbitrary length. It specifies how plaintext is partitioned, what feeds into each block cipher call, and how the results combine into a ciphertext. The mode -- not the cipher -- decides whether identical plaintext leaks, whether the scheme is parallel, and what the initialization-vector or nonce rule is.

The primitive came first. Horst Feistel's work at IBM in the early 1970s produced the Feistel network that became DES, a 64-bit keyed permutation blessed as a federal standard in 1977 [@feistel-1973][@fips-46-3]. The 64-bit block chosen here is the exact quantity that dies, 39 years later, to the Sweet32 attack.

The first wrapper followed almost immediately. In 1976, William Ehrsam, Carl Meyer, John Smith, and Walter Tuchman at IBM filed the patent on Cipher Block Chaining -- the idea of feeding each plaintext block the previous ciphertext block before encryption, so that identical plaintext blocks stop producing identical ciphertext (US Patent 4,074,066, granted 1978) [@cbc-patent-4074066].The patent's actual title is "Message verification and transmission error detection by block chaining" [@cbc-patent-4074066]. That is historically ironic: CBC as a confidentiality mode provides no message verification -- no integrity -- at all, which is the very gap this article is about.

Counter mode arrived on paper three years later. Whitfield Diffie and Martin Hellman described encrypting a counter to make a keystream in their 1979 survey "Privacy and Authentication," turning a block cipher into a parallelizable stream cipher [@diffie-hellman-1979][@rogaway-modes-2011].Counter mode was described "just as early as the basic-four modes," in Rogaway's words, "yet for some reason it was not included in the initial batch" [@rogaway-modes-2011]. It waited 22 years for a federal standard. The exact page in Proc. IEEE 67(3) is gated behind IEEE Xplore, so the DOI is the stable handle and Rogaway's 2011 survey carries the attribution [@diffie-hellman-1979][@rogaway-modes-2011].

Then the standard fixed the toolkit. In December 1980 the National Bureau of Standards published FIPS 81, DES Modes of Operation, sanctioning four ways to stretch DES across real traffic: ECB, CBC, CFB, and OFB [@fips-81]. Counter mode was left out. It did not enter a NIST standard until Morris Dworkin's SP 800-38A re-specified all five modes for the AES era in December 2001, finally adding CTR as the fifth -- 22 years after Diffie and Hellman [@nist-sp-800-38a].

flowchart LR A["1976: CBC invented at IBM"] --> B["1979: Counter mode, Diffie-Hellman"] B --> C["1980: FIPS 81 standardizes ECB, CBC, CFB, OFB"] C --> D["1997: BDJR concrete-security proofs"] D --> E["2000-2001: Encrypt-then-MAC proven, SP 800-38A adds CTR"] E --> F["2004-2007: GCM and CCM, CTR plus a MAC"] F --> G["2011-2018: BEAST, Lucky Thirteen, POODLE, Sweet32, Efail"] G --> H["2024-2025: NIST IR 8459, Ascon"]

Here is the load-bearing historical fact. Every one of these five modes is a confidentiality construction. Integrity -- the second question, "can the attacker change it?" -- was filed under a separate heading called a message authentication code, and in practice it was usually forgotten. FIPS 81 and SP 800-38A specify no integrity mechanism for any of the five [@fips-81][@nist-sp-800-38a]. That separation of concerns, confidentiality here and integrity somewhere else, is the original sin the rest of this story pays for.

So the toolkit was frozen by 1980 (four modes) and completed by 2001 (a fifth), every one a way to hide data and none a way to protect it from change. The most obvious of the four is also the most broken, and seeing exactly why is the fastest route into the whole subject.

3. ECB, and Why "Just Encrypt Each Block" Fails

The most obvious wrapper is to apply the one-block permutation to each block on its own: $C_i = E_k(P_i)$. This is Electronic Codebook mode, and it is the design every beginner reinvents in an afternoon. It is also broken in a way you can see with your eyes.

The flaw is that ECB is deterministic. It has no initialization vector, no chaining, and no state, so the same plaintext block always encrypts to the same ciphertext block: $P_i = P_j \Rightarrow C_i = C_j$. The plaintext's block-level structure survives encryption intact. Rogaway's survey states it flatly: ECB "leak[s] equality of blocks across both block positions and time" and "does not achieve any generally desirable security goal in its own right" [@rogaway-modes-2011].

flowchart TD P1["Block A: LOVE"] --> C1["Ciphertext 7a3f"] P2["Block B: HATE"] --> C2["Ciphertext 9b2e"] P3["Block C: LOVE"] --> C3["Ciphertext 7a3f"] C1 -.->|"equal blocks leak"| C3

That leak is not a metaphor.The famous "ECB penguin" -- an image of Tux encrypted block-by-block whose outline stays perfectly visible -- is community folklore (the Tux image is by Larry Ewing, 1996) with no research primary. The load-bearing evidence for ECB's failure is the Adobe 2013 breach and the BDJR theorem, not the meme. In 2013, roughly 153 million Adobe records showed it at scale: passwords encrypted with 3DES in ECB, no salt, so identical passwords produced identical ciphertext and the plaintext structure reconstructed itself without 3DES ever being broken [@troyhunt-adobe-2013].

Underneath the meme is a theorem. ECB is not IND-CPA.

The baseline security goal for encryption. An adversary who may request encryptions of any plaintexts it chooses still cannot tell which of two equal-length messages a challenge ciphertext hides. Bellare, Desai, Jokipii, and Rogaway (1997) proved the consequence: any IND-CPA scheme must be randomized or stateful, so a deterministic mode like ECB cannot qualify [@bdjr-1997][@katz-lindell-2020].

The proof is a one-line adversary. Ask the challenger to encrypt a pair of equal blocks $(X, X)$ versus an unequal pair $(X, Y)$ and simply look for a repeated ciphertext block; ECB gives itself away every time [@bdjr-1997]. This is the same reasoning Part 1 develops in general. ECB is also malleable at block granularity: because blocks are independent, an attacker can cut, paste, and reorder them undetected. It fails both questions at once.

Note: ECB is deterministic, so identical plaintext blocks become identical ciphertext blocks and structured or repeated data leaks through untouched -- the ECB penguin, and Adobe's roughly 153 million exposed passwords [@troyhunt-adobe-2013]. Reach for ECB only as a raw one-block building block, never to encrypt a message.

That "never" needs one careful qualifier -- it is easy to overstate.

The rule is *never ECB for messages* -- multi-block, structured, or low-entropy plaintext. The raw single-block permutation is still a legitimate building block: it is the block operation every other mode calls, and it sits at the core of NIST AES Key Wrap and of CMAC/CBC-MAC. NIST's SP 800-131A Revision 3, the initial public draft published on October 21, 2024, formalizes this by moving ECB to "legacy use" and disallowing it for encrypting secret data, with legacy (decrypt-only) use retained -- a demotion, not a claim that ECB has no valid use anywhere [@nist-sp-800-131a-r3].

You can watch the determinism happen. The toy below is not a real cipher, but like ECB it transforms each block with the same deterministic function, so a repeated plaintext block produces a repeated ciphertext block:

{` // A toy deterministic block transform. Not a real cipher -- the point is // only that the same input block always yields the same output block. function toyBlockCipher(block) { return block.split('').reverse().map(function (c) { return String.fromCharCode((c.charCodeAt(0) + 7) % 128); }).join(''); }

// ECB: split into 4-char blocks and transform each one independently. function ecb(message) { var out = []; for (var i = 0; i < message.length; i += 4) { out.push(toyBlockCipher(message.slice(i, i + 4))); } return out; }

var blocks = ecb('LOVEHATELOVE'); // block 1 and block 3 are identical console.log(blocks); console.log('Block 1 equals block 3? ' + (blocks[0] === blocks[2])); // True. The repeated plaintext block leaks as a repeated ciphertext block, // with no key required to notice the pattern. `}

One clarification before moving on.These five are the SP 800-38A confidentiality-only modes, not "all block cipher modes." Disk encryption (XTS-AES, SP 800-38E), authentication (CMAC, SP 800-38B), and authenticated encryption (GCM in SP 800-38D, CCM in SP 800-38C) live in separate NIST publications because they pursue different goals. ECB is the degenerate member of the family, and its failure points straight at the fix.

BDJR's theorem is also the cure. To be IND-CPA, encryption must be randomized or stateful. So add an initialization vector, and make each block's encryption depend on the previous one, so that identical plaintext diverges. That is Cipher Block Chaining -- and the start of a forty-year evolution that improves everything except the one thing that matters.

4. From CBC to CTR, Generation by Generation

Four modes remain, and they line up as a sequence of fixes -- each one repairing the previous mode's limitation, and none of them repairing the missing integrity answer. The field got faster, more flexible, and better specified. It stayed exactly as forgeable as the day it started.

CBC: chain the blocks

CBC seeds the chain with an initialization vector and feeds each plaintext block the previous ciphertext block before encryption: $C_i = E_k(P_i \oplus C_{i-1})$, with $C_0 = \text{IV}$. Decryption runs $P_i = D_k(C_i) \oplus C_{i-1}$. Because every ciphertext block now depends on all plaintext before it, identical plaintext blocks diverge, and ECB's pattern leak is gone. With an unpredictable IV, CBC is provably IND-CPA [@bdjr-1997].

The per-message starting value a mode mixes in so that encrypting the same plaintext twice yields different ciphertext. For CBC and CFB the IV must be *unpredictable* -- indistinguishable from random to an attacker -- not merely fresh, because it is the first value fed into the chain [@nist-sp-800-38a]. Part 2 of this series covers how to generate one.

CBC answered the first question correctly and left the second blank, and even its confidentiality carries three sharp contract edges. This one mode seeded most of the Failure Catalog. It is malleable: a controlled flip in ciphertext block $C_i$ deterministically flips the corresponding bits of plaintext block $P_{i+1}$ while randomizing $P_i$ -- the "flip-and-garble" gadget, an attacker editing a later block without the key [@rogaway-modes-2011].

The three contract edges follow. It needs padding, and a receiver that reveals whether decrypted padding is valid turns that check into a plaintext-recovering oracle. Its IV must be unpredictable, or a chosen-plaintext attacker can distinguish messages. And with a 64-bit block, its ciphertext blocks start colliding after about $2^{32}$ blocks, leaking $P_i \oplus P_j$. Rogaway's performance verdict is blunt: CBC encryption is "inherently serial," and he can "identify no important advantages over CTR mode" [@rogaway-modes-2011].Ciphertext stealing (CBC-CS, standardized in an addendum to SP 800-38A) is the no-expansion variant that avoids padding by borrowing bits from the penultimate block. It is a useful trick, not a new security property -- CBC-CS is still malleable and still needs an unpredictable IV.

CFB: a self-synchronizing stream

CFB turns the block cipher into a stream by encrypting the previous ciphertext to produce a keystream, then XORing it with the plaintext: $C_i = P_i \oplus E_k(C_{i-1})$. The cipher never touches the plaintext directly, so there is no padding, the mode can operate on sub-block segments (one byte or even one bit at a time), and it self-synchronizes after lost or inserted segments -- a genuinely useful property for noisy character-oriented links [@rogaway-modes-2011].

The costs are real. Encryption is still serial, and for a segment size $s \lt n$ the mode makes many more block cipher calls per byte -- Rogaway notes $s = 8$ means "16 times the number of blockcipher calls as CBC," and $s = 1$ means 128 times [@rogaway-modes-2011].Folklore (and even the loose version of this article's own scope) sometimes says CFB needs only a unique IV. The primary source is stricter: SP 800-38A Section 5.3 requires the IV for both CBC and CFB to be unpredictable [@nist-sp-800-38a]. Treat CFB's IV exactly like CBC's.

CFB's malleability is the middle case, not a pure bit-flip. Because $P_i = C_i \oplus E_k(C_{i-1})$, flipping a ciphertext bit flips exactly the aligned plaintext bit in the current block -- but that same altered block is the cipher's input for the next one, so the following block decrypts to garbage. Efail (2018) weaponized precisely this: Damian Poddebniak and co-authors built malleability "gadgets" in CFB (OpenPGP's mode), engineered to absorb the garbled block while keeping the surgical edit, that turned an encrypted email into a plaintext-exfiltration channel with no key recovery and no padding oracle [@efail-2018][@efail-site].

OFB: a pre-computable stream

OFB makes the keystream independent of the message by feeding back the cipher's own output instead of the ciphertext: $O_i = E_k(O_{i-1})$, then $C_i = P_i \oplus O_i$. Because the pad depends only on the key and IV, you can compute it before the plaintext arrives, and a single flipped ciphertext bit corrupts only the corresponding plaintext bit, with no error propagation -- attractive for satellite links and digitized voice [@rogaway-modes-2011].

A number used once: a value that must never repeat under a given key. OFB and CTR need their nonce only to be *unique*, not unpredictable, so a simple counter is a perfectly good nonce [@nist-sp-800-38a]. Reusing one under the same key is catastrophic for every keystream mode, because it reproduces the exact same pad. Part 2 covers how to source these values safely.

That last point is OFB's undoing. If a $(\text{key}, \text{IV})$ pair ever repeats, the pad repeats, and $C \oplus C' = P \oplus P'$ leaks the XOR of two plaintexts with no key -- a two-time pad [@rogaway-modes-2011]. OFB is also serial in both directions, so it cannot use hardware parallelism at all, a strictly worse profile than CTR for the same "stream" benefit. And the original FIPS 81 reduced-feedback variants shortened the keystream cycle dangerously, a hazard SP 800-38A removed by defining OFB with full-block feedback only [@fips-81][@nist-sp-800-38a].

CTR: the parallel stream that wins

CTR keeps OFB's "encrypt something to make a pad" idea but replaces the serial feedback chain with an independent per-block counter: $C_i = P_i \oplus E_k(\text{nonce} ,|, i)$. Because each pad block is a standalone function of its counter, the blocks have no data dependency on one another. CTR is fully parallel on both encryption and decryption, random-access (decrypt block $i$ alone), precomputable, inverse-free, and needs no padding. Rogaway estimates it "encrypting at more than 10 times the speed of CBC" in hardware [@rogaway-modes-2011]. Its contract is the simplest of all: the counter must be unique per key, and unpredictability is explicitly not required [@bdjr-1997][@rogaway-modes-2011].

Counter mode is "the best and most modern way to achieve privacy-only encryption" and "an important building block for authenticated-encryption schemes." -- Phillip Rogaway, 2011

And here is the cliff. CTR is the best answer to the first question, which is exactly what makes its failure the point of the whole story. It is still malleable, and more transparently so than any other mode: $P = C \oplus \text{keystream}$, so flipping any ciphertext bit flips exactly the corresponding plaintext bit, with no key. The "transfer $9" to "transfer $9,000,000" edit from the opening is a single XOR, and the receiver decrypts a perfectly well-formed message. CTR removed every other excuse -- it is fast, parallel, and clean -- so the blank where integrity should be is the only thing left to see.

flowchart TD subgraph CBC["CBC: serial chaining"] cIV["IV"] --> cx1["XOR"] cP1["P1"] --> cx1 cx1 --> cE1["E_k"] --> cC1["C1"] cC1 --> cx2["XOR"] cP2["P2"] --> cx2 cx2 --> cE2["E_k"] --> cC2["C2"] end subgraph CTR["CTR: independent counters"] tK1["E_k(nonce, 1)"] --> tx1["XOR"] tP1["P1"] --> tx1 tx1 --> tC1["C1"] tK2["E_k(nonce, 2)"] --> tx2["XOR"] tP2["P2"] --> tx2 tx2 --> tC2["C2"] end

Lined up as a reference grid, the five modes and their exact contracts look like this:

Mode	Relation	IV / nonce contract	Parallelism	Malleability
ECB	`C_i = E_k(P_i)`	none (the flaw)	encrypt and decrypt parallel	block-level: cut, paste, reorder
CBC	`C_i = E_k(P_i XOR C_{i-1})`	unpredictable IV	encrypt serial, decrypt parallel	flip-and-garble (block-coupled)
CFB	`C_i = P_i XOR E_k(C_{i-1})`	unpredictable IV	encrypt serial, decrypt parallel	surgical bit, next block garbled (middle)
OFB	`C_i = P_i XOR E_k(O_{i-1})`	unique nonce	serial both ways	surgical bitwise
CTR	`C_i = P_i XOR E_k(counter_i)`	unique nonce (not unpredictable)	encrypt and decrypt parallel	surgical bitwise

The IV and nonce contracts are SP 800-38A's; the parallelism and malleability columns follow Rogaway's summary tables [@nist-sp-800-38a][@rogaway-modes-2011].

That last column deserves its own magnification, because "malleable" is not one behavior. It runs from surgical (edit one plaintext bit and touch nothing else), through a middle case (edit one bit, but wreck the neighboring block), to block-coupled (your controlled edit lands a block later):

Mode	Malleability class	What one flipped ciphertext bit does
CTR, OFB	surgical	flips exactly the aligned plaintext bit, with zero collateral
CFB	middle case	flips the aligned bit in the current block, and fully garbles the next block
CBC	block-coupled	garbles the current block, and flips the aligned bit in the next block
ECB	block-level	no sub-block control, but whole blocks can be cut, pasted, and reordered

The distinction is operational, not academic: CTR's surgical malleability is what makes the opening bit-flip a one-line edit, while CFB's "flip here, garble there" is the exact structure Efail's exfiltration gadgets were built around [@rogaway-modes-2011][@efail-2018]. Read as an evolution, the same five tell a story of steady improvement on every axis but one:

Mode	Year	Key idea	Limitation that drove the next step
ECB	1980	encrypt each block independently	deterministic; leaks block equality (not IND-CPA)
CBC	1976 / 1980	chain each block with the previous ciphertext	serial; needs padding; unpredictable IV; 64-bit birthday
CFB	1980	encrypt the previous ciphertext into a keystream	serial; sub-block sizes multiply cipher calls
OFB	1980	encrypt the feedback into a message-independent pad	serial both ways; reuse is a two-time pad
CTR	1979 / 2001	encrypt an independent counter	the best confidentiality mode, yet still no integrity

Note: Not one of the four evolutions from ECB added integrity. CBC, CFB, OFB, and CTR each improved chaining, padding, error behavior, or parallelism. Every one of them left the second question -- can the attacker change it? -- completely blank.

One honest caveat: CFB, OFB, and CTR are not a strict quality ladder. They are three parallel answers to CBC's "turn the block cipher into a stream," standardized together, with CTR the clear winner [@rogaway-modes-2011]. The linear arrow is a teaching device.

Line the four up and the pattern is undeniable. The bug was never "which chaining?" It was the blank where the second answer should be. Naming that blank correctly is the pivot the whole field turned on.

5. Malleability Is the Real Bug

Here is the reframe that organizes the entire subject: confidentiality is not security. A mode that perfectly hides your message while letting an attacker predictably rewrite it has not handed you a weaker guarantee. It has handed you a different one, and mistaking the two is the single most repeated error in applied cryptography.

The property that an attacker can transform a ciphertext into a predictable transformation of the underlying plaintext, without knowing the key or the plaintext. A malleable scheme may be perfectly confidential and still let an attacker edit the message. All five SP 800-38A modes are malleable.

Key idea: Every one of the five modes answers only confidentiality. The missing integrity answer is malleability, and malleability is the real bug. The fix is authenticated encryption -- not a faster or cleverer confidentiality mode.

This is a provable statement, not a mood. A confidentiality-only mode is not IND-CCA2 and not non-malleable; IND-CPA says nothing about an active attacker who edits ciphertext in transit [@bdjr-1997].

The mechanism differs per mode, and that difference is your diagnostic. In the pure keystream modes (CTR and OFB) the relation is $P = C \oplus \text{keystream}$, so flipping ciphertext bit $i$ flips plaintext bit $i$ exactly, with no collateral. CFB is the middle case: the flip lands surgically in the current block but garbles the next one, because CFB feeds each ciphertext block back through the cipher. In CBC the coupling runs the other way -- a flip in $C_i$ predictably edits $P_{i+1}$ while randomizing $P_i$. Part 1 develops why this is a failure of the goal, not the construction.

The stronger targets a confidentiality-only mode provably fails. IND-CCA2 (indistinguishability under adaptive chosen-ciphertext attack) hands the adversary a decryption oracle for any ciphertext but the challenge; non-malleability forbids turning one ciphertext into a predictably related one. Because all five SP 800-38A modes are malleable, none is IND-CCA2. Part 1 of this series formalizes both goals -- here they are exactly what a MAC restores.

You can run the attack from the opening. The demo below encrypts a payment instruction with a toy keystream, then, knowing only the message format, rewrites the amount by XORing a delta into the ciphertext. No key is ever touched:

{` // Toy CTR: P = C XOR keystream. Editing C edits P, with no key. NOT real crypto. function xorBytes(a, b) { return a.map(function (x, i) { return x ^ b[i]; }); } function toBytes(s) { return Array.from(s).map(function (c) { return c.charCodeAt(0); }); } function toStr(b) { return b.map(function (x) { return String.fromCharCode(x); }).join(''); }

var plaintext = 'amount:0000009'; // the honest instruction var keystream = toBytes('SECRETPADSECRET').slice(0, plaintext.length);

// Sender encrypts. The attacker sees only C -- never the key, never the keystream. var C = xorBytes(toBytes(plaintext), keystream);

// The attacker knows the fixed message FORMAT and wants this instead: var target = 'amount:9000000'; // same length, this is the "9 -> 9,000,000" edit var delta = xorBytes(toBytes(plaintext), toBytes(target)); // computable from the format alone

// He XORs the delta straight into the ciphertext. var forged = xorBytes(C, delta);

// The receiver decrypts with the real keystream and sees the forgery. console.log('Receiver reads: ' + toStr(xorBytes(forged, keystream))); // amount:9000000 console.log('Keys or keystream used by the attacker: none.'); `}

The same edit, drawn as it happens on the wire:

sequenceDiagram participant S as Sender participant A as Attacker participant R as Receiver S->>A: Ciphertext of a nine-dollar transfer Note over A: Cannot read it, AES is unbroken Note over A: But P is C XOR keystream, so flipping ciphertext bit i flips plaintext bit i A->>A: XOR a chosen delta into the amount bytes A->>R: Modified ciphertext Note over R: Decrypts to a nine-million transfer, perfectly well-formed R->>R: Accepts the forgery as authentic Confidentiality without integrity is not weaker encryption. It is a different, largely illusory guarantee.

Now turn the lens on the historical record. Every famous break of these modes is one of two diagnoses -- a missing integrity answer, or a violated IV/nonce contract:

Break	Year	Mode	Root cause	Lesson
Adobe [@troyhunt-adobe-2013]	2013	ECB	confidentiality answered wrongly (determinism)	never ECB for messages
Padding oracle, Vaudenay [@vaudenay-2002]	2002	CBC	no integrity plus a distinguishable padding check	verify before decrypting
BEAST [@bard-2004][@cve-2011-3389]	2011	CBC	violated IV contract (predictable IV)	IVs must be unpredictable
Lucky Thirteen [@lucky-thirteen-2013]	2013	CBC	wrong composition order plus a timing leak	Encrypt-then-MAC, constant time
POODLE [@poodle-2014][@cve-2014-3566]	2014	CBC (SSL 3.0)	padding oracle after a downgrade	retire the mode and the fallback
Sweet32 [@sweet32-2016][@cve-2016-2183]	2016	CBC (64-bit)	block-size birthday bound	no 64-bit ciphers for bulk
Efail [@efail-2018]	2018	CBC / CFB	missing integrity (malleability gadget)	authenticate the ciphertext
Truncation, Smyth-Pironti [@smyth-pironti-2013]	2013	TLS record (any mode)	missing integrity of length and framing (omission)	authenticate the end, not just the bytes
GCM nonce reuse [@joux-2006][@nonce-disrespecting-2016]	2016	CTR / GCM	violated nonce contract	never repeat a (key, nonce)

Most of these breaks edit or leak bytes, but the subtlest one deletes them. Ben Smyth and Alfredo Pironti showed at WOOT 2013 that silently truncating a TLS stream -- cutting it short at an attacker-chosen point -- changes the meaning a web application infers from a "complete" response, because the record layer authenticated the bytes it carried but never the fact that the message had ended [@smyth-pironti-2013]. That is an integrity failure of omission, and it is why the fix in Section 10 authenticates length and end-of-stream, not just content. Most of the rest are TLS history, which the SChannel post tells from the deployment side.Precision on GCM nonce reuse: one repeated $(\text{key}, \text{nonce})$ immediately leaks $P_1 \oplus P_2$, but uniquely recovering the GHASH subkey $H$ generally needs two or more collisions. Never say "one reuse leaks $H$" [@joux-2006].The routinely mis-cited CVE-2016-0270 actually names IBM Domino, not OpenSSL, and NVD warns it "has been incorrectly used for GCM nonce reuse issues in other products." The deployed GCM-nonce forgery is the Nonce-Disrespecting Adversaries paper, whose byline is exactly five authors: Boeck, Zauner, Devlin, Somorovsky, and Jovanovic [@cve-2016-0270][@nonce-disrespecting-2016].

Note: A bare confidentiality mode lets an attacker edit your plaintext undetected -- bit-for-bit in CTR and OFB, a surgical bit plus a garbled next block in CFB, and block-coupled in CBC. Use an AEAD, or Encrypt-then-MAC and verify the tag before you decrypt a single byte.

The fix is to add the missing answer, and the order in which you add it turns out to matter. Bellare and Namprempre (2000) and Krawczyk (2001) proved that Encrypt-then-MAC -- encrypt, then MAC the ciphertext, and verify the tag before decrypting -- generically yields both IND-CPA and INT-CTXT, a scheme that is confidential and unforgeable, while MAC-then-encrypt and encrypt-and-MAC are fragile [@bellare-namprempre-2000][@krawczyk-2001].

A keyed tag that proves a message was not altered and came from someone holding the key. Anyone with the key can compute the tag over a message; without it, forging a valid tag is infeasible. HMAC, CMAC, and CBC-MAC are common constructions. A MAC supplies the integrity answer a confidentiality mode leaves blank. SSL and early TLS shipped MAC-then-encrypt. The theory said Encrypt-then-MAC was the safe generic choice. That debate was not settled by proof alone -- it was settled by a decade of breaks (BEAST, Lucky Thirteen, POODLE) that all exploited the MAC-then-encrypt-plus-CBC-padding surface, until TLS 1.3 removed CBC outright and mandated authenticated encryption [@krawczyk-2001][@rfc-8446-tls13].

Better still, fuse the two answers into one primitive.

A single primitive that provides confidentiality *and* integrity at once, and can also authenticate unencrypted "associated data" such as headers. It answers both questions in one object, so a modified ciphertext is rejected before any plaintext is released.

The punchline binds this whole article together: the dominant AES AEADs are literally these modes plus a MAC. GCM equals CTR plus GHASH, a polynomial hash over $GF(2^{128})$ [@mcgrew-viega-2004][@nist-sp-800-38d]. CCM equals CTR plus CBC-MAC [@rfc-3610-ccm][@nist-sp-800-38c]. The 1979 counter idea and the 1976 chaining idea, welded into a primitive that finally answers both questions -- the SMB 3.1.1 post shows GCM and CCM running in a real protocol.

flowchart TD P["Plaintext"] --> CTR["CTR encryption"] CTR --> C["Ciphertext"] C --> M["MAC over ciphertext and associated data"] M --> T["Authentication tag"] C --> W["Transmit ciphertext plus tag"] T --> W W --> V{"Tag valid?"} V -->|"no"| X["Reject, decrypt nothing"] V -->|"yes"| D["Decrypt and release plaintext"]

One boundary to keep honest: not every modern AEAD is built from these modes. ChaCha20-Poly1305 (a stream cipher plus Poly1305) and Ascon (a sponge permutation) are first-class AEADs that are deliberately not SP 800-38A constructions [@rfc-8439-chacha20][@nist-sp-800-232]. The lineage claim is bounded to the AES AEADs.

With integrity finally bolted on, every entry in the catalog retroactively dies -- a modified ciphertext fails the tag before a byte is decrypted. So the field declared victory and shipped AEAD everywhere. Then it discovered that AEAD did not repeal the IV/nonce contract. It sharpened it -- which is exactly where the state of the art picks up.

6. The Field Is Retiring Confidentiality-Only Modes

The modern answer to "which block cipher mode should I use?" is no bare confidentiality mode at all. It is a choice of AEAD, and between 2024 and 2026 that answer stopped being folklore and became written policy. The tell is what the standards bodies did not do. Faced with four decades of breaks, nobody proposed a sixth confidentiality mode. Every document below reaches instead for authentication.

Start with the audit. NIST IR 8459, published in September 2024 by Nicky Mouha and Morris Dworkin, is the first formal review of the entire SP 800-38 series, and it reads less like a specification than a post-mortem: it works through the family mode by mode, documenting why each keeps failing, and its recommendations point at authenticated encryption rather than a patched mode -- down to disallowing ECB for the very job it keeps losing at, encrypting secrets [@nist-ir-8459]. An audit whose answer to "which new mode?" is "stop adding modes" is this whole section in miniature.

The policy machinery had already started turning. In April 2023 NIST's Crypto Publication Review Board published its decision to revise SP 800-38A itself, with goals that read like a confession: to "limit the approval of the Electronic Codebook (ECB) mode," to "provide guidance on the importance of incorporating authentication, where feasible," to fold in "three variations of ciphertext stealing for Cipher Block Chaining mode," and -- once a stronger technique exists -- to "consider deprecating the modes in SP 800-38A" [@csrc-sp38a-revision-2023]. The document that defines the five modes is contemplating its own retirement, and names authenticated encryption as the successor it is waiting on.

SP 800-131A Revision 3 supplies the compliance lever. Its initial public draft of October 21, 2024 disallows ECB for encrypting secret data and relegates it to legacy (decrypt-only) use; the draft's own phrase is "the retirement of ECB as a confidentiality mode of operation" [@nist-sp-800-131a-r3]. For a FIPS-bound product that is an effective-on-finalization change, not a suggestion.

Where the field is heading is just as clear from what it standardized. Ascon, finalized as NIST SP 800-232 in August 2025, is the new AEAD for the constrained, low-power class for which earlier standards specified AES-CCM -- and it is a sponge permutation, pointedly not an SP 800-38A block cipher mode [@nist-sp-800-232]. "Migrate to AEAD" does not mean "migrate to a mode." And for the one contract even AEADs still impose, AES-GCM-SIV (RFC 8452, 2019) is the standardized hedge: a nonce-misuse-resistant scheme that degrades gracefully instead of catastrophically when a nonce repeats [@rfc-8452-gcm-siv].

An AEAD that stays secure even when a nonce is accidentally reused, leaking at most whether two identical messages were sent under the same nonce, instead of collapsing into a two-time pad and forgery. AES-GCM-SIV reaches this by deriving its internal counter from a MAC of the whole message, so a repeat is a mild, bounded leak rather than a catastrophe [@rfc-8452-gcm-siv][@gcm-siv-spec-2017]. AES-GCM-SIV is engineered to be "nonce misuse resistant -- that is, [it does] not fail catastrophically if a nonce is repeated." -- RFC 8452

Document	What it does	Status
NIST IR 8459 [@nist-ir-8459]	audits the whole SP 800-38 series; steers ECB and secrets toward AEAD	published, Sept 2024
Decision to revise SP 800-38A [@csrc-sp38a-revision-2023]	limit ECB, add CBC ciphertext stealing, urge authentication, weigh deprecation	published, Apr 2023
SP 800-131A Rev. 3 [@nist-sp-800-131a-r3]	moves ECB to legacy (decrypt-only) use; disallowed for encrypting secrets on publication	draft (Oct 21, 2024 IPD)
Ascon (SP 800-232) [@nist-sp-800-232]	a permutation AEAD for constrained devices, deliberately not a 38A mode	final, Aug 2025
AES-GCM-SIV (RFC 8452) [@rfc-8452-gcm-siv]	a nonce-misuse-resistant AEAD hedge	published, 2019

The migration is credible now, rather than merely aspirational, because the substrate already moved. TLS 1.3 (RFC 8446, 2018) removed every CBC-mode cipher suite and makes AES-GCM its mandatory-to-implement AEAD [@rfc-8446-tls13]; QUIC protects every packet with an AEAD, binding the packet number directly into the AEAD nonce, with no unauthenticated-confidentiality option at all [@rfc-9001-quic-tls].

The performance objection that once favored CBC also evaporated: with AES-NI and the carry-less multiply instruction PCLMULQDQ, AES-GCM fell from roughly 3.7 cycles per byte in optimized software toward about 1, so the fast path and the safe path are now the same path [@krovetz-rogaway-ae-2011][@gcm-siv-spec-2017]. The 2024-2026 standards are simply retiring the confidentiality-only modes to match a deployment reality that migrated years earlier.

Key idea: The modern "which mode?" question is really "which AEAD?" The five SP 800-38A confidentiality-only modes now survive as internals of authenticated encryption and as legacy interoperability options -- not as something you deploy on purpose.

Not every SP 800-38 sibling is a confidentiality mode. SP 800-38G defines FF1 and FF3, *format-preserving* encryption that turns a 16-digit card number into another 16-digit string so it still fits a legacy database column [@nist-sp-800-38g]. Different goal, and it came with its own break: Durak and Vaudenay gave a practical total recovery of FF3 over small domains, a slide attack exploiting the design's "bad domain separation" in roughly $O(N^{11/6})$ chosen plaintexts [@durak-vaudenay-2017]. NIST responded with FF3-1, shrinking the tweak from 64 to 56 bits and raising the minimum domain to one million [@nist-sp-800-38g-r1]. Signposted here, not surveyed -- it is not one of the five.

Note: Reach for a vetted AEAD -- AES-GCM or ChaCha20-Poly1305 -- give it a unique nonce per key, cap your messages under the nonce limit, and drop to a raw confidentiality mode only as an Encrypt-then-MAC building block when an AEAD is genuinely unavailable.

The cross-references write themselves: the CBC-to-GCM migration is the story the SChannel post tells for Windows TLS, and GCM and CCM running in a shipping protocol is what the SMB 3.1.1 post shows. So the strategic direction is settled: move to AEAD. But "AEAD" is not one thing. The moment you have to ship, the question sharpens from "which mode?" to "which AEAD, with which parameters, for which platform?" -- and that has a real, defensible answer.

7. When You Must Pick a Mode, and Which AEAD

Two comparisons matter in practice. The first is the intra-family one folklore gets wrong. The second is the one you actually face when you ship.

CBC versus CTR: a choice that changes nothing that matters

Both are confidentiality-only, both are malleable, and both are still everywhere. On the merits CTR is superior: fully parallel on encryption and decryption, random-access, and governed by the simplest contract (a unique nonce). CBC survives on forty years of deployment inertia, not on technical advantage -- Rogaway, having surveyed all five modes, reports "no important advantages over CTR mode" for CBC [@rogaway-modes-2011].

But here is the point most tuning guides miss: swapping CBC for CTR fixes nothing that matters, because neither answers the second question. You trade a serial mode with padding for a parallel mode without it, and you keep every bit of the malleability. If your reason for the swap is security, you are solving the wrong problem.

Which AEAD

This is the comparison with real stakes, and every option is a defensible answer to a different constraint. AES-GCM is the throughput default on modern CPUs, hardware-accelerated by AES-NI and CLMUL, and brittle exactly where humans err -- a single reused nonce is catastrophic [@nist-sp-800-38d]. ChaCha20-Poly1305 is the software default: constant-time by construction, with no AES hardware and no cache-timing hazard [@rfc-8439-chacha20]. AES-CCM is CTR plus CBC-MAC, two-pass and small-footprint [@rfc-3610-ccm][@nist-sp-800-38c]; those documents define CCM, and its compact profile is why the IEEE wireless standards adopt it -- WPA2 (802.11i) [@krovetz-rogaway-ae-2011] and IEEE 802.15.4 low-power wireless [@rfc-4944][@rfc-9031] both build their link-layer security on it. AES-GCM-SIV is the nonce-misuse-resistant hedge [@rfc-8452-gcm-siv]. Ascon is the lightweight standard for microcontrollers [@nist-sp-800-232].

AEAD	Built from	Passes	Constant-time	Nonce-reuse penalty	Best fit
AES-GCM [@nist-sp-800-38d]	CTR + GHASH	1, online	needs AES-NI, CLMUL	catastrophic (forgery)	server bulk, TLS
ChaCha20-Poly1305 [@rfc-8439-chacha20]	stream + Poly1305	1, online	by construction (software)	catastrophic	mobile, no AES hardware
AES-CCM [@rfc-3610-ccm]	CTR + CBC-MAC	2, not online	needs AES-NI	catastrophic	WPA2, IoT, small code
AES-GCM-SIV [@rfc-8452-gcm-siv]	POLYVAL-SIV + CTR	2, not online	needs AES-NI, CLMUL	graceful (leak equality)	nonce-uncertain systems
Ascon [@nist-sp-800-232]	sponge permutation	1 (duplex)	easy to protect	catastrophic	microcontrollers, IoT

The performance folklore is worth correcting too. The cleanest apples-to-apples software measurement, Krovetz and Rogaway at FSE 2011 on an Intel i5 "Clarkdale," found CCM near 4.2 cycles per byte, GCM near 3.7, OCB near 1.5, and raw CTR near 1.3 [@krovetz-rogaway-ae-2011]. Read that as an ordering under fixed effort, not a modern absolute: with mature AES-NI and CLMUL, AES-GCM reaches roughly 1 cycle per byte on current x86 [@gcm-siv-spec-2017]. The durable lesson is that hardware, not algorithm choice, moved GCM from 3.7 to 1 -- which is the whole reason CTR-based AEADs won.

The two non-38A AEADs from Section 5, ChaCha20-Poly1305 and Ascon, sit within a broader research lineage -- OCB, EAX, SIV/AES-SIV, IACBC/IAPM, McOE -- that is real but out of scope here; OCB is the elegant one-pass design that patents kept out of deployment for years [@rfc-7253-ocb].

Every column wins on some axis and loses on another; none is unconditionally best. And the reasons why no single scheme dominates are not engineering accidents. They are theorems. To use any of these correctly, you have to know the walls they are all pressed against.

8. You Cannot Get Integrity From a Confidentiality Mode

The two-question frame is not merely good advice. It is a theorem, and it draws a hard line no amount of clever engineering crosses.

Start with the central impossibility. IND-CPA does not imply IND-CCA2 or non-malleability; BDJR proved ECB is not even IND-CPA and that CBC and CTR are IND-CPA with proper IVs and nonces, but IND-CPA says nothing about an active attacker editing ciphertext [@bdjr-1997]. Bellare and Namprempre sharpened the target, separating INT-PTXT from INT-CTXT and proving that only Encrypt-then-MAC generically delivers IND-CPA plus INT-CTXT [@bellare-namprempre-2000][@krawczyk-2001].

The consequence is a lower bound, not a tip: you cannot patch integrity into a bare CTR, CBC, CFB, or OFB mode, because malleability is a property of the confidentiality goal, not a bug in any construction. This is the reasoning Part 1 sets up in full.

Key idea: "Confidentiality does not imply integrity" is a theorem, not advice. IND-CPA does not imply IND-CCA2 or non-malleability, so you cannot patch integrity into a bare CTR, CBC, CFB, or OFB mode. It is a property of the goal, not a bug in the construction.

The second wall is the block size.

The threshold at which collisions among random $n$-bit values become likely: around $2^{n/2}$ of them. For a block cipher it means ciphertext blocks start repeating -- and leaking $P_i \oplus P_j$ -- after roughly $2^{n/2}$ blocks, regardless of key length. This is the ceiling behind Sweet32 and the GCM nonce cap.

Ciphertext-collision leakage grows like $q^2 / 2^n$ in the number of blocks $q$, so security degrades at about $q \approx 2^{n/2}$ blocks: roughly $2^{32}$ blocks (about 32 GiB) for a 64-bit cipher, which is the Sweet32 ceiling, and $2^{64}$ blocks for AES [@bdjr-1997][@sweet32-2016]. A provable ceiling, independent of key size -- doubling the key does not move it.

GCM inherits its own two ceilings, and conflating them is a common error. Per SP 800-38D, a single message is capped at $2^{39} - 256$ bits (about 64 GiB), and, under random 96-bit nonces, the number of invocations per key must stay below about $2^{32}$ to keep the nonce-collision probability negligible [@nist-sp-800-38d]. One is a length limit; the other is a count limit. They are different numbers that both bite.

The last wall is the sharpest, because no computational assumption stands behind it. Reusing a $(\text{key}, \text{nonce})$ in any keystream mode leaks $C_1 \oplus C_2 = P_1 \oplus P_2$ -- a two-time pad. You can watch it recover a plaintext with nothing but XOR:

{` // Reusing a (key, nonce) reproduces the SAME keystream. That is a two-time pad. function xorBytes(a, b) { return a.map(function (x, i) { return x ^ b[i]; }); } function toBytes(s) { return Array.from(s).map(function (c) { return c.charCodeAt(0); }); } function toStr(b) { return b.map(function (x) { return String.fromCharCode(x); }).join(''); }

var p1 = 'attack at dawn'; var p2 = 'defend the fort'; var n = Math.min(p1.length, p2.length); var ks = toBytes('REUSEDPADREUSEDPAD').slice(0, n); // the SAME pad used twice -- the bug

var c1 = xorBytes(toBytes(p1).slice(0, n), ks); var c2 = xorBytes(toBytes(p2).slice(0, n), ks);

// The attacker never has the key. He XORs the two ciphertexts; the pad cancels: var leaked = xorBytes(c1, c2); // equals p1 XOR p2

// With a crib -- a good guess at p1 -- he recovers p2 outright: var crib = toBytes('attack at dawn').slice(0, n); console.log('Recovered from a crib: ' + toStr(xorBytes(leaked, crib))); // defend the for `}

Note: Reusing a $(\text{key}, \text{nonce})$ leaks $P_1 \oplus P_2$ with no computational assumption to fall back on -- no key length saves you. In GCM it is worse: repeated nonces also expose the GHASH subkey $H$ -- uniquely, once two or more collisions accumulate -- enabling universal forgery [@joux-2006][@nist-sp-800-38d].

The core science, then, is closed. "Confidentiality does not imply integrity" is settled, reuse is an information-theoretic floor, and the block-size wall is provable. If the theory is finished, what is left to work on? More than you would guess -- and it is where the modes still bite.

9. Where Modes Still Bite

The confidentiality-versus-integrity fight is won. The live frontier is one level up: not "is it confidential?" but "how resilient is the authenticated scheme when humans and hardware misbehave?" Four problems are genuinely open, and one popular worry is not a problem at all.

Make nonce-misuse-resistance the default, not the hedge. AES-GCM fails catastrophically on nonce reuse, yet reuse -- from stateless senders, VM clones, restarted counters -- is among the most common real misuses [@nist-sp-800-38d]. AES-GCM-SIV delivers graceful degradation at roughly 1 cycle per byte and up to $2^{50}$ messages per key, "well suited for real world applications that need a nonce-misuse resistant Authenticated Encryption scheme" [@gcm-siv-spec-2017].

But it is two-pass and offline, and it remains opt-in. The open problem is an AEAD that is online, single-pass, parallel, roughly 1 cycle per byte, and misuse-resistant at once -- and, harder, getting TLS and KMS libraries to make it the default. NIST IR 8459 flags nonce management across the whole SP 800-38 series as a first-order concern [@nist-ir-8459].

The property that binds a ciphertext to the single key and context that produced it, so it cannot be made to decrypt validly under a second key. Standard AEAD security says nothing about it, which is why AES-GCM and ChaCha20-Poly1305 lack it -- and why a ciphertext can be crafted to open to two different valid plaintexts under two different keys.

Key commitment and robustness. AES-GCM and ChaCha20-Poly1305 are not key-committing: a single ciphertext can be built to decrypt to valid plaintexts under two different keys [@key-commitment-2022]. Real systems assume otherwise, so this breaks password-based encryption, message franking, and envelope schemes.

Partitioning-oracle attacks turned that gap into practical password recovery against Shadowsocks proxies; the same study only surveyed protocols such as OPAQUE as potentially vulnerable rather than breaking them [@partitioning-oracles-2021]. The "invisible salamanders" attack built AES-GCM ciphertexts that decrypt to valid files under two keys, defeating message franking [@fast-franking-2018], a technique later generalized across file formats [@key-commitment-2022]. A genuine lower bound -- compactly committing AE is provably impossible at AES-GCM's exact performance profile [@fast-franking-2018] -- meets a cheap upper bound -- committing GCM and GCM-SIV variants at no ciphertext expansion [@committing-ae-2022]. The bounds nearly meet, yet the deployed default still sits on the wrong side.

Constant-time implementation. CBC-decrypt-then-MAC timing gave us Lucky Thirteen, and table-based AES and GHASH leak through cache [@lucky-thirteen-2013]. This is effectively solved on hardware with AES-NI and CLMUL, and ChaCha20-Poly1305 is constant-time by design [@rfc-8439-chacha20]. It stays a live hazard on microcontrollers and throughout the legacy CBC base.

The forty-year migration. A vast deployed base still runs CBC and 64-bit block ciphers, keeping Sweet32 and padding oracles alive. TLS 1.3 removed CBC-mode cipher suites and mandates AEAD [@rfc-8446-tls13], and IR 8459 audits the whole series [@nist-ir-8459], but embedded firmware, file-format crypto, database encryption, and private protocols lag by years. This is an engineering and logistics problem, not a mathematical one -- and it is the one that keeps the Failure Catalog growing.

A widespread belief holds that quantum computers break block cipher modes. To first order they do not: Grover's algorithm gives only a quadratic speedup on key search, so doubling the key (AES-256) restores the margin. The post-quantum churn is in key exchange and signatures, not in symmetric modes or AEADs [@nist-ir-8105].

None of these is a hole in the confidentiality-versus-integrity theory. All are the gap between the ideal AEAD and the one you can install today -- which is exactly the gap a practitioner has to bridge. So here are the rules that bridge it.

10. Use X With These Params In Case Y

Everything so far collapses into one rule and a short decision tree you can apply without re-deriving a theorem. The rule: use a vetted AEAD, not a raw confidentiality mode [@ferguson-schneier-kohno-2010].

The decision guide, in priority order:

Default: AES-GCM with a 96-bit nonce, unique per key -- prefer a deterministic counter -- and a hard cap of fewer than $2^{32}$ messages per key [@nist-sp-800-38d].
Cannot guarantee unique nonces: AES-GCM-SIV [@rfc-8452-gcm-siv], or XChaCha20-Poly1305, which widens the RFC 8439 ChaCha20-Poly1305 construction to a 192-bit random nonce [@rfc-8439-chacha20].The 192-bit-nonce XChaCha20 variant is specified in the IRTF draft draft-irtf-cfrg-xchacha, not in RFC 8439, which standardizes only the 96-bit ChaCha20-Poly1305 [@rfc-8439-chacha20]. The wider nonce is exactly what lets you pick nonces at random without tracking a counter.
No fast AES hardware, or you need constant-time software: ChaCha20-Poly1305 [@rfc-8439-chacha20].
Constrained or IoT, small code budget: Ascon-AEAD128 [@nist-sp-800-232] or AES-CCM [@rfc-3610-ccm].
Need key or context commitment (password-based encryption, franking, envelope, rotation): a committing AEAD [@committing-ae-2022].
Must drop to a raw mode (interoperability or a FIPS boundary): CTR plus Encrypt-then-MAC (CMAC or HMAC) with a unique nonce, or CBC only with a fresh unpredictable IV plus Encrypt-then-MAC plus constant-time padding [@nist-sp-800-38a][@bellare-namprempre-2000].
Streaming or large objects: do not ship one monolithic AEAD blob you cannot buffer. Split the stream into records, give each a unique per-chunk nonce, and authenticate a sequence number plus an explicit end-of-stream marker, so a dropped, reordered, or truncated record is caught rather than silently accepted. This is the record-protocol pattern DTLS 1.3 uses -- rejecting duplicates through "a sliding receive window" -- and that QUIC uses by binding each packet number into its AEAD nonce; together they close truncation and replay, the two integrity gaps a bare mode cannot see [@smyth-pironti-2013][@rfc-9147-dtls13][@rfc-9001-quic-tls].
Never: ECB for messages, a 64-bit block cipher for bulk data, a reused nonce, or "encryption" with no integrity tag.

flowchart TD Start["Need to encrypt a message"] --> Q1{"Is a vetted AEAD available?"} Q1 -->|"no"| Raw["CTR or CBC plus Encrypt-then-MAC, verify tag first"] Q1 -->|"yes"| Q2{"Can you guarantee unique nonces?"} Q2 -->|"no"| NMR["AES-GCM-SIV or XChaCha20-Poly1305 (192-bit nonce)"] Q2 -->|"yes"| Q3{"Fast AES hardware present?"} Q3 -->|"no"| Chacha["ChaCha20-Poly1305"] Q3 -->|"yes"| Q4{"Constrained device?"} Q4 -->|"yes"| Small["Ascon-AEAD128 or AES-CCM"] Q4 -->|"no"| GCM["AES-GCM, 96-bit nonce, fewer than 2^32 messages per key"]

When you do touch a raw mode, the contract is the whole game. Part 2 covers how to generate these values; this table says what each mode requires:

Mode	Requirement	Consequence of violation
ECB	none (and that is the flaw)	determinism leaks block equality
CBC	unpredictable and unique IV	a predictable IV enables BEAST
CFB	unpredictable and unique IV	a predictable IV enables chosen-plaintext distinguishing
OFB	unique nonce	reuse is a two-time pad
CTR	unique nonce (unpredictability not required)	reuse is a two-time pad

Those requirements come straight from SP 800-38A [@nist-sp-800-38a]; the raw bytes that satisfy them come from a CSPRNG, which the Windows CSPRNG post covers, and the real API calls that wire AES-CBC and AES-GCM together live in the CNG post. Finally, every common misuse maps one-to-one to a named break and its fix:

Misuse	Named break	Fix
ECB for structured data	Adobe 2013 [@troyhunt-adobe-2013]	AEAD over AES
static or predictable IV	BEAST [@cve-2011-3389]	fresh unpredictable IV, or an AEAD
reused GCM nonce	Nonce-Disrespecting Adversaries [@nonce-disrespecting-2016]	counter nonces, or GCM-SIV / XChaCha
MAC-then-encrypt or encrypt-and-MAC	Lucky Thirteen [@lucky-thirteen-2013]	Encrypt-then-MAC, verify before decrypt
no integrity at all	Efail [@efail-2018]	an AEAD, or Encrypt-then-MAC
64-bit block cipher for bulk	Sweet32 [@sweet32-2016]	a 128-bit-block AEAD
truncation with no length integrity	Truncation, Smyth-Pironti [@smyth-pironti-2013]	authenticate length and end-of-stream

Run `openssl s_client -connect example.com:443 -tls1_3` and read the `Cipher` line: a modern server reports an AEAD such as `TLS_AES_128_GCM_SHA256` or `TLS_CHACHA20_POLY1305_SHA256`. If you instead see a suite with `CBC` in the name, you are looking at a legacy, malleable-mode configuration that belongs on the migration list.

Note: Read every mode as a building block with an exact IV/nonce contract, and read every break as a missing integrity answer or a violated contract. Default to an AEAD; touch a raw mode only under Encrypt-then-MAC discipline, and only when an AEAD is off the table.

Notice that every rule is the same rule wearing different clothes: pick the primitive that answers both questions, and honor its IV/nonce contract. The folklore that gets this wrong is dense enough to deserve its own section.

11. Misconceptions, Named and Corrected

Seven half-truths cause real incidents. Each dissolves under the same two-question lens.

No. All five SP 800-38A modes are malleable, so an attacker who cannot read your ciphertext can still predictably edit the plaintext -- bit-for-bit in the additive keystream modes CTR and OFB, block-coupled in CBC, and a mix of the two in CFB. Confidentiality and integrity are different guarantees; you need a MAC or an AEAD to get the second one, and encryption alone does not provide it. Only as a building block, never as a message-encryption mode. The raw single-block permutation is legitimate inside key wrap and CMAC or CBC-MAC. But ECB is deterministic, so the moment your data has any structure or repetition it leaks block equality -- which is why NIST is moving ECB to legacy use [@nist-sp-800-131a-r3]. The rule is "never ECB for messages," not "ECB has no use anywhere." No. A random IV fixes ECB's determinism, but it adds no integrity -- the mode is still malleable. And the requirement is not uniform: CBC and CFB need an *unpredictable* IV, while CTR and OFB need only a *unique* nonce [@nist-sp-800-38a]. Getting that distinction wrong is exactly what BEAST exploited. No. Under random 96-bit nonces you must stay below roughly $2^{32}$ invocations per key to keep the nonce-collision probability negligible [@nist-sp-800-38d]. Past that, a repeat becomes likely, and a repeated GCM nonce fails catastrophically. If you cannot count, use AES-GCM-SIV or XChaCha20-Poly1305 instead. That fixes nothing that matters. Both are confidentiality-only and both are malleable; swapping one for the other trades performance characteristics, not security [@rogaway-modes-2011]. The fix is an AEAD, not a different malleable mode. Not under nonce reuse. A single repeated $(\text{key}, \text{nonce})$ leaks $P_1 \oplus P_2$, and with two or more collisions it recovers the GHASH subkey $H$, enabling universal forgery -- Joux's "forbidden attack," which was later found live on real TLS servers [@joux-2006][@nonce-disrespecting-2016]. GCM is only as strong as its nonce discipline. Order matters. MAC-then-encrypt and encrypt-and-MAC are fragile and produced Lucky Thirteen and the padding-oracle family [@lucky-thirteen-2013]. The proven-safe generic composition is Encrypt-then-MAC: authenticate the ciphertext and verify the tag *before* you decrypt [@bellare-namprempre-2000].

Every one dissolves into the same sentence -- which is where this started, and where it ends.

Two Questions, Forty Years

Return to the opening. A ciphertext AES kept perfectly secret, rewritten in transit by an attacker who never read a byte of it, and accepted as authentic -- because the mode answered only the first of two questions. That was not an exotic failure. It was the ordinary shape of every break in this article.

Run the catalog back through the lens and the pattern is total. Adobe [@troyhunt-adobe-2013], Vaudenay's padding oracle [@vaudenay-2002], BEAST [@cve-2011-3389], Lucky Thirteen [@lucky-thirteen-2013], POODLE [@cve-2014-3566], Sweet32 [@cve-2016-2183], Efail [@efail-2018], and GCM nonce reuse [@nonce-disrespecting-2016]: in every case, AES or DES did exactly what it promised, and the variable was always which question the design forgot or which IV/nonce contract it violated. Not one of these was a cipher break.

Read that way, the 2024-2026 state of the art is a single move. The field stopped iterating confidentiality modes and standardized the second answer. Authenticated encryption is the destination -- and its dominant AES instances, GCM and CCM, are literally these very modes plus a MAC, while ChaCha20-Poly1305 and Ascon supply a parallel lineage that is not [@nist-ir-8459][@nist-sp-800-232]. The frontier moved with it: nonce-misuse resistance and key commitment are the properties the deployed defaults still lack.

The payoff of the field guide is the same as its premise. Master the five not as interchangeable dropdown options but as building blocks with exact contracts, and every break -- past or future -- becomes readable on sight. You do not need to memorize the next CVE. You need one test, and you already have it: which question did this mode answer, and was its IV/nonce contract honored?

That lens outlives every mode, every cipher, and every standard revision. Which is why this is Part 5 of a field guide to protocol design, not a chapter on five diagrams.

They Read Your Plaintext Without Breaking Your Cipher: A Field Guide to Padding Oracles

noreply@paragmali.com (Parag Mali) — Wed, 08 Jul 2026 20:09:31 GMT

A padding oracle lets an attacker read your plaintext without ever touching your key -- and it is not a flaw in AES, in CBC, or even in PKCS#7. It is what you get whenever a receiver reveals *whether an attacker-chosen ciphertext decrypted to well-formed plaintext* before it has proven that ciphertext authentic. That one leaked bit ("was the padding valid?"), plus CBC's malleability, recovers plaintext one byte at a time -- about 128 guesses per byte -- as Serge Vaudenay showed in 2002 and Juliano Rizzo and Thai Duong weaponized against ASP.NET in 2010.

This field guide follows the same bug leaking through progressively quieter channels: a loud error (Vaudenay), coarse timing (Canvel), statistical timing under unified errors (Lucky Thirteen), SSL 3.0's unchecked padding (POODLE), and the oracle re-created by Lucky Thirteen's own fix (CVE-2016-2107). Every point fix lost. The single structural cure is to invert the order: authenticate before you decrypt-and-unpad. Encrypt-then-MAC proves it attains IND-CCA plus INT-CTXT; AEAD, mandated by TLS 1.3, ships it with no knob to misset. The article ends with ranked decision rules and a design-review checklist for 2026.

1. The Break That Never Touched the Key

In September 2010, two researchers pointed a few thousand malformed requests at an ordinary ASP.NET application and walked away with its authentication tickets and its web.config -- the site's master secrets -- without ever attacking its AES-256 encryption or going near the key [@rizzo_duong_woot2010]. It had done nothing more than return one error when a decrypted request had bad padding and a different error when the padding was fine but the data was not. That one-bit difference is a decryption machine: the attackers never broke the cipher, they turned the server's error handling into the decryption function.

Sit with the paradox, because the rest of this article lives inside it. AES-256 was, and is, intact. Nobody factored anything, guessed a key, or exploited a weakness in the block cipher's rounds. The plaintext walked out the door one byte at a time purely because the server answered a question it should never have been willing to answer: was this ciphertext, which I did not create, well-formed after I decrypted it?

Juliano Rizzo and Thai Duong automated that question against WebResource.axd and ScriptResource.axd handlers and recovered Forms-authentication tickets and server files. The United States National Vulnerability Database catalogs it as CVE-2010-3332, the "ASP.NET Padding Oracle Vulnerability," and Microsoft shipped an out-of-band patch to close it [@cve_2010_3332]. This was not a lab curiosity. It was, at the time, the largest deployed instance of a bug that had been sitting in plain sight for eight years.

A padding oracle is an attack class, not a cipher weakness. A receiver decrypts an attacker-chosen ciphertext, checks whether the recovered plaintext has valid padding, and reveals the verdict -- through an error message, a timing difference, or any observable behavior. That single accept/reject bit, repeated, becomes a plaintext-recovery oracle that never attacks the underlying cipher or key.

The reframe is worth stating in the sharpest possible terms, because once you hold it you will see this bug everywhere.

The attacker never attacks the cipher. They turn the receiver's error handling into the decryption function -- "decrypt, then validate" becomes "decrypt, then confess."

This is Part 6 of a field guide for protocol designers. It assumes the malleability of CBC mode from Part 5 (the lever the attack pulls) and the chosen-ciphertext adversary from Part 1 (this is that adversary, deployed and winning). By the end you will carry one diagnostic sentence and drop every named break in this article -- Vaudenay, Lucky Thirteen, POODLE, and tomorrow's application-layer oracle -- onto it on sight: when a ciphertext you did not create arrives, what does the receiver reveal about it before it has proven the ciphertext authentic?

If AES was intact and the key was never touched, then the machine that recovered the plaintext was built entirely out of the server's own responses. That idea did not begin with CBC, or even with symmetric cryptography. To see the atom clearly, go back to the first time anyone realized that a receiver's verdict on validity is itself a decryption function.

2. A Validity Check Is a Decryption Oracle

The year is 1998, the place is Bell Labs, and Daniel Bleichenbacher is staring at an SSL server that is far too honest. When the server receives an RSA-encrypted message, it decrypts and checks whether the result has the structure that the PKCS #1 v1.5 standard demands. If the structure is wrong, it says so. Bleichenbacher realized that this single yes/no answer -- does the decrypted message have valid PKCS #1 formatting? -- is enough to recover the plaintext.

With roughly $2^{20}$ adaptively chosen queries, he could extract an RSA-protected session key without factoring the modulus and without ever learning the private key [@bleichenbacher1998]. The server's "is this well-formed?" answer was the attacker's decryption function. This is the seed of everything that follows.

It is also the moment to nail down a boundary that expert readers will check for. Bleichenbacher's attack is an RSA PKCS #1 v1.5 oracle -- a different primitive with different arithmetic. It is the conceptual ancestor of the CBC padding-oracle class "in spirit," but it is never itself a CBC padding oracle [@bleichenbacher1998].Calling Bleichenbacher "the first CBC padding oracle" is a common and consequential error. His target is RSA public-key encryption; the CBC class is symmetric. The shared idea -- a structural validity verdict on attacker-chosen ciphertext leaks the plaintext -- is what makes him the ancestor, not the mechanism. The distinction matters because the family tree has two branches, and confusing them muddles the fix.

In an adaptive chosen-ciphertext attack, the adversary submits ciphertexts of its choosing and learns something from the receiver's reaction to each one. A scheme is IND-CCA2 secure only if those reactions leak nothing that helps distinguish or recover plaintext. A padding oracle is precisely a receiver whose reaction leaks -- so it is a live, deployed IND-CCA2 break, the security notion this series defines in Part 1.

The whole subject lives inside that definition. If a receiver's response to a ciphertext it did not create tells the attacker anything, the game is already lost -- the only question is how expensive the win is.

Bleichenbacher's oracle never died; it changed clothes. **DROWN** (2016) revived it by using a server's SSLv2 support to attack modern TLS [@drown_attack2016]. **ROBOT** (2017 to 2018) found the same PKCS #1 v1.5 oracle live in load balancers and TLS stacks from major vendors, nearly two decades on [@robot_2018]. And the **Marvin Attack** (2023) showed the timing variant still breaks RSA implementations "previously thought immune" [@marvin_attack2023]. All three are RSA-side breaks -- a different primitive from the CBC story told here -- and they appear only as this signpost so nobody mistakes them for CBC oracles. The lesson each one re-teaches is the same: a validity verdict on attacker-chosen input is a decryption oracle, whatever the cipher.

Four years after Bleichenbacher, Serge Vaudenay carried the idea across the aisle from public-key to symmetric cryptography. In "Security Flaws Induced by CBC Padding," presented at EUROCRYPT 2002, he showed that a receiver which decrypts a CBC ciphertext and reveals whether the padding is valid becomes a plaintext-recovery oracle against SSL, IPSEC, and WTLS [@vaudenay2002]. This is the founding result of the class -- the moment "confidentiality without integrity" was shown to be, in the general case, a decryption oracle waiting to be asked.

The object it manipulates had arrived on schedule: PKCS #7 padding, the append-n-bytes-each-equal-to-n scheme, was standardized as RFC 2315 in the same era, so the manipulable surface and the attack template appeared together [@rfc2315]. Vaudenay's procedure is documented in cryptography's standard texts as the canonical illustration of chosen-ciphertext insecurity [@katz_lindell_imc].

timeline title Padding oracles, 1998 to 2022 1998 : Bleichenbacher RSA PKCS number 1 oracle 2000 : Bellare-Namprempre composition theorem 2002 : Vaudenay CBC padding oracle 2003 : Canvel timing oracle vs TLS 2010 : ASP.NET break by Rizzo and Duong 2013 : Lucky Thirteen statistical timing 2014 : POODLE and RFC 7366 Encrypt-then-MAC 2016 : CVE-2016-2107, the fix re-creates the oracle 2018 : TLS 1.3 removes CBC, mandates AEAD 2022 : BCP 195 recommends against CBC

Vaudenay's real contribution was noticing that CBC makes the symmetric version cleaner than Bleichenbacher's RSA original: flip a byte, watch the verdict, recover a byte. To believe that -- and to earn the right to use it on every later break -- you have to see the arithmetic. It is simpler than it sounds, and once you see it you cannot un-see it in any decrypt-then-check system you review.

3. The Atom: Vaudenay's Oracle, Worked Byte by Byte

Everything in this article is one move, performed once here and then reused by every named break with only the channel changed. Derive it in full and the rest of the piece can move fast. There are three steps: understand the padding, understand the lever, then watch the recovery.

Step one: three padding formats, disambiguated once

Block ciphers operate on whole blocks, so a message that does not fill the last block must be padded, and the padding must be self-describing so the receiver can strip it. PKCS #7 is the canonical scheme.

To pad a message to a block boundary, append `n` bytes, each equal to the value `n`. Need three bytes of padding? Append `03 03 03`. Need one? Append `01`. If the message is already block-aligned, append a *full extra block* of padding (for a 16-byte AES block, sixteen bytes of `10`). To unpad, read the final byte `n`, verify that the last `n` bytes all equal `n`, and strip them. Standardized in RFC 2315 [@rfc2315].

Here is the trap that catches expert readers, so disambiguate it now and never again: not every named attack operates on literal PKCS #7 bytes. Three formats matter, and mitigations for one do not automatically cover another.

PKCS #7 (RFC 2315) requires every pad byte to equal the pad length [@rfc2315]. TLS 1.0 through 1.2 use a PKCS #7-like scheme where every pad byte equals length - 1, and -- this detail will return with Lucky Thirteen -- the record is MAC'd, then padded, then encrypted [@rfc5246]. SSL 3.0 is the dangerous outlier: its pad bytes are arbitrary, and only the final length byte is constrained, so there is effectively no padding content to check at all [@rfc6101].

Padding format	Pad-byte rule	What the receiver checks	Break that targets it
PKCS #7 (RFC 2315)	Append `n` bytes each equal to `n`	Length byte and every pad byte	Vaudenay's canonical oracle
TLS 1.0 to 1.2 (RFC 5246)	Every pad byte equals `length - 1`; MAC then pad then encrypt	Length and pad bytes, after decrypt	Lucky Thirteen
SSL 3.0 (RFC 6101)	Pad bytes arbitrary; only the final length byte constrained	Length byte only; pad bytes unchecked	POODLE

The DES-era ancestor is PKCS #5, re-published as RFC 8018, which is the same scheme fixed at an 8-byte block; PKCS #7 generalizes it to any block size up to 255 [@rfc8018]. The two names describe one idea, which is why you see both in old code.

That single table is why "just make the padding check uniform" was never a complete fix -- it says nothing about SSL 3.0, where there is no pad content to make uniform.

Step two: CBC malleability, the lever

In CBC decryption, each plaintext block is $P_i = D_k(C_i) \oplus C_{i-1}$: decrypt the current ciphertext block with the block cipher, then XOR the previous ciphertext block. Because that XOR is the last step, an attacker who flips a bit in $C_{i-1}$ deterministically flips the *same* bit in $P_i$ -- steering the plaintext without any knowledge of the key. Part 5 derives this in full; here it is the lever the oracle pulls. flowchart TD Ci["Target ciphertext block Ct"] --> Dk["Block cipher decryption Dk"] Dk --> Inter["Intermediate block, equals Dk of Ct"] Cprev["Previous ciphertext block, attacker controls it"] --> XORnode(("XOR")) Inter --> XORnode XORnode --> Pt["Recovered plaintext block Pt"] Attacker["Attacker flips byte j of the previous block"] -.-> Cprev Attacker -.-> Result["Byte j of Pt flips by the same amount, no key needed"]

Hold the two pieces together: the receiver will tell you whether a decrypted block has valid padding, and you can steer any byte of that decrypted block by editing the block in front of it. Those two facts are a decryption oracle.

Step three: the recovery, last byte first

Take a target ciphertext block $C_t$ whose plaintext you want. Prepend a block $C'$ that you fully control, and ask the receiver to decrypt the pair. The receiver computes an intermediate block $I = D_k(C_t)$ and returns the plaintext $P = I \oplus C'$, then checks its padding. You do not know $I$, but you can search for it one byte at a time.

Fix your attention on the last byte. Vary $C'$'s last byte over all 256 possible values and watch the verdict. For exactly one value, the decrypted last byte becomes 0x01, which is valid single-byte padding, and the receiver accepts. At that instant you know that $I[\text{last}] \oplus C'[\text{last}] = \texttt{0x01}$, so the intermediate byte is $I[\text{last}] = C'[\text{last}] \oplus \texttt{0x01}$. XOR that against the real previous ciphertext byte and you have recovered a true plaintext byte -- and AES was never touched.

One honest wrinkle hides inside "about 128 guesses." A guess can occasionally produce valid longer padding by luck -- for instance if the plaintext already ended in 0x02, a crafted byte could yield 02 02. So the careful attacker perturbs the second-to-last byte to confirm the intended 01 interpretation. That rare double-check is why the average is ~128 rather than a clean 128, and why worst-case is 256.

To peel the next byte, target two-byte padding: set the known last byte to decrypt to 0x02 (you can, because you now know its intermediate), and brute-force the second-to-last byte until the receiver sees 02 02. March inward -- 03 03 03, then 04 04 04 04 -- and a full block falls. The cost is about 128 guesses per byte on average and 256 in the worst case [@vaudenay2002].

sequenceDiagram participant A as Attacker participant O as Oracle receiver Note over A,O: Goal, learn the last byte of target block Ct A->>O: Send chosen block Cprime, then Ct O->>O: Decrypt, inspect last-byte padding O-->>A: invalid padding Note over A: Increment last byte of Cprime, retry A->>O: The value making the last plaintext byte 0x01 O->>O: Padding parses as one valid byte O-->>A: valid padding Note over A,O: Intermediate byte is that guess XOR 0x01 Note over A: True plaintext byte is intermediate XOR real previous byte

Run the atom yourself. The simulation below models the oracle over a fixed intermediate block -- no real cipher, so you can watch the one-in-256 accept that leaks a byte.

{` // A toy padding oracle over a fixed 16-byte "intermediate" block. // No real crypto: we model I = D_k(C_t) as a known array so you can watch // the 1-in-256 accept that leaks one plaintext byte. const BLOCK = 16;

// Pretend these are the secret intermediate bytes I = D_k(C_t). const intermediate = [0x8a,0x2f,0x11,0x77,0x4c,0x93,0xe0,0x05, 0xbb,0x6d,0x19,0xa4,0x3c,0xf8,0x52,0x7e]; // The real previous-ciphertext block (known to the attacker). const realPrev = [0x01,0x23,0x45,0x67,0x89,0xab,0xcd,0xef, 0xfe,0xdc,0xba,0x98,0x76,0x54,0x32,0x10];

// Oracle: is the last decrypted byte valid 0x01 padding? function oracle(cprime) { const lastPlain = intermediate[BLOCK-1] ^ cprime[BLOCK-1]; return lastPlain === 0x01; // the single leaked bit }

// Attack: brute-force the last byte of a controlled block. let guesses = 0; const cprime = new Array(BLOCK).fill(0); for (let g = 0; g < 256; g++) { guesses++; cprime[BLOCK-1] = g; if (oracle(cprime)) { const intByte = g ^ 0x01; // I[last] = guess XOR 0x01 const plainByte = intByte ^ realPrev[BLOCK-1]; console.log("Accepted after " + guesses + " guesses"); console.log("Recovered intermediate byte: 0x" + intByte.toString(16)); console.log("Recovered plaintext byte: 0x" + plainByte.toString(16)); break; } } `}

Key idea: One reliable accept/reject bit on attacker-chosen ciphertext, plus CBC's malleability, is a complete decryption function -- about 128 guesses per byte, and the key is never touched. Every named break in the rest of this article is that same atom, with only the channel that carries the bit changed.

That is Aha number one, and it dismantles the mental model most engineers start with. AES-256's strength was never the variable. The variable was what the receiver was willing to say about a ciphertext it had not authenticated. Before moving on, one point of vocabulary, because it changes how you diagnose the bug.

Note: A padding oracle is an attack class -- a side channel against a construction (CBC-mode encryption composed with a MAC), not a weakness in a primitive. The block cipher (AES) and the MAC (HMAC) are the primitives, and they are doing exactly what they promise. The oracle lives in how they are composed and in what the receiver reveals. Say "attack class" and "construction," never "the padding-oracle primitive."

The atom needs exactly one thing from the receiver: a distinguishable answer to "was the padding valid?" Vaudenay read that answer off a loud error message. The next fifteen years are the story of the field muffling that answer, one channel at a time -- and the same bit escaping through the next-quietest one every single time.

4. One Distinguisher, Four Quieter Channels

The atom never changes. What changes is how the accept/reject bit is observed -- and each time the field silences one channel, the bit re-emerges through a quieter one. Here is the entire failure catalog as one descending staircase, with POODLE branching off to the side.

Channel one -- the loud error message (Vaudenay 2002, ASP.NET 2010). The first receivers simply returned a distinct "padding error," trivially observable. Vaudenay read it straight off the response, and eight years later Rizzo and Duong read it off differing HTTP responses from ASP.NET applications, recovering authentication tickets and web.config at scale [@rizzo_duong_woot2010] [@cve_2010_3332]. The obvious countermeasure: return one indistinguishable error for both padding failures and data failures. That closes the loudest channel and opens the next.

Channel two -- coarse timing (Canvel et al. 2003). Once OpenSSL returned the same bad_record_mac alert for padding and MAC failures, Brice Canvel, Alain Hiltgen, Serge Vaudenay, and Martin Vuagnoux showed the verdict still leaked through when the alert arrived: a receiver that accepted the padding went on to compute the MAC, while one that rejected padding could bail early, and the resulting millisecond gap reconstituted the oracle [@canvel2003]. They intercepted a password over a live OpenSSL TLS channel. This is the first concrete demonstration of the pattern that organizes the whole subject. The standards response, TLS 1.1 (RFC 4346), mandated uniform alert handling and explicit per-record initialization vectors [@rfc4346]. The countermeasure: make the decryption path constant-time -- compute the MAC even on padding failure so both paths take equal time.

Channel three -- statistical timing, Lucky Thirteen (AlFardan and Paterson, 2013). This is the break that proved constant-time is the hard problem, and it is worth binding tightly to the thesis, because it is not merely "a timing attack." TLS uses MAC-then-encrypt with a specific receiver order: decrypt, strip the padding, then run HMAC over what remains. The trouble is that "what remains" has a length that depends on how many bytes the receiver treated as padding -- and HMAC's running time depends on that length, because the hash compression function runs one extra time at certain length thresholds. So the attacker's guess about the padding changes the MAC-computation time by a few tens of CPU cycles [@lucky13_2013].

A comparison (or, more broadly, a code path) is constant-time when its running time does not depend on secret data or on how far into the data a difference occurs. A tag check that returns early on the first mismatched byte leaks *where* the mismatch is; a constant-time check XORs all bytes and inspects the accumulated difference once. Lucky Thirteen forced constant-time unpadding-and-MAC on the whole industry, and CVE-2016-2107 shows how easily a hand-written fast path reintroduces the oracle -- there, through a missing length check that produced a distinguishable alert rather than a timing gap.

Nadhem AlFardan and Kenneth Paterson amplified that sub-microsecond difference statistically across the network, recovering a full plaintext block in about $2^{23}$ TLS sessions, dropping to roughly $2^{13}$ sessions per byte with favorable positioning, across OpenSSL, GnuTLS, PolarSSL, and more (CVE-2013-0169) [@lucky13_2013] [@cve_2013_0169]. Bind it to the ordering: MAC-then-encrypt forces a length-dependent MAC, so the timing leak is a property of the order of operations, not a stray implementation slip.The name "Lucky Thirteen" comes from the 13 bytes TLS feeds into the HMAC before the record body: a 5-byte TLS record header plus an 8-byte sequence number. Their alignment against the 64-byte hash-compression boundary is exactly what opens the timing gap. A number that sounds whimsical is really a byte-counting accident. The next countermeasure was obvious and genuinely hard: make the MAC and the unpadding constant-time.

Channel four -- unchecked structure, POODLE (Moller, Duong, and Kotowicz 2014). Here the staircase forks into a parallel branch. SSL 3.0's pad bytes are arbitrary by specification -- only the final length byte is constrained -- so there is no padding check to harden, no message to unify, no timing to flatten [@rfc6101]. An attacker who maneuvers a target byte into the last position of a block learns it from MAC pass or fail alone, needing neither an error message nor a timing measurement, at an expected cost of 256 SSL 3.0 requests per byte [@poodle_writeup] [@cve_2014_3566]. The name expands to Padding Oracle On Downgraded Legacy Encryption, and this is where a persistent misconception must be corrected.POODLE's downgrade is the enabler, not the bug. The downgrade only forces a modern client back onto vulnerable SSL 3.0; the vulnerability is the unchecked pad. The proof is TLS-POODLE (CVE-2014-8730), which hit TLS stacks that copied SSL 3.0's lax padding check and works with no downgrade at all [@cve_2014_8730]. Frame POODLE as a padding oracle first, a downgrade second. Google's write-up and the accompanying announcement documented the mechanism and effort in full [@poodle_writeup] [@google_poodle_blog]. Because there is no check to make uniform, the only fix is to remove SSL 3.0, and CBC, from the wire entirely.

Channel five -- the oracle the fix re-created (CVE-2016-2107, 2016). This is the single clearest proof of the thesis. OpenSSL's AES-NI assembly fast path, written to make the Lucky Thirteen countermeasure constant-time, mishandled a length check -- and re-opened a padding oracle. It was found with the TLS-Attacker fuzzing methodology [@somorovsky_fuzzing2016], and the National Vulnerability Database records the cause in words worth quoting exactly.

This vulnerability [CVE-2016-2107] exists because of an incorrect fix for CVE-2013-0169.

The constant-time patch for Lucky Thirteen re-created the very oracle it was written to close, and OpenSSL shipped the repair in 1.0.2h and 1.0.1t [@cve_2016_2107] [@openssl_secadv_20160503]. It did not travel alone. Amazon's s2n library added a Lucky Thirteen countermeasure that still leaked, revived as Lucky Microseconds by Martin Albrecht and Kenneth Paterson -- and the randomized delays s2n had added as masking were part of the problem [@lucky_microseconds2016].

Then, in 2019, Craig Young's Zombie POODLE and GOLDENDOODLE and a large Internet scan by Robert Merget and colleagues found CBC padding oracles still live in 1.83% of the Alexa Top Million, distinguishable by the content of server responses with no precise timing required at all [@merget2019] [@qualys_zombie_poodle2019].

Zombie POODLE is an invalid-padding, valid-MAC oracle; GOLDENDOODLE is the mirror image, a valid-padding, invalid-MAC oracle. Different verdicts, same atom.

Incident	Year	Leak channel	Root cause	Primary source
Vaudenay	2002	Distinct padding error	MtE-CBC observable branch	[@vaudenay2002]
Canvel et al.	2003	Coarse timing	MAC computed vs skipped	[@canvel2003]
ASP.NET (Rizzo, Duong)	2010	Distinct HTTP error	Padding vs data error revealed	[@rizzo_duong_woot2010] [@cve_2010_3332]
Lucky Thirteen	2013	Statistical timing	Strip-then-MAC length dependence	[@lucky13_2013] [@cve_2013_0169]
POODLE	2014	MAC pass or fail on shifted byte	SSL 3.0 unchecked padding	[@poodle_writeup] [@cve_2014_3566]
TLS-POODLE	2014	Same, no downgrade	TLS stacks copying the lax check	[@cve_2014_8730]
CVE-2016-2107	2016	Distinguishable alert (bad_record_mac vs record_overflow)	Constant-time fix slipped a length check	[@cve_2016_2107]
Zombie POODLE, GOLDENDOODLE	2019	Content differences in responses	Deployed CBC-HMAC long tail, 1.83%	[@merget2019] [@qualys_zombie_poodle2019]

Note: Never return a distinct "bad padding" error, and never let padding validity change a branch or the timing of the response. Any distinguishable decryption outcome on attacker-chosen ciphertext -- an error string, a millisecond, a TCP reset, a difference in response content -- is a padding oracle. The channel does not matter; the observability does.

One clarification sharpens the definition by contrast. BEAST (2011) is often filed next to these breaks, but it is not a padding oracle: it is a predictable-initialization-vector, chosen-plaintext attack on CBC [@beast_2011], and it belongs to the IV story of Part 2 and Part 5, not here.The tell is the direction of information flow. A padding oracle recovers unknown plaintext from the receiver's verdict on the attacker's ciphertext. BEAST confirms guessed plaintext by exploiting a predictable IV. Different precondition, different fix -- naming it here only sharpens what a padding oracle is.

Five generations, five channels, one bit. Every fix silenced the loudest remaining leak, and every fix was beaten by the next-quietest -- including a fix that became its own oracle. Whack-a-mole is not a strategy; it is a symptom. And the symptom points at a diagnosis the field had actually proved correct two years before Vaudenay's attack, and simply had not deployed.

5. The Bug Is the Order, Not the Padding

Stop looking at the padding. A padding oracle is not a padding bug; it is the consequence of checking padding on data you have not authenticated. Change what you check first, and the oracle has nothing to answer. To see why, you need the piece the attack has been quietly relying on: the MAC, and the three ways to combine it with encryption.

A MAC is a keyed tag that proves a message is authentic and unmodified: only a holder of the secret key can produce a tag that verifies. HMAC is the deployed instance. A valid MAC on a ciphertext means the ciphertext is genuine -- it came from someone with the key, and nothing tampered with it. Part 3 covers HMAC's structure; here the point is simply *when* you check it.

In 2000, Mihir Bellare and Chanathip Namprempre formalized the three "generic composition" ways to bolt a MAC onto an encryption scheme and proved exactly what each one buys [@bellare_namprempre2000]. Each maps cleanly onto a real protocol.

Compute the MAC over the *plaintext*, then encrypt the plaintext, MAC, and padding together. On receipt the order is forced: decrypt, strip padding, *then* verify the MAC. Because the receiver must decrypt and unpad before it can check authenticity, the padding verdict is observable by construction. This is SSL and TLS's original choice -- and the reason SSL/TLS, and only SSL/TLS, became a fifteen-year catalog of padding oracles. Encrypt the plaintext, then compute the MAC over the *ciphertext* (and the IV), and transmit ciphertext plus tag. On receipt, verify the tag *first*; decrypt only if it passes. A ciphertext the attacker altered fails the MAC and is discarded before any padding logic runs -- so there is no padding verdict to leak, through any channel. This is IPsec ESP's design and the shape RFC 7366 retrofits onto TLS.

The third sibling, encrypt-and-MAC, tags the plaintext and sends the tag alongside the ciphertext; SSH chose it. It still forces decryption before verification, and because the tag is over the plaintext it can leak plaintext equality, so it is no cure [@bellare_kohno_namprempre_ssh2002].

flowchart TD subgraph MtE["MAC-then-encrypt (SSL and TLS)"] M1["Decrypt"] --> M2["Strip padding"] --> M3["Verify MAC"] end subgraph EnM["Encrypt-and-MAC (SSH)"] E1["Decrypt"] --> E2["Verify MAC over plaintext"] end subgraph EtM["Encrypt-then-MAC (IPsec ESP)"] T1["Verify MAC over IV and ciphertext"] --> T2["Decrypt"] --> T3["Strip padding"] end

Look at where the MAC check sits. In the first two, unauthenticated ciphertext reaches the decrypt-and-parse machinery before anyone has proven it genuine. In the third, a forged ciphertext dies at the door.

Composition	MAC covers	Receiver order	IND-CCA (generic)	INT-CTXT (generic)	Protocol
MAC-then-encrypt	Plaintext	Decrypt, unpad, verify	Not guaranteed	No	SSL and TLS
Encrypt-and-MAC	Plaintext	Decrypt, verify	No	No	SSH
Encrypt-then-MAC	Ciphertext and IV	Verify, decrypt, unpad	Yes	Yes	IPsec ESP

Now the theorem, stated precisely. Encrypt-then-MAC, composed from an IND-CPA encryption scheme and a strongly unforgeable MAC (SUF-CMA), generically attains both IND-CCA and integrity of ciphertexts -- the strongest guarantees of the three -- while MAC-then-encrypt and encrypt-and-MAC do not generically reach integrity of ciphertexts [@bellare_namprempre2000]. Strong unforgeability is the load-bearing word: with only ordinary unforgeability, a second valid tag on the same ciphertext is a fresh accepted ciphertext, and the guarantee weakens to integrity of plaintexts. In practice the qualifier is free, because HMAC is strongly unforgeable, so the deployed guarantee is exactly as stated. That is the whole game: a construction with integrity of ciphertexts rejects any forged ciphertext before decryption, so a padding oracle cannot form.

One honest caveat, because the sloppy version of this claim is wrong. Hugo Krawczyk proved in 2001 that MAC-then-encrypt is secure when the encryption is CBC or counter mode, under stated conditions [@krawczyk2001]. So MtE is not "always broken."Krawczyk's result is conditional: MtE with CBC or CTR is provably secure in the model, which means Canvel, Lucky Thirteen, and POODLE are implementation, side-channel, and underspecified-padding failures -- not refutations of a theorem. The precise statement guards against the overreach "MtE is broken." What is true is subtler and more useful: MtE is conditionally provable and practically fragile, because it leaves unauthenticated ciphertext reaching the parser, and holding the model's assumptions in compiled code is the hard part [@krawczyk2001]. The practitioner's takeaway is not "the theorem was wrong" but "the theorem's assumptions are unreasonably hard to preserve in real code -- so change the order and stop needing them." The practitioner literature has said as much for years [@ferguson_schneier_kohno_ce].

Watch the difference on a single tampered ciphertext. The MtE receiver leaks a distinguishable outcome; the EtM receiver returns one indistinguishable failure before it parses anything.

{` // Two toy receivers over the SAME tampered ciphertext. // No real crypto: "decrypt" and "macOk" are stand-ins so you can see // what each receiver reveals. function decrypt(ct) { return { paddingValid: false }; } // tampering broke the pad function macOk(ct) { return ct.tag === "authentic"; } // forged tag fails

const tampered = { tag: "forged" };

// MAC-then-encrypt: decrypt and check padding BEFORE the MAC. function mteReceive(ct) { const p = decrypt(ct); if (!p.paddingValid) return "PADDING_ERROR"; // leaks the padding verdict if (!macOk(ct)) return "MAC_ERROR"; return "OK"; }

// Encrypt-then-MAC: verify the MAC FIRST; never touch padding on forgeries. function etmReceive(ct) { if (!macOk(ct)) return "FAIL"; // one indistinguishable outcome const p = decrypt(ct); if (!p.paddingValid) return "FAIL"; return "OK"; }

console.log("MtE says:", mteReceive(tampered)); // PADDING_ERROR (distinguishable) console.log("EtM says:", etmReceive(tampered)); // FAIL (nothing to learn) `}

Key idea: The bug is the order, not the padding. Silencing channels is whack-a-mole; checking authenticity first -- Encrypt-then-MAC, and its successor AEAD -- removes the precondition that unauthenticated ciphertext ever reaches a padding check, so the oracle has nothing left to answer.

That is Aha number two, and it reorganizes the entire catalog. Every generation before Encrypt-then-MAC silenced a channel while leaving the precondition intact; the last two remove the precondition itself.

flowchart TD G1["Gen 1, distinct padding error"] --> G2["Gen 2, unified alert"] G2 --> G3["Gen 3, constant-time MtE"] G3 --> G4["Gen 4, Encrypt-then-MAC"] G4 --> G5["Gen 5, AEAD"] G1 -.-> S["Silenced a channel, precondition intact"] G2 -.-> S G3 -.-> S G4 -.-> R["Removed the precondition, authenticity first"] G5 -.-> R The three compositions were not tried in sequence; they were chosen in *parallel* by different protocols and coexisted for years. MAC-then-encrypt went into SSL and TLS, encrypt-and-MAC into SSH, Encrypt-then-MAC into IPsec ESP [@bellare_namprempre2000]. Only the MtE branch became the fifteen-year catalog. IPsec's Encrypt-then-MAC branch was structurally immune from the start, which is the quiet punchline of the whole story: the fix TLS reached for in 2014 was, in effect, "become IPsec" -- the negotiated `encrypt_then_mac` extension of RFC 7366 [@rfc7366].

AEAD (RFC 5116) is Encrypt-then-MAC's standardized successor: one primitive, authenticity intrinsic, no composition knob to misset [@rfc5116]. The theorem was published in 2000. Vaudenay's attack landed in 2002. And the fix did not reach the deployed TLS base until 2014 to 2018. The rest of this article is what "check authenticity first" looks like when it finally shipped at Internet scale -- and why, even now, the class is not entirely dead.

6. The State of the Art: Closed by Construction

The modern answer is boring, and that is exactly the point. Use a primitive where a padding oracle cannot exist, because authenticity is checked first and there is no block padding at all.

An AEAD primitive takes a key, a nonce, a plaintext, and optional associated data, and produces a ciphertext with an integral authentication tag. Decryption verifies the tag as part of the operation and returns *nothing* -- a single indistinguishable failure -- if it does not match. There is no separate MAC to order, and for the stream-based AEADs in wide use there is no block padding to be oracular. Standardized as an interface in RFC 5116 [@rfc5116].

Two AEADs carry nearly all modern traffic. AES-GCM is the default where AES hardware exists: it is AES in counter mode for encryption, plus a GHASH tag over the ciphertext and associated data, verified before any plaintext is released. ChaCha20-Poly1305 is the default where AES hardware does not exist -- Google deployed it in Chrome on Android because it runs about three times faster than AES-GCM on devices without AES acceleration, and it is constant-time in portable software by design [@rfc8439] [@google_chacha_blog2014]. Both are counter-mode stream constructions, and that structural fact, not the label "AEAD," is why they are immune.A stream construction has no block padding at all -- the keystream is simply truncated to the plaintext length. So the object Vaudenay's atom acts on, a padded final block whose validity the receiver checks, does not exist. There is no surface. This is why "GCM has a tag, could it have a padding oracle?" answers itself: there is nothing to pad.

Then the standards removed the choice. TLS 1.3 (RFC 8446, 2018) removes CBC cipher suites entirely and mandates AEAD, and QUIC inherits that record layer, so a conformant modern stack cannot express the padding-oracle precondition [@rfc8446].

For the deployed base that could not jump straight to 1.3, RFC 7366 (2014) retrofits Encrypt-then-MAC onto TLS 1.0 through 1.2 as a negotiated extension -- extension type 22 -- citing Bellare-Namprempre and Krawczyk by name as the reason MtE "is no longer regarded as secure" [@rfc7366]. And BCP 195 (RFC 9325, 2022) codifies the operational rule: prefer TLS 1.3, prefer AEAD suites on 1.2, and recommend against CBC [@rfc9325].

Method	How it works	What it buys	Status 2024 to 2026
AES-GCM	AES-CTR plus GHASH tag, verified first	No padding surface, fastest with AES hardware	Default (TLS 1.3, QUIC)
ChaCha20-Poly1305	ChaCha20 plus Poly1305, verified first	Constant-time in software, ~3x without AES-NI	Co-default, WireGuard, OpenSSH
Encrypt-then-MAC (RFC 7366)	MAC over IV and ciphertext, verified first	Structural fix for legacy CBC	Compose-by-hand rule
Constant-time CBC-HMAC	Harden the MtE order in place	Nothing new; fragile	Deprecated (BCP 195)
Misuse-resistant, committing AEAD	AES-GCM-SIV, committing wrappers	Nonce-repeat safety, key commitment	Ascending, niche
Padding-oracle detection	TLS-Attacker, padcheck scanners	Measures residual exposure	Active tooling

The honest status has two levels. At the primitive level the class is closed: TLS 1.3 has no CBC-HMAC record layer, so it has no padding oracle. But CBC-HMAC survives in the long tail -- legacy TLS, VPN appliances, load balancers, IoT stacks, and home-grown application crypto -- which is why padding oracles are still discovered, in 1.83% of the top million as recently as the 2019 scan, exploitable without precise timing [@merget2019].

Note: Treat any distinguishable decryption error on a CBC-HMAC endpoint as a reportable finding, not a performance bug to smooth over. The lesson of five generations is that the construction, not any single leak, is the problem: CBC-HMAC is the thing to retire. Every hour spent hardening its constant-time behavior is an hour not spent migrating to AEAD, which needs no such hardening.

"Use AEAD" is the entire answer for greenfield code. But engineers inherit constraints -- a mode they cannot change, a library without AEAD, a protocol mid-migration -- so the real question is not "what is best" but "what are my options, ranked, and exactly when does each apply?"

7. How to Not Have a Padding Oracle, Ranked

There are three ways to keep a padding oracle out of your system, in strict order of durability -- and the ranking is a theorem, not a taste. The yardstick is one question: is authenticity checked before anything parses the plaintext?

First choice: AEAD. Authenticity is intrinsic, there is no padding, and there are zero composition knobs for an implementer to misset. This is the default, full stop. Its own frontier is a genuinely different problem, not a padding successor: nonce reuse under AES-GCM is catastrophic -- the "forbidden attack," demonstrated against real TLS and IPMI stacks by Böck et al. (WOOT '16) [@bock_nonce_woot2016] -- and standard AEAD is not key-committing, so one ciphertext can be made to open to different valid plaintexts under different keys [@albertini_committing2022]. Those are addressed by AES-GCM-SIV for nonce-misuse resistance and by committing AEAD constructions, which the CFRG's property vocabulary now names formally [@rfc8452] [@rfc9771]. Treat that as a one-line signpost, not a reason to hesitate on AEAD.

Second choice: Encrypt-then-MAC by hand. Correct, but only if you get three things right -- an independent MAC key (never the encryption key), coverage of both the IV and the ciphertext, and a constant-time tag comparison performed before any decrypt or unpad. That is the RFC 7366 shape [@rfc7366]. Three knobs an implementer can misset is precisely the argument for reaching for AEAD's zero knobs whenever you can.

Third choice, and only if forced: constant-time MtE / CBC-HMAC. This is the "make the existing order safe in place" path, and it is the cautionary option to retire, not to choose. Lucky Thirteen, Lucky Microseconds, and CVE-2016-2107 are the evidence that it fights the construction: MtE keeps unauthenticated ciphertext reaching the parser, so the distinguisher re-emerges through whatever the CPU or the compiler leaves open [@lucky13_2013] [@cve_2016_2107].

Property	AES-GCM	ChaCha20-Poly1305	Encrypt-then-MAC (CBC-HMAC)	Constant-time MtE (CBC-HMAC)	AES-GCM-SIV
Authenticity checked first?	Yes (intrinsic)	Yes (intrinsic)	Yes (verify tag first)	No (decrypt and unpad first)	Yes (intrinsic)
Padding-oracle surface	None (stream)	None (stream)	None (rejected pre-unpad)	Full (precondition survives)	None (stream)
Composition knobs to misset	0	0	3	Many	0
Nonce or IV reuse behavior	Catastrophic	Catastrophic	IV must be unpredictable	IV must be unpredictable	Graceful (equality leak only)
Status 2024 to 2026	Active default	Active co-default	Compose-by-hand rule	Deprecated (BCP 195)	Ascending, niche

Only the first two options remove the precondition; the third merely silences the loudest channel. That is the whole ranking, and it maps onto the parallel history from the last section: AEAD and Encrypt-then-MAC are what IPsec effectively had from the start, while constant-time MtE is the fifteen-year attempt to make SSL/TLS's original order safe without changing it.

So the durable options all share one property: they refuse to let unauthenticated ciphertext reach a parser. That raises a deeper question a careful reader should now be asking. Why is one accept/reject bit enough to be fatal in the first place -- and is Encrypt-then-MAC provably enough to stop it, or just empirically better so far?

8. Why a Bit Is Enough, and Why the Fix Is a Theorem

Two boundaries frame the whole subject: how little leakage the attacker needs, which is frighteningly little, and how hard the defender's guarantee actually is, which is a proof rather than a hope.

The lower bound: one reliable bit suffices. A single accept/reject bit per query, combined with CBC's malleability, recovers plaintext at about 128 guesses per byte, and the cipher is never attacked [@vaudenay2002]. The consequence is a hard limit on defense that every engineer should internalize: there is no "leak too small to matter," only "too noisy to measure cheaply." The bit is information-theoretically sufficient; the only variable is how many queries it takes to read it reliably.

Note: Lucky Thirteen turned a difference of a few tens of CPU cycles -- invisible to a human, buried in network jitter -- into full plaintext recovery by amplifying it statistically over many sessions [@lucky13_2013]. If a one-bit distinguisher exists at all, "make it quieter" only raises the query count; it never reaches zero. The only defense that reduces the leak to nothing is removing the precondition, so no bit is ever produced.

The impossibility in the middle. An unauthenticated, malleable mode is provably not IND-CCA2. CBC without integrity is a decryption oracle by construction, so no amount of error-message hygiene or timing equalization can rescue MAC-then-encrypt CBC against a determined side-channel adversary. The impossibility lives in the precondition itself -- in letting a malleable ciphertext be decrypted before it is authenticated -- which is why the deployed padding oracle is exactly the IND-CCA2 break this series defines in Part 1.

The upper bound: the fix is a hard theorem. The best achievable defense is a proved one.

A scheme has integrity of ciphertexts when an adversary, even after seeing many valid ciphertexts, cannot produce *any* new ciphertext the receiver accepts as valid. This is the property that closes the oracle: if every forged ciphertext is rejected before decryption, the receiver never reveals a padding verdict on attacker-chosen input. Encrypt-then-MAC and AEAD provide it; MAC-then-encrypt does not, generically.

Encrypt-then-MAC with an IND-CPA cipher and a strongly unforgeable MAC (SUF-CMA) generically attains IND-CCA plus integrity of ciphertexts, so a forged ciphertext is rejected with overwhelming probability before decryption -- the oracle is closed by theorem, not by patch [@bellare_namprempre2000]. Krawczyk marks the honest boundary of the alternative: MAC-then-encrypt is conditionally provable for CBC and counter mode, so the real-world MtE breaks are implementation and side-channel failures, not refutations of a theorem -- but Encrypt-then-MAC needs no such conditions [@krawczyk2001].

Key idea: At the level of construction design there is no gap. The lower bound -- any observable padding verdict yields byte-at-a-time decryption -- is met by removing the precondition, and the upper bound -- reject forgeries before decryption, IND-CCA plus INT-CTXT -- is achieved by Encrypt-then-MAC and AEAD. Best-possible and best-achieved coincide. Every remaining gap is implementation and deployment, not mathematics.

That is Aha number three, and it is a humbler note than it first sounds. If the design problem is provably solved, why do scanners still find these oracles in production, and why did a correct construction get re-broken by its own patch? Because "solved on paper" and "solved in a compiled binary on a specific CPU, deployed to a billion devices" are different sentences -- and the space between them is where the class still lives.

9. Where Padding Oracles Still Live

The construction-level problem is closed; the class is not. Here are four places the 2002 bug remains exploitable, and one frontier that would end the whack-a-mole.

Constant-time is a moving target. Even with the correct construction, a specific compiled binary on a specific CPU can reintroduce a secret-dependent timing difference through branch prediction, cache behavior, or an assembly fast path -- and the countermeasure can also slip in a plainer way. CVE-2016-2107 is the canonical evidence: OpenSSL's AES-NI fast path, written to make the fix constant-time, dropped a length check and re-created the oracle -- leaking not through timing but through a distinguishable alert (bad_record_mac versus record_overflow), which is why TLS-Attacker found it by clustering responses rather than measuring cycles [@cve_2016_2107]. The strongest partial answer is formally verified, secret-independent cryptographic code -- HACL* and EverCrypt prove memory safety, functional correctness, and secret independence, and ship in Firefox and NSS [@hacl_star]. But that covers primitives, not yet whole record layers end to end, so the verification frontier is real.

The deployed CBC-HMAC long tail. Legacy TLS, VPN appliances, load balancers, and IoT stacks that cannot move to TLS 1.3 keep MAC-then-encrypt CBC alive. The 2019 scan put the exposure at 1.83% of the top million, exploitable without precise timing, and the population shrinks year over year rather than vanishing -- a trend the SSL Pulse dashboard tracks [@merget2019] [@ssl_pulse].

Application-layer oracles. This is the part TLS 1.3 does not reach, and it deserves its own aside because it is where the next decade of these bugs will be found.

Tibor Jager and Juraj Somorovsky broke the W3C XML Encryption standard with the same oracle, decrypting XML in SOAP and web-services stacks by watching how an endpoint reacted to manipulated ciphertext -- proof that the mechanism operates far outside TLS [@jager_somorovsky_xmlenc2011]. The application layer is full of the same shape: JWE and JOSE `A128CBC-HS256` tokens, encrypted cookies, and ViewState-style tokens reproduce the 2002 bug, often with no MAC at all, above TLS where network scanners cannot see them. A separate but adjacent hazard, Efail, exploited a CBC *malleability gadget* in S/MIME and a CFB gadget in OpenPGP to exfiltrate plaintext directly -- not a padding-verdict oracle, but the same "unauthenticated malleable ciphertext" precondition wearing different clothes [@efail2018].

Format and parse oracles beyond padding. Generalize once more: any observable post-decryption structural verdict -- a JSON parse success, a protobuf validity check, a decompression outcome -- is a padding oracle by another name whenever it acts on unauthenticated ciphertext. The padding was only ever the first structure anyone checked. Jager and Somorovsky already proved the mechanism outside padding entirely [@jager_somorovsky_xmlenc2011], and systematic detection of "decrypt-then-parse" leaks is not yet automated the way TLS padding-oracle scanning now is.

AEAD's own frontier. The successor primitive has two sharp edges of its own -- catastrophic nonce reuse in AES-GCM [@bock_nonce_woot2016] and the lack of key commitment [@albertini_committing2022] -- which matter most in exactly the places large systems trip: nonce management across many distributed senders, and multi-key or multi-recipient contexts like JWT and envelope encryption. Both are addressed separately today, by AES-GCM-SIV for misuse resistance and by committing constructions that RFC 9771's vocabulary now specifies, but no single ubiquitous primitive yet delivers misuse-resistant and committing and fast and online at once [@rfc8452] [@rfc9771]. That convergence is the open engineering target, and it is a different problem from the padding oracle, not a continuation of it.

Every one of these is the same sentence wearing new clothes: unauthenticated, attacker-chosen input reaching a check whose verdict is observable. Which means the practical guide almost writes itself -- it is the thesis made operational.

10. Decision Rules: Use X With These Params in Case Y

Everything above collapses into a short decision procedure and a shorter list of nevers.

flowchart TD Start["Need authenticated encryption"] --> Q1{"Greenfield design?"} Q1 -->|"Yes"| Q2{"AES hardware present?"} Q2 -->|"Yes"| GCM["AES-GCM, unique 96-bit nonce"] Q2 -->|"No"| ChaCha["ChaCha20-Poly1305"] Q1 -->|"No, stuck with CBC"| Q3{"Can you retire CBC?"} Q3 -->|"Yes"| GCM Q3 -->|"No"| EtM["Encrypt-then-MAC, RFC 7366, verify first"] GCM --> Q4{"Nonce uniqueness hard?"} Q4 -->|"Yes"| SIV["AES-GCM-SIV"] Q4 -->|"No"| Done["Ship it"]

The rules, in order:

Default to a vetted AEAD, from a library you cannot misuse. Use AES-GCM with a unique 96-bit nonce and fewer than $2^{32}$ messages per key where the CPU has AES-NI; use ChaCha20-Poly1305 where there is no AES hardware, or when you want constant-time behavior from portable software [@rfc8439]. In application code, reach for libsodium's secretbox or Google Tink rather than raw primitives, and prefer any API where you cannot express "decrypt, then check" -- the safest libraries never hand you plaintext before verification.
If nonce uniqueness is hard to guarantee across many independent senders or under snapshot and rollback risk, use AES-GCM-SIV, so a nonce repeat degrades gracefully instead of catastrophically [@rfc8452].
If a ciphertext may be opened under more than one key -- JWT and JOSE, envelope encryption, abuse reporting -- use a committing AEAD [@albertini_committing2022] [@rfc9771].
If you must compose by hand, use Encrypt-then-MAC: encrypt, then compute the MAC over the IV and ciphertext with an independent MAC key, and verify the tag in constant time before you decrypt or unpad [@rfc7366].
On a legacy TLS 1.2 CBC deployment you cannot yet retire, negotiate RFC 7366 Encrypt-then-MAC, prefer AEAD suites, and follow BCP 195 [@rfc9325].
Never return a distinct "bad padding" error; never branch or vary timing on padding validity; never decrypt before verifying; never reuse the encryption key as the MAC key; never leave the IV out of the MAC; and never ship SSL 3.0 or non-RFC-7366 CBC.

If you are stuck at the fourth rule, the shape below is the reference. It is dependency-free and non-cryptographic on purpose: copy the order of operations, not the stand-in primitives.

{` // Reference SHAPE for a correct Encrypt-then-MAC open(). // constantTimeEqual, hmac, cbcDecrypt, removePkcs7 are stand-ins, NOT real crypto. function constantTimeEqual(a, b) { if (a.length !== b.length) return false; let diff = 0; for (let i = 0; i < a.length; i++) diff |= a[i] ^ b[i]; return diff === 0; // no early exit: time is independent of where they differ }

function open(kEnc, kMac, iv, ciphertext, tag) { // 1. Authenticate FIRST, over IV concat ciphertext, in constant time. const expected = hmac(kMac, iv.concat(ciphertext)); if (!constantTimeEqual(tag, expected)) return "FAIL"; // one outcome, always

// 2. Only authentic ciphertext ever reaches decryption and unpadding. const padded = cbcDecrypt(kEnc, iv, ciphertext); const plain = removePkcs7(padded); return plain === null ? "FAIL" : plain; // same FAIL either way }

// Stand-ins so the snippet runs (NOT secure): function hmac(k, data) { return data.map((b) => (b ^ k) & 0xff); } function cbcDecrypt(k, iv, c) { return c; } function removePkcs7(p) { return p; }

console.log(open(1, 2, [9, 9], [4, 5, 6], [7, 7, 7])); // FAIL: forged tag rejected first `}

Every misuse in real code maps one-to-one onto a named break in the catalog. That mapping is the practical guide as a grid.

Misuse seen in code	The named break it reproduces	The fix
Distinct "bad padding" error	Vaudenay, ASP.NET	Verify authenticity first
Non-constant-time unpad and MAC	Lucky Thirteen	AEAD, or constant-time EtM
Unchecked pad bytes	POODLE	Retire SSL 3.0 and CBC
AES-NI fast-path length slip	CVE-2016-2107	Verified constant-time, or AEAD
Verifying the MAC after decrypting	The whole class	Encrypt-then-MAC ordering
Nonce reuse under AES-GCM	The forbidden attack	Unique nonces, or AES-GCM-SIV
App-layer encrypt with no MAC	JWE and cookie oracles	A committing AEAD

Note: Use a vetted AEAD: AES-GCM with unique 96-bit nonces and the under-$2^{32}$-messages-per-key cap where AES hardware exists, or ChaCha20-Poly1305 where it does not. If you must keep CBC, negotiate RFC 7366 Encrypt-then-MAC with an independent MAC key and a constant-time verify performed first. Never ship SSL 3.0 or non-RFC-7366 CBC. That is the entire checklist, because the lesson is a single sentence.

Detection is cheap enough to wire into a pipeline, and you should, because content-difference oracles need no timing rig to find [@merget2019].

Point an open-source padding-oracle scanner at your own hosts. Craig Young's `padcheck` and the TLS-Attacker project's `TLS-Padding-Oracles` both probe for the invalid-padding-versus-invalid-MAC content differences that Zombie POODLE and GOLDENDOODLE exploit, and they run without a precise timing setup [@padcheck] [@tls_padding_oracles]. A clean result on a CBC endpoint is reassuring; any distinguishable response is a reportable finding, not a tuning opportunity.

The checklist is short because the lesson is one sentence. Before restating it, clear the confident, wrong sentences that keep this bug alive in design meetings.

11. Misconceptions, Named and Corrected

The padding oracle survives mostly because a handful of confident, wrong sentences keep getting said in design meetings. Here they are, corrected.

The strength of AES is irrelevant to this attack, because the key is never attacked. A padding oracle recovers plaintext from the receiver's error handling -- a distinguishable answer to "was the padding valid?" -- combined with CBC's malleability [@vaudenay2002]. The ASP.NET break recovered authentication tickets and `web.config` with AES-256 fully intact [@rizzo_duong_woot2010]. "The cipher is strong" and "the system is secure" are different claims. No. The same accept/reject bit re-emerges through the next-quietest channel. Once the error message was unified, it leaked through coarse timing (Canvel et al., 2003) and then through statistical timing under unified errors (Lucky Thirteen, 2013), and through unchecked structure entirely (POODLE, 2014) [@canvel2003] [@lucky13_2013] [@poodle_writeup]. Silencing one channel just moves the leak; only removing the precondition closes it. No -- and the overstatement matters. Krawczyk proved MAC-then-encrypt conditionally secure for CBC and counter mode, so the real-world breaks are implementation, side-channel, and underspecified-padding failures, not refutations of a theorem [@krawczyk2001]. What is true is that MtE is *fragile in practice*: it leaves unauthenticated ciphertext reaching the parser, so constant-time MtE is a fight against the construction. The fix is to change the order, not to declare a theorem false. It is a padding oracle; the downgrade is only the enabler that forces a client onto vulnerable SSL 3.0, whose pad bytes are unchecked by specification [@poodle_writeup] [@rfc6101]. The proof is TLS-POODLE (CVE-2014-8730), the same oracle against TLS stacks that copied the lax check, with no downgrade at all [@cve_2014_8730]. Frame POODLE as a padding oracle first, a downgrade second. No. Bleichenbacher (1998) is an RSA PKCS #1 v1.5 oracle -- a different primitive with different arithmetic [@bleichenbacher1998]. Vaudenay (2002) is the first *CBC* instance [@vaudenay2002]. Bleichenbacher is the ancestor "in spirit," because he first showed that a structural validity verdict is a decryption oracle, but calling his attack a CBC padding oracle confuses two branches of the family tree. No. AES-GCM and ChaCha20-Poly1305 are counter-mode stream constructions with no block padding, and they verify the authentication tag before releasing any plaintext, so the Vaudenay atom has no surface to act on [@rfc8439]. GCM's own hazard is nonce reuse, which is a different problem -- the "forbidden attack" -- not a padding oracle [@bock_nonce_woot2016]. Only if authenticity is checked *first* and the unpadding is *also* constant-time. A constant-time compare on a MAC you verify *after* decrypting still leaves the padding check reachable, which is the whole class -- and a hand-written fast path can reintroduce the oracle anyway, as CVE-2016-2107 did, through a missing length check observable as a distinguishable alert rather than a timing leak [@cve_2016_2107]. The safe pattern is verify-then-decrypt, or an AEAD that gives you no other option.

Every correction points at the same root: the padding was never the bug. Time to say the sentence the whole article was built to earn.

Decrypt, Then Confess

Return to that ASP.NET server in September 2010. AES-256 intact. The key never touched, never even approached. And the plaintext -- authentication tickets, web.config, the site's master secrets -- gone, one byte at a time, because the server answered a question it should never have been asked before it authenticated the ciphertext [@rizzo_duong_woot2010].

Line up the catalog and the shape is unmistakable. Bleichenbacher, Vaudenay, Canvel, ASP.NET, Lucky Thirteen, POODLE, CVE-2016-2107, Zombie POODLE: in every case the cipher did exactly what it promised, and the variable was always the order of operations, leaking through a quieter channel each time it was silenced. A loud error became coarse timing became statistical timing became unchecked structure became a fix that re-created its own oracle. Five generations chased the bit; the bit kept escaping, because the precondition -- unauthenticated, malleable ciphertext reaching a padding check -- was never removed.

The resolution the field finally deployed is a single move: verify authenticity first. Encrypt-then-MAC proves it -- IND-CCA plus integrity of ciphertexts, the strongest of the three generic compositions, published two years before Vaudenay's attack [@bellare_namprempre2000]. AEAD ships it as one primitive with no knob to misset, and TLS 1.3 makes it the only option a conformant stack can express [@rfc8446].

This mirrors the running lesson of the series: Part 1's IND-CCA2 adversary is not a chalkboard abstraction but the exact adversary that walked out of that ASP.NET server, and Part 5's warning that confidentiality is not integrity is precisely the gap a padding oracle drives through.

When a ciphertext you did not create arrives, what does your receiver reveal about it before it has proven the ciphertext authentic? Encrypt-then-MAC and AEAD are the discipline of making the answer nothing.

Carry that one question into every protocol you design or review. Drop Lucky Thirteen onto it, drop POODLE onto it, drop the next application-layer JWE oracle onto it: each is a non-empty answer, and the fix is always the same shape. The cipher was never the weak link, and no future cipher will be. That is why this is Part 6 of a field guide to protocol design, not a chapter on block ciphers.

Secure Against Whom? The Security Definitions Every Protocol Designer Needs

noreply@paragmali.com (Parag Mali) — Sat, 04 Jul 2026 15:17:50 GMT

A security definition is a contract with two clauses: a **goal** (what the adversary must fail to do) bound to an **adversary model** (what the adversary is allowed to do). Nothing is ever "secure" in the abstract, only secure *relative to that contract*. Most real-world breaks are not weak math. They are a construction that met a *weaker* target than its deployment's adversary demanded: Bleichenbacher and POODLE handed attackers a decryption oracle, AES-GCM nonce reuse handed them a repeated nonce, invisible salamanders handed them a second key. This guide builds the vocabulary generation by generation, from IND-CPA and IND-CCA2 through EUF-CMA, SUF-CMA, AEAD, and committing encryption, plus the two proof settings (random oracle versus standard model) and the reduction that ties goals to hard problems. The operational lesson is one habit: **state your deployment's adversary model first, pick the matching target second, and choose the primitive last.**

1. The Primitive Was Fine

In 1998, Daniel Bleichenbacher did not break RSA. Factoring stayed hard, the keys stayed secret, and the math was exactly as sound the day after his attack as the day before. Yet with about a million carefully malformed messages, he could recover the secrets of an SSL session, because the server, trying to be helpful, answered one question every time it rejected a ciphertext: was the padding valid? [@bleichenbacher1998]

That single leaked bit is a decryption oracle. RSA as used in SSL wrapped the session key in PKCS#1 v1.5 padding, and a server that reports "bad padding" differently from "bad key" tells the attacker, ciphertext by ciphertext, whether a chosen value decrypts into the padded structure. Bleichenbacher showed that roughly $2^{20}$ adaptive queries turn that trickle into the full plaintext [@bleichenbacher1998].

The tempting reading is "an RSA bug." It is not. Nineteen years later, in 2017, researchers pointed the identical attack at modern TLS stacks and load balancers, and it still worked against products from several major vendors [@robot_2018] [@robot_site]. They called it ROBOT, the Return Of Bleichenbacher's Oracle Threat. The industry had spent two decades patching individual symptoms, tightening one timing difference here, one error message there, without ever changing what was actually wrong.

Note: ROBOT is the clearest evidence in this article that the failure is structural, not incidental. Every point fix removed one instance of the oracle. None of them changed the fact that PKCS#1 v1.5 encryption was deployed where an attacker can observe decryption behavior, and it was never built to survive that. You cannot patch your way out of the wrong security target. You have to change the target [@robot_2018].

So what, exactly, does "secure" mean, and secure against whom? That question is not rhetorical. It is the entire discipline. A construction is secure only against a specified adversary trying to achieve a specified goal, and the moment the deployment hands that adversary a capability the specification never modeled, the guarantee evaporates no matter how sound the underlying math.

Key idea: A security definition is a contract with two clauses: a goal (what the adversary must fail to achieve) bound to an adversary model (what the adversary is allowed to do). "Secure" without a named adversary model is not a weak claim. It is not a claim at all.

This guide makes you fluent in that contract. We build the vocabulary the way the field built it, one generation at a time, and prove the thesis with evidence: a catalog of named, dated breaks in which a provably fine primitive sank a real protocol because the environment granted an adversary the proof never covered. Bleichenbacher and ROBOT are the first entry.

By the end you will read any construction as goal plus adversary model plus proof setting, and see why that one habit would have prevented the entire catalog. For the deployment story of how Windows TLS stacks rotated ciphers over twenty years, see SChannel and the twenty-year algorithm.

A construction is never secure in the abstract. It is secure only relative to a named adversary model.

To see why a correct primitive was not enough, we have to go back to a time when "secure" had no definition at all.

2. Before "Secure" Meant Anything

For most of history, a cipher was "secure" because nobody important had broken it yet. That is survivorship bias wearing the costume of a guarantee. It tells you nothing about the attacks nobody has tried, and it cannot distinguish a strong design from one that simply has not attracted a competent adversary. Every classical cipher, from simple substitution to Vigenère to Enigma, was "secure" by this standard right up until the morning it was not.

The one durable gain from that era is Kerckhoffs's principle: assume the adversary knows every detail of your algorithm, and put all the secrecy in the key.Auguste Kerckhoffs stated this in 1883 [@kerckhoffs1883]. It is why "security through obscurity" is a slur, and why modern designs publish their algorithms and keep only keys secret. But note what it still does not supply: a definition of what the attacker must fail to do. It is a rule about where to hide the secret, not a definition of success. It leaves "secure" undefined.

That gap survived the single most important idea in the field's modern history. In 1976, Whitfield Diffie and Martin Hellman opened public-key cryptography, showing that two strangers could agree on a secret over a channel an eavesdropper fully controls, and sketching digital signatures along the way [@dh1976]. It was a genuine discontinuity. But it delivered mechanisms, not a definition of what an attacker must fail to achieve. "Secure" still meant "we tried and could not break it."

You cannot prove a scheme meets a goal you never wrote down. So the founding question of modern cryptography is not "how do we encrypt?" It is "what must the attacker fail at, and what is the attacker allowed to do while failing?" Shafi Goldwasser and Silvio Micali answered it in 1982 and 1984 with semantic security: a ciphertext must leak nothing computationally useful about its plaintext, not even a single predicate, to any efficient adversary who already knows partial information [@gm1984] [@gm1982stoc].

They also gave an equivalent, more usable form, indistinguishability, which we meet as IND-CPA in the next section. The award committee agreed the shift mattered: Goldwasser and Micali received the 2012 Turing Award for it [@turing2012].

Two words in that definition carry enormous weight. "Efficient" means the adversary runs in probabilistic polynomial time; we do not defend against an attacker with unbounded computation, because for public-key cryptography that is hopeless. "Negligible" means the adversary's edge over guessing shrinks faster than any inverse polynomial in the security parameter.Probabilistic polynomial time (PPT) and negligible functions are the two dials of computational security. A function is negligible if it eventually falls below $1/n^c$ for every constant $c$. Together they let us say "no realistic adversary wins by more than a vanishing margin" instead of the impossible "no adversary ever wins." Security stops being a binary property of an algorithm and becomes a statement about a game between a challenger and a bounded adversary.

This article numbers the generations of definitions by *idea*, not by calendar. Confidentiality against a passive attacker comes first, then against an active one, then integrity, then their union, then commitment. The field did not invent them in that order: unforgeability for signatures (1988) was defined *before* adaptive chosen-ciphertext security (1991). Where the dates cross, we flag it. The dependency that matters here is conceptual, not temporal.

Before we build the first game, there is one loose end. An airtight, provably unbreakable definition of secrecy was already on the books, and it predated all of this by decades. Why did the field not simply use Shannon's?

3. The Perfect Cipher We Cannot Afford

Claude Shannon gave cryptography a mathematically perfect definition of secrecy in 1949, and the one-time pad achieves it, unconditionally, forever [@shannon1949]. Not "we think it is hard to break." Provably impossible to break, even against an adversary with infinite computing power.

An encryption scheme has perfect secrecy if the ciphertext is statistically independent of the plaintext: observing the ciphertext leaves the adversary's probability distribution over possible messages exactly where it started. Formally, $\Pr[M = m \mid C = c] = \Pr[M = m]$ for every message and ciphertext. No amount of computation helps, because the information is simply not present in the ciphertext.

The one-time pad reaches this bar with almost embarrassing simplicity. Take a key $k$ that is uniformly random and as long as the message $m$, and send $c = m \oplus k$. Because each key bit is a fresh coin flip, every plaintext of that length is an equally plausible explanation of the ciphertext, so the ciphertext reveals nothing. Decryption is the same XOR again.

So why is the internet not built on one-time pads? Shannon proved the catch in the same paper: any perfectly secret cipher needs at least as much key entropy as message entropy, $H(K) \ge H(M)$ [@shannon1949]. The key must be as long as everything you will ever send, and it does nothing to solve the problem of getting that key to the other party in the first place. Two strangers who have never met cannot pre-share gigabytes of secret pad, which is exactly the situation every TLS handshake faces.

There are two more ceilings, and they matter for the rest of this guide. The first is that the perfection is contingent on the pad being used once. Reuse a pad across two messages and $c_1 \oplus c_2 = m_1 \oplus m_2$, which leaks the XOR of the plaintexts and, with a little language structure, both messages.This is not hypothetical. The VENONA project decrypted Soviet cables for years precisely because the Soviets reused one-time-pad key material under wartime production pressure [@venona]. "Never reuse the key" is a lesson written in decades of intercepted traffic, and it returns almost verbatim in the AES-GCM nonce story later.

The second ceiling is quieter and more important for our thesis. The one-time pad offers zero integrity. It is maximally malleable: flip any bit of the ciphertext and you flip exactly the corresponding bit of the plaintext, and the receiver has no way to notice. Perfect secrecy says nothing whatsoever about whether a message arrived unmodified.

Note: This is one of the most expensive misconceptions in applied cryptography, so meet it early. Confidentiality (nobody can read it) and integrity (nobody can change it undetected) are different goals. A scheme can have perfect confidentiality and no integrity at all, as the one-time pad demonstrates. Assuming encryption implies integrity is the root cause of an entire class of breaks we catalog in Generation 4.

The way out of the key-length ceiling is to relax the adversary. Shannon's model grants the attacker unlimited computation. If we instead demand only that a computationally bounded adversary fail, we can hope for short keys, public keys, and eventually integrity, provided we state precisely what "fail" means. That relaxation is the whole computational project the previous section set up.

The relaxation bites immediately, and its first bite is instructive. Consider deterministic "textbook" RSA, where a message always encrypts to the same ciphertext under a given public key. An adversary who suspects the plaintext is one of two values does not need to break RSA at all. The public key lets anyone encrypt, so the attacker encrypts both candidates and compares them to the challenge ciphertext. Whichever matches is the answer.

Goldwasser and Micali turned this into a theorem: no deterministic public-key scheme can be semantically secure [@gm1984]. Randomization is not good hygiene; it is mandatory, a consequence of the definition itself. That randomness has to come from somewhere trustworthy, its own deep subject that a later part of this series takes up.

With the passive adversary finally pinned down as a game, we can write the first modern definition precisely, and then watch an attacker walk straight through its one blind spot.

4. Five Generations, One Recurring Story

The next four decades of cryptography follow one pattern so regularly that you can predict the next entry. A definition fixes a goal and an adversary model. A deployment then hands the attacker a capability the model never granted, whether a decryption oracle, a repeated nonce, or a second valid key. A named, dated break follows. And the field responds by writing a stronger definition that pulls the new capability inside the game. Watch for that shape. By Generation 3 you will feel it coming.

timeline title From perfect secrecy to committing encryption 1949 : Shannon perfect secrecy, unbounded adversary 1976 : Diffie-Hellman public-key crypto, no definition of success 1984 : Goldwasser-Micali semantic security and IND-CPA 1988 : Goldwasser-Micali-Rivest unforgeability, EUF-CMA 1990 to 1991 : Naor-Yung CCA1, Rackoff-Simon CCA2, Dolev-Dwork-Naor non-malleability 1993 : Bellare-Rogaway random oracle model 1998 : Bleichenbacher break, relations map, Cramer-Shoup, ROM uninstantiability 2000 to 2006 : Bellare-Namprempre AE, Rogaway AEAD, SIV nonce-misuse resistance 2018 to 2021 : Invisible salamanders and partitioning oracles, committing AE 2024 : ML-KEM in FIPS 203, NIST Accordion effort

Generation 1: confidentiality against a passive adversary (IND-CPA, 1984)

Goldwasser and Micali's indistinguishability game is the founding contract of modern cryptography, and it is worth stating exactly.

A scheme is IND-CPA secure if no efficient adversary can tell which of two self-chosen, equal-length messages was encrypted, even while free to encrypt anything else it likes. The adversary submits $m_0$ and $m_1$; the challenger flips a secret bit $b$ and returns the challenge $\mathrm{Enc}(m_b)$; the adversary outputs a guess $b'$. Its advantage is $\lvert \Pr[b' = b] - \tfrac{1}{2} \rvert$, and security means that advantage stays negligible. This is the indistinguishability form of semantic security.

In the public-key setting the adversary already holds the public key, so its chosen-plaintext power is free: it can encrypt anything it wants. That is exactly what dooms determinism. If encryption is a plain function, the adversary encrypts $m_0$ itself and checks whether the result equals the challenge.

{` // A toy "deterministic" encryption: the same message always maps to the same ciphertext. function encryptDeterministic(pk, m) { // stand-in for textbook RSA: a fixed, public, invertible transform return "CT[" + pk + ":" + m + "]"; }

// The IND-CPA adversary, given only the public key and the challenge ciphertext. function adversary(pk, challenge) { const m0 = "attack at dawn"; const m1 = "retreat at dusk"; // The public key lets the adversary encrypt candidates itself. const guessForM0 = encryptDeterministic(pk, m0); // Re-encrypt m0 and compare. No key recovery, no math broken. return (challenge === guessForM0) ? "m0" : "m1"; }

const pk = "PUBLIC-KEY"; const challengerSecretlyChose = "attack at dawn"; // this is m0 const challenge = encryptDeterministic(pk, challengerSecretlyChose); console.log("Adversary guesses:", adversary(pk, challenge)); console.log("Advantage over guessing: 1/2, the maximum. Deterministic PKE cannot be IND-CPA."); `}

The adversary wins every time, with the maximal advantage of one half. The fix, forced by the definition rather than by taste, is randomization: a good scheme encrypts the same message to freshly random-looking ciphertexts, so re-encrypting a guess tells the attacker nothing.

IND-CPA is the right target for exactly one adversary: a passive one, who watches ciphertexts go by but never learns how the receiver reacts to them. That is its blind spot. Real servers decrypt attacker-supplied ciphertexts and do something observable: return an error, take a branch, spend measurable time. Each reaction is a decryption oracle the IND-CPA game never handed out.

Bleichenbacher's 1998 attack, from the opening of this article, is precisely this failure: an IND-CPA-grade target deployed where the adversary can watch decryption behavior [@bleichenbacher1998]. To survive that attacker, the definition itself must give the adversary a decryption oracle.

Generation 2: confidentiality against an active adversary (IND-CCA1, IND-CCA2, non-malleability, 1990 to 1998)

The strengthening arrived in two steps. Naor and Yung (1990) gave the adversary a decryption oracle it may query only before seeing the challenge, the "lunchtime attack" or CCA1, and built the first provably chosen-ciphertext-secure scheme using double encryption plus a zero-knowledge proof that both ciphertexts hold the same plaintext [@ny1990]. A year later Rackoff and Simon (1991) removed the timing restriction: the oracle is available before and after the challenge, forbidding only a query on the challenge ciphertext itself. That is IND-CCA2, still the gold-standard confidentiality target today [@rs1991].

IND-CCA2 is the IND-CPA game plus a decryption oracle the adversary may call adaptively both before and after receiving the challenge $c^{*}$, with the single restriction that it may not ask for the decryption of $c^{*}$ itself. A scheme that meets it withstands exactly the padding-oracle and reaction-attack environments that sink IND-CPA-only deployments. sequenceDiagram participant A as Adversary participant C as Challenger A->>C: Two equal-length messages m0 and m1 C->>C: Flip secret bit b, encrypt the chosen message C->>A: Challenge ciphertext c-star A-->>C: IND-CCA2 only, decrypt any ciphertext except c-star C-->>A: The corresponding plaintext A->>C: Final guess b-prime Note over A,C: Advantage measures how far a correct guess beats one half

Dolev, Dwork, and Naor (1991) added an orthogonal axis that turns out to matter just as much.

A scheme is non-malleable if, given a ciphertext of some message $m$, no efficient adversary can produce a ciphertext of a *meaningfully related* message such as $m+1$ or $2m$. Indistinguishability says the adversary learns nothing from a ciphertext; non-malleability says the adversary cannot *transform* it into a ciphertext of a related plaintext, which is a distinct, active threat such as raising a sealed bid by one dollar [@ddn1991].

By 1998 the notions had multiplied into a zoo, and Bellare, Desai, Pointcheval, and Rogaway mapped it. They proved every implication and separation among the goals of indistinguishability and non-malleability crossed with the attacks CPA, CCA1, and CCA2, and the headline result is that IND-CCA2 and non-malleability under CCA2 are the same property [@bdpr1998]. That equivalence is the reward of definition-first thinking: hit the single target IND-CCA2 and you get non-malleability with no separate proof.

Notice the chronology. Rackoff and Simon defined the adaptive oracle in 1991, seven years before Bleichenbacher showed a real SSL server being that oracle. The definition did not chase the break; it predicted the entire class of break. What was missing in 1998 was not the theory but the discipline of choosing the target the deployment demanded. And yet IND-CCA2, for all its strength, guarantees only confidentiality. It promises nothing about whether a message you can read arrived unmodified, or whether an attacker who cannot read it can still inject one the receiver will accept.

Generation 3: integrity as a first-class goal (EUF-CMA and SUF-CMA, 1988 onward)

Here the calendar folds back. Goldwasser, Micali, and Rivest defined unforgeability in 1988, three years before adaptive chosen-ciphertext security, by carrying the game-based, reduction-oriented definition style from secrecy to authenticity: the same challenger, oracle access, and negligible success bound, now applied to a forgery game rather than to indistinguishability [@gmr1988].

Give the adversary the verification key and a signing oracle it may query on any messages it chooses. The adversary wins if it outputs a valid signature on a message it never asked the oracle to sign. A signature or MAC scheme is EUF-CMA secure if every efficient adversary wins with only negligible probability. This is the target behind HMAC, RSA-PSS, ECDSA, and Ed25519.

There is a strictly stronger sibling that the deployment reality of the decade made important.

SUF-CMA changes only the winning condition: the adversary wins if it produces any valid message-signature *pair* the oracle never produced, including a brand-new signature on a message that was already signed. SUF-CMA therefore forbids the signature malleability that EUF-CMA tolerates. Every SUF-CMA scheme is EUF-CMA, but not the reverse [@katzlindell].

Why does the gap between them matter? Because EUF-CMA lets a third party take a valid signature and maul it into a different valid signature on the same message. Wherever a protocol treats a signature or ciphertext as a unique identifier, that malleability bites. Early Bitcoin is the textbook case: an attacker could re-encode an ECDSA signature, changing a transaction's identifier without invalidating it, which disrupted systems that assumed the identifier was fixed. MtGox famously halted withdrawals citing malleability, though the same analysis found it did not actually account for the exchange's lost funds [@decker2014]. That is exactly the attack SUF-CMA forbids and EUF-CMA permits.

A subtler cousin is verifying a signature without binding its context (which key, which algorithm, which audience), which invites cross-protocol confusion. For a real incident where a stolen signing key met permissive validation, see how Storm-0558 turned one signing key into forged tokens.

A MAC or signature protects a token. It is not, by itself, a secure channel. For that we need confidentiality and integrity together, composed in a way we can prove correct.

Generation 4: authenticated encryption (AE and AEAD, 2000 to 2006)

Practitioners had been bolting encryption and MACs together by instinct, and instinct chose badly. Bellare and Namprempre (2000) settled the matter with definitions and proofs [@bn2000].

INT-PTXT (plaintext integrity) means the adversary cannot force decryption to accept a plaintext that was never legitimately encrypted. INT-CTXT (ciphertext integrity), strictly stronger, means the adversary cannot produce *any* valid ciphertext the encryptor never output. INT-CTXT is what real channels want, because it rejects forged ciphertexts before they are ever decrypted.

Their verdict on the three ways to glue encryption to a MAC is one of the most consequential engineering results in the field: Encrypt-then-MAC (encrypt, then authenticate the ciphertext) generically delivers IND-CCA together with INT-CTXT, while MAC-then-Encrypt and Encrypt-and-MAC do not [@bn2000]. Order is not a detail. It is the difference between a secure channel and a broken one.

AEAD is a single combined target: confidentiality (IND-CPA) plus ciphertext integrity (INT-CTXT) over a nonce-based interface that takes a key, a nonce, associated data, and a message, and returns a ciphertext and a tag. The associated data (packet headers, sequence numbers, routing context) is authenticated but not encrypted. Rogaway named and formalized it in 2002, and RFC 5116 turned it into the deployable interface every modern channel uses.

Rogaway (2002) added the associated-data interface [@rogaway2002], McGrew's RFC 5116 (2008) standardized it as the API protocol designers actually call [@rfc5116], and Rogaway and Shrimpton (2006) defined the fallback for when nonces cannot be trusted [@rs2006siv].

A nonce-misuse-resistant scheme degrades gracefully when a nonce repeats: instead of collapsing, it leaks only whether two (nonce, associated data, message) triples were identical. The SIV construction achieves this by deriving the tag from the plaintext first, then using that tag as the encryption nonce. This is the guarantee behind AES-GCM-SIV.

Now the breaks, and they line up with the theory exactly. TLS chose MAC-then-Encrypt with CBC, the very order Bellare and Namprempre flagged, and decrypted before verifying. That handed attackers a padding-and-timing decryption oracle twice: Lucky Thirteen (2013) recovered plaintext from tiny timing differences in MAC and padding checks [@lucky13_2013] [@lucky13_site], and POODLE (2014) forced a downgrade to SSL 3.0, whose CBC padding is not checkably authenticated, then peeled secrets off byte by byte [@poodle_cve]. Both are wrong-composition-order failures wearing different clothes.

The second Gen-4 landmine is the nonce contract, and it is the most destructive single mistake in applied cryptography.

Note: Reuse one (key, nonce) pair in AES-GCM and you do not lose a little security, you lose all of it. GHASH evaluates a polynomial whose coefficients are the ciphertext blocks at the secret authentication key $H$, so two messages under one nonce cancel the block-cipher mask and leave a polynomial equation in $H$. The attacker factors that polynomial to recover $H$ and can then forge a valid tag on any message. This is Joux's "forbidden attack," a universal forgery rather than a slow leak [@joux_gcm]. VM clones, snapshot rollbacks, and stateless senders are the usual culprits.

Even without reuse, GCM has a hard ceiling.AES-GCM's standard nonce is 96 bits. With random nonces, birthday collisions on that nonce cap a single key at about $2^{32}$ messages, the bound NIST SP 800-38D fixes in section 8.3 to keep the collision probability negligible. A separate limit, the 32-bit block counter that the 96-bit nonce leaves inside the 128-bit block, caps any one message at about $2^{32}$ blocks (roughly 64 GiB). NIST warns that exceeding either cap can compromise both confidentiality and integrity [@sp800_38d]. The proof was always conditioned on unique nonces and a bounded message count; the environment routinely violates both.

Which surfaces the deepest omission of all. AE and AEAD guarantee that a ciphertext is unforgeable and hides its plaintext. They never required it to commit to the key that produced it.

Generation 5: committing encryption, binding a ciphertext to its key (2018 to 2021, still open)

An AEAD scheme is key-committing if a single ciphertext cannot be made to decrypt validly under two different keys. Stronger notions bind more of the input: context commitment binds the key, nonce, and associated data, while the strongest level also binds the message. Bellare and Hoang grade these from CMT-1 (key only) up to CMT-4, which commits to the entire input tuple of key, nonce, associated data, and message. It is a binding property, not a privacy property, and standard AEAD never required it.

The break that named the goal is vivid. For AES-GCM you can craft one ciphertext that decrypts to two different, meaningful plaintexts under two chosen keys, because its GHASH tag can be made to collide across keys.Dodis, Grubbs, Ristenpart, and Woodage called the hidden second message an "invisible salamander," after a test image they smuggled past Facebook's abuse-reporting checks. The playful name marks a serious result: a reported ciphertext could be made to "say" different things to sender, receiver, and moderator. That broke Facebook's encrypted-message franking, the mechanism that lets a recipient report abuse in a way a moderator can verify [@salamanders2018].

Three years later the same missing property was weaponized for a different goal. Len, Grubbs, and Ristenpart showed that a single ciphertext valid under many keys turns password guessing into a binary search: each query rules out half the candidate key space at once. These partitioning oracles sped online attacks against Shadowsocks proxies and reached into key-management and end-to-end-encrypted settings [@partitioning2021]. Bellare and Hoang formalized the graded commitment hierarchy and proved that committing to the key alone (CMT-1) does not imply committing to the full context (CMT-4), so partial fixes leave a real gap [@bh2022]; Menda and colleagues then demonstrated concrete context-discovery and commitment attacks that exploit that gap in real settings [@menda2023].

Generation 5 is not superseded. It is the live frontier, being written into standards right now, and we return to it in the state of the art.

That is five turns of one wheel. It is worth seeing the wheel itself.

flowchart TD A["A definition fixes a goal and an adversary model"] --> B["A deployment hands the attacker a capability outside that model"] B --> C{"Does the attack win inside the old game?"} C -->|"No, the game never granted that capability"| D["A named, dated break follows in the wild"] D --> E["The field writes a stronger definition that grants the capability"] E --> A

Key idea: Every arrow in that chain has the same shape. A definition names a goal and an adversary model; a deployment grants the attacker a capability outside that model; a dated break follows; a stronger definition absorbs the capability. Learning the definitions is learning to spot the next missing capability before an attacker does.

Two tables make the pattern concrete. The first is the failure catalog, where each row is a construction that met a weaker target than its environment demanded.

Break	Year	Construction	Capability the model ignored	Missing target	Lesson
Bleichenbacher, then ROBOT	1998, 2017	RSA PKCS#1 v1.5 encryption	Decryption and padding oracle	IND-CCA2	You cannot patch out a missing target
Lucky Thirteen	2013	TLS CBC, MAC-then-Encrypt	Timing decryption oracle	AEAD (Encrypt-then-MAC)	Composition order is provable, not a matter of taste
POODLE	2014	SSL 3.0 CBC, MAC-then-Encrypt	Padding oracle via forced downgrade	AEAD / IND-CCA2	The adversary model must include downgrade
AES-GCM nonce reuse	ongoing	AES-GCM AEAD	Repeated (key, nonce) pair	Nonce-misuse resistance	Unique nonces are a load-bearing assumption
Invisible salamanders	2018	AES-GCM message franking	A second valid key	Key commitment (CMT)	AEAD never promised one key per ciphertext
Partitioning oracles	2021	Non-committing AEAD	One ciphertext valid under many keys	Key commitment (CMT)	Missing commitment enables key and password search

The second table lays out the targets themselves, in order of increasing strength, so you can name any construction as a goal bound to an adversary model.

Target	Goal	Adversary model	Strength relation	Deployed instance
IND-CPA	Confidentiality	Passive, chosen-plaintext	Weakest confidentiality	Building block only
IND-CCA2	Confidentiality	Active, adaptive decryption oracle	Implies IND-CPA, equals NM-CCA2	ML-KEM, RSA-OAEP, Cramer-Shoup (standard-model reference)
EUF-CMA	Authenticity	Adaptive chosen-message	Base authenticity	HMAC, ECDSA, Ed25519
SUF-CMA	Authenticity	Adaptive chosen-message	Strictly stronger than EUF-CMA	Ed25519, HMAC
AEAD	Confidentiality and integrity	Active, nonce-respecting	Combines IND-CPA and INT-CTXT	AES-GCM, ChaCha20-Poly1305
Committing AE	Binds ciphertext to key and context	Active, multi-key	Strictly stronger than AEAD	AWS Encryption SDK, Accordion (pending)

Five times we have said a scheme "meets" a target. It is time to say what meets actually means, and why you should believe it.

5. What "Provably Secure" Actually Proves

We have been defining games. A game tells you what it means to win. It does not tell you that nobody can. So how do you prove a negative, that no efficient adversary wins, without enumerating every possible attack? The answer is the single idea that unifies everything in this guide: a proof by reduction.

To prove a scheme meets a target, assume some problem is hard (integer factoring, the decisional Diffie-Hellman problem, Module-LWE) or that a lower-level primitive is secure. Then exhibit an efficient algorithm, the reduction, that turns *any* adversary who wins the security game into a solver for that hard problem. If the problem really is hard, no such solver exists, so no such adversary exists either. Security becomes a conditional theorem: break the scheme and you have broken the assumption.

Read that structure carefully, because it is doing something subtle. It never claims the scheme is unbreakable. It claims something you can actually establish: that breaking the scheme is at least as hard as a problem the world's cryptanalysts have failed to crack for decades. The proof relocates all the risk onto one clearly labeled assumption, where everyone can study it. The hard problems themselves (factoring, discrete logarithms, lattice problems) are the subject of later parts of this series; here they are simply the anchors a reduction reaches for.

flowchart LR A["Efficient adversary A wins the security game"] --> R["Reduction R runs A as a black box"] R --> S["R becomes an algorithm that solves the hard problem"] S --> X["But the problem is assumed hard, so no such solver exists"] X --> Z["Therefore no efficient adversary A can exist"]

This is the only known way to make "secure" falsifiable, and it composes, which is what makes it practical. Bellare and Namprempre's result that IND-CPA plus INT-CTXT implies IND-CCA is itself a reduction you can bolt onto others: prove your encryption IND-CPA and your MAC strongly unforgeable, glue them Encrypt-then-MAC, and the channel's IND-CCA security follows with no fresh from-scratch proof [@bn2000] [@bonehshoup]. Large guarantees get assembled from small proven parts.

A security proof does not promise that nobody can break the scheme. It promises that breaking it is as hard as a problem we have collectively failed to solve for decades.

But a proof is only as good as two things: the assumption it rests on, and how tightly it reduces.

A reduction is tight if the solver it builds is almost as effective as the adversary it consumes, running in similar time with similar success probability. It is loose if it loses a factor, for instance a multiple of the number of queries or users. A reduction that loses a factor $L$ means a scheme advertised at $k$-bit security actually delivers only about $k - \log_2 L$ bits at the chosen parameters. Looseness is not academic; you pay it back in larger keys and slower handshakes.

Neal Koblitz and Alfred Menezes pressed exactly this point in their "Another Look" critique: many published reductions are loose, or rest on bespoke, barely-studied assumptions, and calling a scheme "provably secure" invites readers to hear "unbreakable" when the honest claim is much narrower [@km2007]. We take up their argument in full when we reach the limits. For now it is enough to know that the tightness of a proof is an operational number, not a footnote.

Key idea: "Provably secure" means conditionally secure: secure relative to a named hardness assumption and a named adversary model, and only as tightly as the reduction allows. It converts a vague hope into a precise, falsifiable claim whose single point of failure is written on the label. That is far more than folklore offers, and far less than "unbreakable."

This method is not a museum piece. It is the machine still producing the definitions that shipped last year. Here is what it built between 2024 and 2026.

6. The Definitions That Shipped: 2024 to 2026

A quantum-resistant standard published in 2024 is built directly on the 1984, 1991, and 1999 sequence: an IND-CPA scheme, upgraded to IND-CCA2, by a transform invented to plumb exactly that gap.

On August 13, 2024, NIST published FIPS 203, standardizing ML-KEM, a key-encapsulation mechanism whose security rests on the hardness of Module-LWE and which is, in the standard's own words, believed to be secure even against adversaries who possess a quantum computer [@fips203].

A KEM is the modern shape of public-key confidentiality. Rather than encrypting a chosen message, encapsulation generates a fresh random shared secret together with a ciphertext that carries it; decapsulation recovers the secret from the ciphertext using the private key. The shared secret then keys a symmetric AEAD channel. The target you want from a KEM is IND-CCA2, because an active network attacker can submit chosen ciphertexts to decapsulation.

ML-KEM reaches IND-CCA2 the way Fujisaki-Okamoto transforms do: start from an IND-CPA lattice scheme, then make decapsulation recompute and compare. It derives the encryption randomness deterministically from the message, re-encrypts on the way in, and on any ciphertext that does not re-encrypt exactly returns a pseudorandom key instead of the real one (implicit rejection), so a decapsulation failure is invisible to the caller [@fips203] [@fo1999]. That single move strips out the malleability an adaptive attacker would exploit, turning a passive-secure scheme into an active-secure one.

The transform's soundness in both the random-oracle and quantum-random-oracle settings is the subject of a careful modular analysis by Hofheinz, Hövelmanns, and Kiltz, which also shows the quantum bound is not tight [@hhk2017].The Quantum Random Oracle Model (QROM) lets the adversary query the idealized hash in superposition, which is what a real quantum attacker holding the hash's public code could do. Proving the FO transform secure in the QROM is harder than in the classical setting and currently costs a looser bound. The full story belongs to a later post-quantum installment of this series.

The price of the strong target is not CPU, it is bandwidth. Google reports that an ML-KEM key exchange transmits about 1 KB per peer against 32 bytes for X25519, an over-thirty-fold increase that splits the TLS ClientHello across packets and adds roughly 4 percent to median desktop handshake latency [@chrome2024].

That cost is being paid at scale regardless. Cloudflare reported that nearly 2 percent of all TLS 1.3 connections already used post-quantum key exchange in early 2024 [@cloudflare2024], Signal's PQXDH was the first large-scale deployment of post-quantum key establishment in messaging [@signal_pqxdh], and Apple's iMessage PQ3 layers ongoing ML-KEM rekeying on top for what it calls Level 3 security [@apple_pq3].

ML-KEM ships in *hybrid* mode, combining a classical key exchange such as X25519 with the post-quantum one so a break of either component alone is survivable. The driver is "harvest now, decrypt later": an adversary recording encrypted traffic today could decrypt it once a quantum computer arrives, so confidentiality that must outlive the next decade needs the post-quantum target now. The Windows-side rollout is covered in [the thirty-year migration that ships in a pip install](/blog/the-thirty-year-migration-ships-in-a-pip-install-how-post-qu) and [post-quantum cryptography on Windows](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati).

The same AEAD target ships in three deployed instances that differ not in what they guarantee but in the deployment reality they suit. All three hit AEAD; the discriminating axis is how they behave when a nonce repeats [@rfc8439] [@rfc8452] [@sp800_38d].

Property	AES-GCM	ChaCha20-Poly1305	AES-GCM-SIV
Target met	AEAD (IND-CPA + INT-CTXT)	AEAD	AEAD plus nonce-misuse resistance
Structure	Counter mode plus GHASH	ChaCha20 stream plus Poly1305	Tag derived from plaintext, then counter mode, via POLYVAL
Passes	One pass, online, parallelizable	One pass, online	Two passes, not online
Best hardware	AES-NI and carryless multiply	none needed, fast in software	AES-NI and carryless multiply
Nonce reuse	Catastrophic (Joux forgery)	Catastrophic (keystream reuse)	Graceful, leaks only equality of inputs
Per-key limit	about $2^{32}$ invocations at a 96-bit nonce	same nonce-uniqueness requirement	far higher tolerance
Key-committing	No	No	No
Best suited for	TLS and QUIC with AES hardware	mobile and embedded, no AES hardware	stateless senders, key wrap, uncertain nonces
Spec	NIST SP 800-38D	RFC 8439	RFC 8452

Note: Pick AES-256-GCM when you have AES hardware and can guarantee unique nonces. Pick ChaCha20-Poly1305 when you cannot count on AES hardware, as on many mobile and embedded targets [@rfc8439]. Pick AES-GCM-SIV when nonce uniqueness is at risk, for example stateless senders, key wrapping, or anything that can be cloned or rolled back [@rfc8452]. None of the three commits to its key, so add that property separately if you need it.

The newest target on this list, key commitment from Generation 5, is being written into standards as you read this. In May 2025 the IRTF's Crypto Forum Research Group published RFC 9771, which gives consensus, game-based names for Key Commitment and Full Commitment alongside related properties such as nonce hiding, multi-user security, and quantum security. A spec can finally name the property it needs instead of gesturing at it [@rfc9771].

NIST is scoping an actual mode. Its Accordion effort targets a tweakable, variable-input-length strong pseudorandom permutation with a reduction proof and key commitment as a stated requirement, laid out across NIST IR 8537 in 2024 [@ir8537], the requirements report NIST IR 8552 in April 2025 [@ir8552], and a pre-draft call for comments on SP 800-197A that proposes three modes (Acc128, Acc256, and a beyond-birthday variant) built from the HCTR2 technique [@sp800197a] [@hctr2] [@nist_news_accordion].

You do not have to wait for it: the AWS Encryption SDK already enforces key commitment through a commitment policy, a production deployment that predates any standard [@aws_esdk].

Why does commitment need a whole new mode rather than a bigger tag? Partly because a binding guarantee inherits the birthday bound: $n$-bit commitment security needs roughly a $2n$-bit commitment, about 256 bits for 128-bit security, so a standard 128-bit tag is undersized for the job [@bh2022]. And breaking commitment is a binding problem, which the sketch below shows is a weapon rather than a curiosity.

{` // Intuition only, not a real attack. A non-committing "AEAD" whose verifier // happens to accept a crafted ciphertext under MANY candidate keys. function accepts(candidateKey, craftedCiphertext) { // In a committing scheme this would be true for at most one key. // Here the attacker built a ciphertext valid for a whole set of keys. return craftedCiphertext.validKeys.includes(candidateKey); }

// The attacker packs "half the remaining candidates" into one ciphertext. function craftFor(keySubset) { return { validKeys: keySubset }; }

let candidates = []; for (let i = 0; i < 1024; i++) candidates.push("key#" + i);

let queries = 0; while (candidates.length > 1) { const half = candidates.slice(0, Math.floor(candidates.length / 2)); const ct = craftFor(half); queries++; // One online guess rules out half the space, committing or not. candidates = accepts(candidates[0], ct) ? half : candidates.slice(half.length); } console.log("Recovered key:", candidates[0], "in", queries, "online queries over 1024 candidates."); `}

Ten queries to search a thousand keys, because each ciphertext answers "is your key in this set?" A committing scheme makes that impossible: one ciphertext accepts under at most one key, so each guess can only ever eliminate a single candidate.

All of this, classical and post-quantum, symmetric and public-key, is proven in one of two settings, under one of two styles of definition. Which one you trust changes what the proof is worth.

7. Two Styles of Definition, Two Places to Prove Them

Two long-running tensions run underneath every definition so far, and neither is resolved. The first is how you state a goal. The second is where you prove it.

Everything up to this point has used indistinguishability games: define two worlds and demand that no efficient adversary can tell them apart. That style fits standalone primitives beautifully. But there is a second style, simulation-based (or real-versus-ideal) security, which asks a different question: is there a simulator that, with no access to the secrets, can produce a transcript indistinguishable from a real interaction? If so, the real protocol leaks nothing the ideal one would not, because anything the adversary learns it could have generated itself.

Simulation is the natural language for zero-knowledge proofs, secure multiparty computation, and composable settings, where the strongest framework is Universal Composability.Universal Composability, due to Ran Canetti [@canetti2001uc], proves a protocol secure even when arbitrarily many copies of it and other protocols run concurrently, by comparing the real execution to an ideal functionality. It is the strongest simulation-based framework, and the price of that strength is that UC-secure protocols are harder to build. We only point at it here. Simulation generally implies the matching indistinguishability notion but not the reverse, so the two are complementary lenses rather than rivals [@bonehshoup]. For these simulation-based definitions in deployed systems, see the age gate that does not know your age and direct anonymous attestation.

The second tension is the setting in which a proof lives, and it is the one most often misunderstood.

The random oracle model proves a scheme secure while treating a hash function as if it were a truly random function that everyone can query but nobody can predict. It is a *proof setting*, a modeling assumption you adopt in order to prove a goal such as IND-CCA2, and it sits beside the standard model, which assumes only that standard problems are hard. The random oracle model is emphatically **not** a security definition. It never occupies the same slot as IND-CPA or EUF-CMA; it is where you prove those goals, not what you prove.

Bellare and Rogaway introduced it in 1993 precisely because it buys efficient, strong proofs for practical schemes: OAEP, PSS, and the FO transform behind ML-KEM all live here [@br1993]. The standard model asks for less faith and is therefore more trustworthy when you can afford it.

Cramer and Shoup proved in 1998 that IND-CCA2 is achievable in the standard model, under the decisional Diffie-Hellman assumption, with no random oracle at all, settling that the strongest confidentiality target is not hostage to the heuristic [@cramershoup1998]. The two settings coexist as a trade of assurance against efficiency, and the post-quantum era stacks the quantum random oracle model on top.Beyond the deployed targets in this guide, the literature refines these notions further along both axes. RCCA (Canetti-Krawczyk-Nielsen) [@ckn2003rcca] and the related gCCA and mCCA variants relax IND-CCA2 for settings such as re-randomizable encryption. On the hash-function side, UCE is a standard-model assumption for discharging hash-based proofs without a random oracle, while indifferentiability is an ideal-model framework showing that a concrete construction built from an ideal primitive behaves like a random oracle, the tool that justifies random-oracle-style design rather than replacing it. These academic refinements are surveyed in later parts of this series; here they are pointers only.

Here is the whole thing in one picture: two proof settings, the random oracle model and the standard model, with the major schemes sorted by where each one is proven.

flowchart TD subgraph ROM["Random oracle model"] O["RSA-OAEP (IND-CCA2) and RSA-PSS (EUF-CMA), strong game-based goals proven in the ROM"] K["ML-KEM, IND-CCA2 KEM via the FO transform in the quantum ROM"] end subgraph STD["Standard model"] CS["Cramer-Shoup, IND-CCA2 under decisional Diffie-Hellman"] UC["Universal-composability zero knowledge, simulation based"] end The random oracle model and the standard model are not rival definitions of secure. They are two settings in which you prove the same goal.

Which raises the uncomfortable question the next section confronts. If the random oracle model is only a heuristic, exactly how much is a random-oracle proof worth?

8. What a Proof Cannot Promise

Now the uncomfortable part. A scheme can be provably secure in the random oracle model and broken under every real hash function you could ever plug in.

That is not a worry, it is a theorem. Canetti, Goldreich, and Halevi constructed signature and encryption schemes that carry airtight proofs in the random oracle model yet become insecure the moment the oracle is replaced by any concrete, efficiently computable hash [@cgh2004]. Their construction is deliberately contrived, engineered to detect when its oracle has a short description and to misbehave when it does. But contrived is enough: it proves that a random-oracle proof cannot, in general, guarantee security once instantiated. The proof is real; the security does not always survive contact with a real hash.

Note: Treat a random-oracle proof as strong evidence, not as a certificate. It says a scheme has no structural weakness of the kind the proof rules out, which is reassuring for OAEP, PSS, and ML-KEM. It does not say that every hash instantiation is safe, because we know constructions where none is [@cgh2004]. Calibrate your trust to the setting the proof actually used.

The honest reading is not to discard random-oracle proofs. Almost everything efficient we deploy has one, and the counterexamples above are artificial rather than schemes anyone would design. The honest reading is to calibrate. That is also the spirit of Koblitz and Menezes's "Another Look" critique, which is often misread as an attack on provable security and is better understood as a discipline for reading proofs [@km2007].

Before you trust a "provably secure" label, ask four questions. What exactly are the goal and adversary model, stated in full? What assumption does the reduction rest on, and how well studied is it? How tight is the reduction, and what security does it actually deliver at the deployed parameters? And in which setting does the proof live, random oracle or standard model? None of these questions refutes a proof. Each tells you what the proof is worth [@km2007].

Even celebrated proofs need repair. The original OAEP argument had a gap in its chosen-ciphertext proof that went unnoticed for years before it was found and fixed for the RSA case.Victor Shoup showed in 2001 that the original OAEP proof did not establish IND-CCA2 in the generality claimed. The result was recovered for RSA specifically, but only after the community re-examined a proof everyone had trusted [@shoup2001]. A proof is an artifact, and artifacts can contain bugs. If the proofs themselves can carry errors, "it has a proof" is the beginning of due diligence, not the end.

Underneath all of it sits the deepest limit of the field. Essentially every computational definition in this guide rests on an unproven assumption: that factoring is hard, that discrete logarithms are hard, that Module-LWE is hard. A genuine, unconditional proof that any of them is hard would resolve questions on the order of P versus NP, which nobody can do [@bonehshoup].

So "provably secure" always means conditionally secure. There is no unconditional computational security above the Shannon bound we started with. The one-time pad remains the only thing proven secure against an unbounded adversary, and it is the one thing we cannot afford to use.

None of this refutes the method. It maps the edge of what is settled. And the edge is exactly where today's research is moving.

9. Where the Definitions Are Still Moving

The chain is not closed. Each open problem below is a place where the adversary model is still being enlarged, which is another way of saying the thesis is a roadmap rather than a finished map.

Standardizing committing AEAD. The deployed triad commits to nothing, yet message franking, multi-recipient encryption, key rotation, key-management services, and password-based encryption all need it. The Accordion effort is scoping the mode now, but whether the default becomes key commitment (CMT-1) or full context commitment (CMT-4) is still open, and the two differ in both cost and in what they defend [@ir8537] [@sp800197a].
Tight, deployment-honest reductions. Loose reductions force larger keys than the assumption alone requires, and the gap is worst in the multi-user setting, where one attacker faces millions of sessions at once. The Section 5 rule makes the cost concrete: if a reduction loses a factor equal to a billion ($2^{30}$) sessions, a headline 128-bit guarantee shrinks to about 98 bits at the deployed parameters.RFC 9771 names multi-user security as a distinct property precisely because a bound that is comfortable for one user can dissolve across a billion of them. Tight multi-user proofs are an active target, not a solved problem [@rfc9771]. How much the community should discount a loose proof remains contested rather than settled [@km2007].
Post-quantum definitions in the quantum random oracle model. What "IND-CCA2 against a quantum adversary" actually costs is still being pinned down. ML-KEM ships with a proof whose bound is not tight, and the right model for a superposition decryption oracle is unsettled [@hhk2017] [@rfc9771].
The random-oracle-versus-standard-model question. Canetti, Goldreich, and Halevi proved the random oracle model is in principle uninstantiable, yet the efficient schemes running the internet are proved there, and Cramer and Shoup showed the standard model can reach the same target at higher cost [@cgh2004] [@cramershoup1998]. There is no consensus on how much to trust the heuristic; the honest position is calibrated trust, not resolution.

Note: Every entry on this list is a place where a future deployment could hand an attacker a capability no current definition names, exactly as message franking did in 2018. That is why the discipline is not "memorize the acronyms." It is a habit you apply before you choose a primitive.

Which is exactly why mastery here is not the acronyms. It is a workflow, and it fits on one screen.

10. The Field Guide: Choose the Target Before the Primitive

Everything in this guide collapses into one workflow you can run in a design review this afternoon: name what the adversary is allowed to do, pick the target that survives that adversary, and only then choose a concrete mode and its parameters. The tree below is the whole method.

flowchart TD Q1{"Can the adversary observe decryption or accept/reject?"} Q1 -->|"Yes"| CCA["Require IND-CCA2, never IND-CPA-only"] Q1 -->|"No, just encrypting a channel"| AEAD["Use AEAD by default"] AEAD --> Q2{"Can you guarantee unique nonces?"} Q2 -->|"Yes, with AES hardware"| GCM["AES-256-GCM, 96-bit random nonce, cap under 2 to the 32 per key"] Q2 -->|"No"| SIV["AES-GCM-SIV, nonce-misuse resistant"] CCA --> Q3{"Must one ciphertext bind to one key?"} Q3 -->|"Yes"| CMT["Require committing AE, CMT-4 or a vetted transform"]

The decision rules, stated the way you would apply them:

If any adversary can observe decryption or accept/reject behavior, require IND-CCA2, never IND-CPA-only. That is the Bleichenbacher and ROBOT lesson: a reacting server is a decryption oracle [@bleichenbacher1998].
If you are encrypting a channel, use AEAD by default. AES-256-GCM with 96-bit random nonces and a hard message cap well under $2^{32}$ per key [@sp800_38d]; ChaCha20-Poly1305 where there is no AES hardware [@rfc8439]; AES-GCM-SIV when nonce uniqueness cannot be guaranteed [@rfc8452].
If you must use RSA encryption at all, use RSA-OAEP, never PKCS#1 v1.5, or drop RSA key transport entirely as TLS 1.3 did [@br1994oaep] [@bleichenbacher1998].
If you need authenticity only, use HMAC or Ed25519 for EUF-CMA, and require SUF-CMA wherever a signature or token must be unique [@bonehshoup] [@decker2014]. Ed25519 delivers SUF-CMA only when verification enforces the RFC 8032 canonical-S range check, rejecting any scalar $S$ outside $[0, L)$; libraries that skip it stay malleable [@rfc8032].
If a ciphertext must bind to exactly one key or context, require a committing AE: a CMT-4 construction or a vetted committing transform, never the raw triad. This is the multi-recipient, key-rotation, franking, password-based, and key-management case [@rfc9771] [@aws_esdk] [@bh2022].
If you need post-quantum key establishment, use ML-KEM (FIPS 203) in hybrid mode with a classical KEM during the transition [@fips203].

Deployment condition	Required target	Concrete choice and parameters	Anti-pattern it prevents
Adversary sees decryption or accept/reject	IND-CCA2	ML-KEM, RSA-OAEP, or an AEAD channel	Bleichenbacher, ROBOT, POODLE
Channel, unique nonces, AES hardware	AEAD	AES-256-GCM, 96-bit random nonce, cap under $2^{32}$ per key	Unauthenticated or malleable ciphertext
Channel, no AES hardware	AEAD	ChaCha20-Poly1305	Slow or side-channel-prone software AES
Nonce uniqueness not guaranteed	AEAD plus misuse resistance	AES-GCM-SIV	Joux forbidden-attack forgery
Legacy RSA encryption required	IND-CCA2	RSA-OAEP, never PKCS#1 v1.5	Padding-oracle decryption
Signature or token must be unique	SUF-CMA	Ed25519	Signature-malleability confusion
One ciphertext must bind to one key	Committing AE (CMT)	Committing transform or Accordion mode	Invisible salamanders, partitioning oracles
Confidentiality must outlive a quantum computer	IND-CCA2, post-quantum	Hybrid X25519 plus ML-KEM	Harvest-now-decrypt-later

Every rule above has a mirror image, a mistake that turns up in code review after code review. Here is the misuse catalog, each entry the negation of a rule you just read.

Nonce reuse under AES-GCM or ChaCha20-Poly1305, the single most destructive AEAD error, because it is a universal forgery via the Joux attack rather than a slow degradation [@joux_gcm]. Clones, snapshots, and stateless senders are the usual sources; reach for AES-GCM-SIV or a strictly managed random nonce with a per-key cap.
The wrong composition order, MAC-then-Encrypt or Encrypt-and-MAC; only Encrypt-then-MAC or a dedicated AEAD is generically safe, and history already paid for this with POODLE and Lucky Thirteen [@bn2000].
Treating AES-GCM as key-committing. It commits to nothing; assuming otherwise is the salamander and partitioning-oracle bug [@salamanders2018] [@partitioning2021].
Unbounded messages per key, silently walking past the birthday ceiling that GCM's 96-bit nonce imposes [@sp800_38d].
Verifying a signature without binding its context, which EUF-CMA never promised to cover and which invites cross-protocol confusion.
Trusting a random-oracle proof as a standard-model guarantee, when it is a heuristic to be calibrated rather than a certificate [@cgh2004].

For where these targets are actually invoked as concrete API calls on Windows, from BCrypt to key storage providers, see the CNG architecture behind BCrypt, NCrypt, and KSPs.

Note: State your deployment's adversary model first, choose the matching target second, and pick the concrete primitive and its parameters last. Every rule and every anti-pattern above is a corollary of that one habit.

Bleichenbacher and ROBOT: require IND-CCA2 and drop PKCS#1 v1.5. Lucky Thirteen and POODLE: use an AEAD with Encrypt-then-MAC, not MAC-then-Encrypt CBC. AES-GCM nonce reuse: cap messages per key and use AES-GCM-SIV where uniqueness is uncertain. Invisible salamanders and partitioning oracles: require a committing (CMT) mode. Every break in the catalog was preventable by choosing the target the environment demanded before choosing the primitive.

One habit generated every rule and every warning on this page: name the adversary first.

11. Misconceptions, Named and Corrected

The fastest way to internalize the thesis is to correct the folklore it contradicts.

Only against a *passive* adversary who never sees how the receiver reacts to a ciphertext. The moment a server decrypts attacker-supplied input and behaves observably differently on success and failure, you need IND-CCA2. That gap is exactly what Bleichenbacher's attack exploited [@bleichenbacher1998]. Only under a strict nonce-uniqueness contract and a per-key message cap. Reusing a (key, nonce) pair is a universal forgery, not a minor leak [@joux_gcm]; NIST caps GCM at about $2^{32}$ invocations per key at a 96-bit nonce [@sp800_38d]; and GCM commits to no key, so it is unsafe wherever commitment is assumed [@salamanders2018]. It is strong evidence, not a guarantee. Canetti, Goldreich, and Halevi built schemes provably secure in the random oracle model that are insecure under every real hash [@cgh2004]. Trust a random-oracle proof, but calibrate that trust to the setting it used. No. Confidentiality and integrity are different goals; a one-time pad has perfect confidentiality and zero integrity, since flipping a ciphertext bit flips the plaintext bit undetected. Use an AEAD, and compose Encrypt-then-MAC if you must build it yourself [@bn2000]. No. SUF-CMA also forbids producing a *new* valid signature on an already-signed message, which EUF-CMA permits. The gap bites whenever a signature or ciphertext is treated as a unique token, as Bitcoin transaction malleability showed [@decker2014] [@bonehshoup]. No. It means *conditionally* secure, relative to a named hardness assumption and adversary model, and only as tightly as the reduction allows. A loose reduction delivers fewer bits of security than the headline number suggests [@km2007]. No. It is a proof setting, a heuristic that idealizes a hash as a random function, and it sits beside the standard model, not beside goals like IND-CPA or EUF-CMA. Cramer and Shoup showed the strongest confidentiality target is reachable without it [@br1993] [@cramershoup1998].

The Contract Behind the Cipher

We began with a puzzle: Daniel Bleichenbacher decrypted SSL sessions without ever breaking RSA. The answer runs through every section since. "Secure" is not a property an algorithm has. It is a contract, a goal bound to an adversary model, and a construction honors that contract only against the adversary the contract names.

Bleichenbacher, POODLE, Lucky Thirteen, AES-GCM nonce reuse, invisible salamanders, partitioning oracles: not one of them was weak math. Each was a construction meeting a weaker target than its deployment's adversary demanded, after the environment handed the attacker an oracle, a repeated nonce, or a second key the proof never granted.

That is why the vocabulary matters. IND-CPA and IND-CCA2 name what confidentiality means against a passive versus an active adversary. EUF-CMA and SUF-CMA name authenticity with and without malleability. AEAD names their union; committing AE names what AEAD forgot. The random oracle model and the standard model name where a proof lives, and a reduction names the single assumption on which the whole guarantee rests. Learn to read a construction as goal plus adversary model plus proof setting, and the failure catalog stops being a list of surprises and becomes a list of predictions.

This is Part 1 of a field guide, and it deliberately taught no primitive in depth. That was the point. The remaining parts of this series will build RSA, Diffie-Hellman, elliptic curves, lattices, and hash functions, and every one of them will be measured against exactly the targets defined here. The math will change from part to part. The contract will not.

The RSA math was always fine. What the field lacked in 1998 was the habit of naming the adversary before trusting the primitive. Now you have it.

State the adversary model first, choose the matching target second, and pick the primitive last. That one habit would have prevented every break in this article.