Parag Mali - tag: protocol-design

The Signature Was Valid. The Message Was Forged: A Field Guide to Serialization and Canonicalization Attacks

noreply@paragmali.com (Parag Mali) — Wed, 08 Jul 2026 03:48:01 GMT

A signature, a MAC, and a hash make exactly one promise: they bind a specific string of *bytes* -- never their meaning. Every attack in this guide (hash length extension, ASN.1/DER signature forgery, JWT algorithm confusion, XML signature wrapping) leaves the algorithm flawless and pries open the gap between the bytes that were authenticated and the bytes the application acts on. Each does it with one of just two moves: an **ambiguous encoding**, or an **attacker-influenced binding**. The cure is a three-pattern discipline, not a stronger algorithm: sign the exact bytes the consumer parses; when you must sign structure, use an encoding with exactly one valid form; and bind type, context, and algorithm into what you sign. Master one question and you can read any break in this family on sight: *are the bytes I authenticated exactly the bytes I will act on, and can they mean only one thing?*

1. Two Lines of Code, Fifteen Years Apart

In September 2009, two researchers forged a perfectly valid signature on a Flickr API request without ever learning Flickr's secret key, and the attack exploited no weakness in MD5's compression function at all [@flickr-2009]. Fifteen years later, an attacker holding any single assertion an identity provider had ever signed could walk into a GitLab instance as any user they chose, because the signature that verified covered one identity while the application trusted another [@cve-2024-45409] [@gitlab-advisory]. In both cases the mathematics was flawless. The bytes were the wound.

That pairing is the whole subject in miniature. A cryptographic signature, a message authentication code, and a hash all make the same narrow promise: they bind one exact string of bytes. They say nothing about what those bytes mean, and nothing about whether the bytes the verifier checked are the bytes the application will act on. Break either of those unspoken assumptions and you get a valid signature over a forged message, with the algorithm computing exactly what it was told to.

An attacker with any document signed by the identity provider can "forge a SAML Response/Assertion with arbitrary contents" and "log in as arbitrary user" -- with a signature that verifies. [@cve-2024-45409]

Once you see it this way, the family stops looking like seven unrelated tricks. Every break enters through one of exactly two doors. Call them the two-move lens, and you will spend the rest of this article placing new attacks into one bucket or the other on sight.

flowchart TD A["A signature, MAC, or hash binds one exact byte string"] --> B{"Where does the attacker's wedge enter?"} B -->|Move 1| C["Ambiguous encoding: many byte strings mean one thing, or one byte string parses two ways"] B -->|Move 2| D["Attacker-influenced binding: the authenticated span, or the verify rule, is under the adversary's control"] C --> E["The bytes the verifier checked are not the bytes the application acts on"] D --> E

Move one is an ambiguous encoding: many different byte strings decode to the same meaning, or one byte string parses two different ways. Move two is an attacker-influenced binding: the span that actually gets authenticated, or the rule used to verify it, is something the adversary can steer. Flickr was move two: hash length extension extends the authenticated span to swallow the attacker's appended bytes. Bleichenbacher's 2006 forgery was the clean move one, a lax encoding that a lenient verifier read as a valid one [@bleichenbacher-2006]. The GitLab break was move two, riding on move one. A third break we will meet shortly, the JWT alg:none bypass, is move two in its purest form: the message tells the verifier how to verify it [@mclean-2015].

Note: This is not "insecure deserialization." The bugs in this family live at the boundary where cryptography meets parsing, not where an attacker ships a serialized object that runs code on load (Python pickle, Java readObject, PHP unserialize). Object-injection remote code execution is a distinct topic with a distinct fix. Here, the payload is always just data, and the entire drama is which bytes got signed versus which bytes got believed.

This is Part 3 of a field guide for protocol designers. Part 1 built the vocabulary of security definitions, showing that a provably fine primitive still sinks a protocol when the deployment hands an adversary a capability the proof never modeled (Secure Against Whom?). This part is that thesis pointed at one specific seam: the serialization. We assume you are comfortable with the idea that "secure" means "secure against a named adversary," and we build from there.

If neither MD5's compression function, nor RSA's modular exponentiation, nor SAML's signature algorithm was ever broken, then where exactly did the wedge go in? To answer that, we have to go back to two inventions that created the gap, one from 1989 and one whose canonical form was standardized in 1994, both engineered for entirely good reasons.

2. Where the Gap Comes From

Kerckhoffs said it in 1883 and Shannon formalized it in 1949: put all the secrecy in the key, and assume the adversary knows everything else [@kerckhoffs-1883] [@shannon-1949]. That principle governs where a system's security must live -- in the key, never in the obscurity of the algorithm. Historically framed for secrecy systems, it says nothing about the moment you have to serialize a structured message you must authenticate: an API request, a certificate, an identity assertion.

The instant a structure has to become bytes on a wire, the rule that turns structure into bytes becomes attack surface. This family of breaks is not new. It is as old as the sentence "we need to sign this serialized data."

Two inventions, one from 1989 and one whose canonical form was standardized in 1994, built the gap into the foundations. Neither was a mistake. Each solved a real problem and quietly left a door ajar.

The first is the way almost every hash function you have used is built.

An iterated hash design, introduced independently by Ralph Merkle and Ivan Damgard at CRYPTO 1989. The padded message is split into fixed-size blocks, and a compression function folds them one at a time into a running chaining value. The *final chaining value is published as the digest*. MD5, SHA-1, and the SHA-2 family are all Merkle-Damgard hashes.

Write it as a recurrence and the shape of every later attack is already visible. Starting from a fixed initial value $s_0$, the hash computes $s_i = f(s_{i-1}, m_i)$ for each padded block $m_i$, and emits the last state as the digest, $H(m) = s_n$ [@merkle-1989] [@damgard-1989] [@cryptoeng]. Merkle and Damgard proved something valuable: if the compression function $f$ resists collisions, so does the whole iterated hash. To make the proof work, they appended the message length inside the final padding, a trick called Merkle-Damgard strengthening.

Here is the door. The digest is the internal state. Nothing about $s_n$ is secret or scrambled beyond what the public compression function did to it. If you know a digest and how many bytes preceded it, you can set your own machine's state to that digest and keep hashing from where the original left off.The appended length field was added to stop collision ambiguities between messages that pad to the same blocks. It does nothing to conceal the internal state. That is precisely why a length-extension attacker needs to know the length of the secret: only to reconstruct the "glue" padding, never to recover the state itself [@bowes].

The second invention is how we write down the things we sign so two machines agree byte-for-byte.

An encoding rule under which every abstract value has exactly one legal byte representation. That makes "is this the encoding of X?" a single yes-or-no question. The Distinguished Encoding Rules (DER) of ASN.1, standardized by the ITU-T as X.690, are the archetype, and they carry the signed structures inside X.509 certificates and PKCS#1 signatures [@x690] [@rfc8017].

ASN.1 dates to the 1980s, and its canonical DER form was standardized as ITU-T X.690 in 1994. DER exists for a genuine reason: if you are going to hash and sign a structured object like a certificate, every implementation must serialize it to identical bytes or no two of them will ever agree on a signature. DER is the "exactly one valid byte string" discipline done right. Its siblings, the more permissive Basic Encoding Rules (BER), allow many byte strings for the same value, which is convenient for streaming and a loaded gun for signature verification, as we will see [@x690].

timeline title The byte-vs-meaning gap, 1989 to 2025 1989 : Merkle-Damgard hashing 1994 : X.690 DER canonical encoding 1997 : HMAC standardized (RFC 2104) 2005 : XML signature wrapping named 2006 : Bleichenbacher e-3 RSA forgery 2009 : Flickr length-extension forgery 2015 : JWT alg confusion and alg none 2025 : ruby-saml parser differential

The third piece of history is younger, and it is the moment the industry first wrote the problem down as a class rather than a one-off bug. In 2005, Michael McIntosh and Paula Austel at IBM published the first formal treatment of XML signature element wrapping: a genuinely signed element could be relocated inside a document so that verification found it in one place while the application consumed a forged element somewhere else [@mcintosh-2005]. They named the attacker-influenced-binding move for documents two decades before it produced an unauthenticated GitLab administrator takeover in 2025.

Both roots were built for good reasons -- a collision-resistance proof and an interoperable, unambiguous encoding -- and both left the same gap between bytes and meaning. So what happens when a working engineer reaches for the obvious way to authenticate a message with these tools? They build a trap. Three of them, one for each obvious shortcut.

3. Three Obvious Designs, Three Traps

Give an engineer a hash, a signature, and a deadline, and each of the two foundations above suggests an obvious shortcut. All three shortcuts authenticate something near the thing they should have, and the small gap between "near" and "exactly" is where every attack in this article lives.

Trap one: prove you know a secret by hashing it in front of the message. Before HMAC existed, the natural way to build a keyed authentication tag was to concatenate the secret with the message and hash the result: MAC = H(secret || message). It feels airtight. An attacker who has never seen the secret cannot reproduce the hash, so a matching tag looks like proof of knowledge. But recall that in a Merkle-Damgard hash the digest is the internal state after absorbing secret || message || padding. Publishing the tag hands the attacker the machine mid-computation.

Given only the tag $t = H(\text{secret} \,\|\, m)$ and the *length* of the secret -- but not the secret itself -- an attacker can compute a valid tag for a longer message $H(\text{secret} \,\|\, m \,\|\, \text{pad} \,\|\, m')$ for attacker-chosen bytes $m'$. The published digest is loaded back in as the hash's internal state, and hashing simply continues from there. It works against any plain "output equals full state" Merkle-Damgard hash [@bowes].

Trap two: verify an RSA signature by looking for the right structure inside it. A PKCS#1 v1.5 signature, once you undo the RSA math, is a byte string that is supposed to be a specific padded encoding wrapping a small ASN.1 structure called DigestInfo, which names the hash algorithm and carries the hash [@rfc8017]. The correct check is exact: re-encode the expected structure to its canonical DER bytes and compare the whole thing, byte for byte. The tempting shortcut is to parse: scan the decrypted block, find a DigestInfo somewhere inside it, pull out the hash, and compare only that. A lenient verifier silently changes the question from "is this the canonical encoding?" to "does a valid DigestInfo appear somewhere in here?" [@bleichenbacher-2006].

Trap three: sign an XML element and let the verifier find it later by name. XML Signature, standardized by the W3C in 2002, does not sign "the document." It signs whatever elements a <Reference> points at, typically by an Id attribute, after running them through a canonicalization transform [@xmldsig-2002] [@xmldsig]. Verification asks "is there a correctly signed element with this Id?" The application, separately, asks "what does the assertion say?" Nothing in the design forces those two questions to resolve to the same element. That gap is the seed of every signature-wrapping attack [@mcintosh-2005].

Traps two and three share a deeper shape that has its own name.

A situation in which two implementations, or two passes of one implementation, derive different structure or meaning from the *same* input bytes. When one parser is the verifier and another is the consumer, the object that got checked and the object that gets acted on are no longer guaranteed to be the same object [@bishopfox-2020].

Each of these designs shipped, and each was trusted for years, because each works perfectly on honest input. Honest input is the trap. The verifier and the consumer agree on every well-formed message anyone generates by accident, and diverge only on the adversarial message nobody tested.

Key idea: In all three traps, verification confirmed a valid reading of the bytes, not the single canonical one, and it authenticated a span the attacker could later move, extend, or reinterpret. That one sentence is the whole failure catalog. Everything that follows is the same wound in five different bodies.

These leaks did not announce themselves. They surfaced one at a time, over fifteen years, and each new break forced a specific defense that the next generation promptly outgrew. Line the breaks up in order and they beat like a metronome: an obvious design, a named forgery, a fix, then a more ambitious design that reopens the identical gap. Here is that sequence, generation by generation.

4. Five Generations, One Shape

The genealogy of this subject is easy to misread as "each fix replaced the previous primitive." It did not. Hashes did not replace signatures, and JSON did not replace XML because XML was cryptographically weaker. What actually happened is a steady rise in ambition.

Read the five generations as one trend, not a list. Each authenticates *more structure* than the last: a raw string, then a cryptographic structure, then a whole document, then a self-describing token, then a binary remote-procedure-call message. Every added layer of structure opened a new way for the authenticated bytes to drift from the consumed bytes. The primitive was never the variable that changed. The ambition was.

Generation 1 -- The keyed hash done wrong

The simplest thing to authenticate is a raw string, and the simplest keyed tag is H(secret || message). In September 2009, Thai Duong and Juliano Rizzo showed that Flickr's API used exactly this over MD5, and that an attacker could append arbitrary parameters to a signed request and produce a tag that verified, without ever knowing the secret [@flickr-2009]. MD5's compression function was not the casualty. The construction was.

flowchart TD S["Sender computes the tag as H of secret then message"] --> T["Published tag equals the final Merkle-Damgard state"] T --> A["Attacker reads the tag and guesses the secret length"] A --> R["Reload the tag as the hash internal state"] R --> X["Keep hashing: glue padding, then attacker bytes m-prime"] X --> F["Valid tag for secret, message, padding, m-prime, with the secret never known"]

The mechanism is worth feeling in code, not just reading. A "resumable" hash publishes its whole state as the digest, so the tag is a saved game the attacker loads and continues.

{` // A toy "output equals full internal state" hash, in the Merkle-Damgard spirit. // The tag IS the state, so anyone can resume hashing from it. (Padding elided.) function toyCompress(state, block) { let s = state >>> 0; for (const ch of block) s = (Math.imul(s, 31) + ch.charCodeAt(0)) >>> 0; return s; // final state == published digest } function toyHash(msg) { return toyCompress(0x9e3779b1, msg); }

const SECRET = "hunter2"; // attacker never sees this const tag = toyHash(SECRET + "&role=guest"); console.log("server tag:", tag);

// Attacker knows ONLY the tag and the length of (secret + message). // They reload the tag as state and keep hashing their own bytes: const forged = toyCompress(tag, "&role=admin");

// What the server computes over the extended message, WITH the secret: const serverRecompute = toyCompress(toyHash(SECRET + "&role=guest"), "&role=admin"); console.log("forged == server:", forged === serverRecompute); // true, no secret needed `}

The fix was to stop signing with a construction whose output is a resumable state. Bellare, Canetti, and Krawczyk had already shown how in 1996 [@bck-1996].

The Hash-based Message Authentication Code, analyzed by Bellare, Canetti, and Krawczyk in 1996 and standardized in RFC 2104 in 1997. HMAC nests two keyed hash passes, $\text{HMAC}(K, m) = H((K_0 \oplus \text{opad}) \,\|\, H((K_0 \oplus \text{ipad}) \,\|\, m))$, where $K_0$ is the secret key fitted to one full hash block. It is length-extension-immune not because it has no resumable state, but because its outer input is a fixed one-key-block-plus-one-inner-digest structure, and forging a new inner digest requires the secret [@rfc2104] [@bck-1996] [@fips198-1].

Two details of that definition carry the whole argument, and both are routinely mangled. First, $K_0$: FIPS 198-1 defines it as the key preprocessed to exactly one $B$-byte hash block -- the key itself when it is already $B$ bytes, its hash padded with zeros when it is longer than a block, and the key padded with zeros when it is shorter [@fips198-1]. The exclusive-or is always against that block $K_0$, never against a raw key of arbitrary length.

Second, the reason HMAC resists length extension. It is tempting, and wrong, to say HMAC "has no internal state to resume." It does; an HMAC tag is an ordinary hash output, so you can load it back as a Merkle-Damgard state and keep hashing. The immunity is structural. A genuine HMAC tag is the outer hash of exactly two things: one $B$-byte key block $(K_0 \oplus \text{opad})$ followed by exactly one inner digest. Resume from a tag, append your own bytes, and what you have computed is a valid HMAC of no well-formed message at all, because a real HMAC's outer input is never longer than one key block plus one inner digest.This is the subtlest true statement in the subject. An HMAC tag can be resumed as a Merkle-Damgard state, so the folk explanation "there is no state to resume" is false. What resuming actually yields is a valid tag for no message, because the outer hash's input is pinned at one key block plus one inner digest. Immunity is a property of that fixed structure, not of missing state [@fips198-1]. To forge a tag for a genuinely new message you would have to produce that message's inner digest, and the inner hash begins with the secret-derived block $(K_0 \oplus \text{ipad})$. So you need $K_0$, which means you need the secret [@rfc2104] [@fips198-1].

The single most-botched fact in this whole subject is the boundary between what is extendable and what is not, so here it is drawn exactly [@bowes].

Construction	Length-extendable?	Why
MD5, SHA-1, SHA-256, SHA-512 over secret then message	Yes	The digest is the full final Merkle-Damgard state
HMAC with any of those hashes	No	Outer input is fixed at one key block plus one inner digest; resuming a tag yields a tag for no message, and a new inner digest needs the secret
SHA-3, SHAKE, KMAC	No	Sponge construction; the capacity is never output
SHA-512/256, SHA-384 (truncated SHA-2)	No	Part of the final state is withheld from the output

Note: Vulnerable: a bare SHA-256(secret || message) used as a MAC. Not vulnerable: HMAC-SHA256, the SHA-3 family, and truncated SHA-2 such as SHA-512/256. Note what this does not say. SHA-256 is not "broken," and HMAC-SHA256 is not length-extendable. The flaw is the construction H(secret || m), never the hash inside it [@bowes] [@rfc2104].

Here the reader's model should shift. Hashing secret || message felt like proof of knowledge; it was nothing of the sort, because the tag is the primitive's own continuation, offered to the attacker for free.Flickr shipped MD5(secret || params) in 2009, twelve years after RFC 2104 (1997) standardized HMAC, the exact fix for this exact bug. Folklore about "just hash the secret with it" outlived its own refutation by more than a decade [@flickr-2009] [@rfc2104]. The compression function was never touched. The construction leaked.

Ron Bowes published `hash_extender`, which automates the glue-padding arithmetic for MD5, SHA-1, the SHA-256 and SHA-512 families, and more. Feed it a captured `H(secret || m)` tag, a guess for the secret length, and the bytes you want to append, and it prints both the forged tag and the exact padded message that produces it [@bowes].

Generation 2 -- Signing a cryptographic structure

Raise the ambition: now you are signing not a raw string but a structured object, an RSA signature carrying an ASN.1 DigestInfo. The lenient verifier from trap two turns this into a forgery machine. In 2006, Daniel Bleichenbacher demonstrated at the CRYPTO rump session that if a verifier parses the decrypted PKCS#1 v1.5 block for a DigestInfo instead of checking the exact padded encoding, and if the RSA public exponent is 3, an attacker can craft a value whose cube looks like a valid signature with garbage in the space the lenient parser ignores [@bleichenbacher-2006] [@valsorda]. No private key, no broken RSA, just a parser that accepted a structure instead of the encoding.Bleichenbacher bridges Part 1 and Part 3 of this guide. His 1998 padding oracle (Part 1) and his 2006 signature forgery are the same lesson told twice: the RSA math was always fine, and the wound was in how an implementation handled the bytes around it [@valsorda].

The lesson should have stuck. It did not. Eight years later, in September 2014, Antoine Delignat-Lavaud of Inria's Prosecco team and, independently, Intel Security's Advanced Threat Research team found the identical flaw shipping in Mozilla's NSS library, the code behind Firefox, Thunderbird, and Chrome on several platforms [@mfsa-2014-73] [@cve-2014-1568]. NVD records it as a failure to "properly parse ASN.1 values," a "signature malleability" issue [@cve-2014-1568].The break was nicknamed "BERserk" because the verifier accepted lax BER encodings where the specification demanded the single canonical DER form. The name is the diagnosis: the gap between "a valid encoding" and "the canonical encoding" is the whole bug [@mfsa-2014-73].

A signature scheme is *malleable* if, given a valid signature or the structure inside it, an attacker can derive a different signature the verifier still accepts, without the private key. NVD logs BERserk (CVE-2014-1568) verbatim as a "signature malleability" issue. A *non-malleable* scheme -- RSA-PSS, or any strongly unforgeable (SUF-CMA) signature -- forecloses this, which is exactly why it is the durable fix for the low-exponent forgeries [@cve-2014-1568] [@rfc8017].

The fix is the discipline from trap two, stated positively: never parse a signature to find its structure. Re-encode the expected DigestInfo to canonical DER, then compare the full block byte for byte, and prefer RSA-PSS, whose verification has no lenient-parse foothold [@rfc8017]. Windows code signing gets this right in production by signing a DER-encoded PKCS#7 structure (Authenticode and catalog files), and the X.509 certificates every TLS stack validates ride on the same DER discipline (SChannel and the twenty-year algorithm).

Generation 3 -- Signing a whole document

Raise the ambition again: sign an entire XML document, flexibly, so a signature can cover part of a message and travel with it. This is XML Signature, and its reference-by-Id model from trap three is the most durable failure in the subject.

An attack in which a genuinely signed XML element is relocated, duplicated, or wrapped inside a document so that signature verification still finds and validates the original element by its reference, while the application's business logic reads a *different*, attacker-authored element. The signed node and the consumed node are not the same node. McIntosh and Austel formalized it in 2005 [@mcintosh-2005]. flowchart TD D["Signed SAML response from the identity provider"] --> W["Attacker keeps the signed assertion and injects a forged assertion"] W --> V{"Verifier: is there a valid signature for this Id?"} V -->|Finds the genuine signed assertion| OK["Signature check passes"] OK --> C["Application reads identity from the forged assertion instead"] C --> R["Logged in as an arbitrary user"]

In 2012, Juraj Somorovsky and colleagues tested this against real SAML frameworks in "On Breaking SAML: Be Whoever You Want to Be." Of the 14 major frameworks they examined, 11 fell to at least one wrapping variant, and only two -- Microsoft SharePoint 2010 and SimpleSAMLphp -- resisted every variant they threw at them [@somorovsky-2012]. Eleven of fourteen is the number that matters: this was a systemic property of the sign-a-tree-by-reference design, not one vendor's slip.

Then in 2018, Kelby Ludwig at Duo Security found a subtler variant. Because canonicalization handles XML comments inconsistently, inserting a comment inside a signed field could make the verifier and the application read different text from the same signed element. As Ludwig put it, "multiple different-but-similar XML documents can have the same exact signature," a cluster catalogued as CVE-2017-11427 and its siblings [@duo-2018].

XML Signature can be patched case by case, but each patch closes one wrapping shape and leaves the model intact. That is why, as we are about to see, the same attack was still taking over logins in 2025. For new designs, this generation is a road that leads nowhere good.

Generation 4 -- Signing a self-describing token

Raise the ambition once more: a token that carries its own metadata, including which algorithm secured it. This is JOSE and the JSON Web Token. In 2015, Tim McLean showed what happens when you let a message choose how it is checked [@mclean-2015] [@cve-2015-9235].

A class of JWT and JOSE attack in which the token declares, in its unauthenticated header, which algorithm the verifier should use. Setting the header algorithm to `none` asks the verifier to accept an unsigned token. Switching it from `RS256` (an RSA signature) to `HS256` (an HMAC) can trick a verifier into using the *public* RSA key as an HMAC secret, a value the attacker also holds. The message chooses its own verification rule [@mclean-2015]. sequenceDiagram participant A as Attacker participant V as Verifier Note over V: Holds the RSA public key, expects RS256 A->>V: Take a real token, change the header alg to HS256 Note over A: Sign the token using the RSA public key bytes as the HMAC secret A->>V: Send the forged HS256 token V->>V: Reads alg from the token, selects HMAC-SHA256 V->>V: Uses the public key as the HMAC key and recomputes the tag V-->>A: Tag matches, token accepted as genuine

The RS256/HS256 confusion is the archetype of the type-confusion move: the attacker does not break either algorithm, but reinterprets a public value (the RSA key) as a secret value (the HMAC key), because the verifier let the token decide which one it was.The none algorithm is not a bug in the JOSE specification. RFC 7518 defines it as the algorithm for an Unsecured JWS, a legitimate option when integrity is guaranteed by some other layer. It becomes a bypass only when a verifier in a secured context fails to forbid it [@rfc7518].

The fix arrived formally in 2020 as RFC 8725, the JSON Web Token Best Current Practices, written after, in its own words, "there have been several widely published attacks on implementations and deployments" [@rfc8725]. Its discipline: pin an explicit algorithm allow-list, bind each key to exactly one algorithm, reject none in secured contexts, and never trust the algorithm the token names for itself. Windows leans on JWS-style tokens in production, such as the Primary Refresh Token (Inside the Primary Refresh Token); the rules a service applies before it trusts such a token are a discipline of their own (Who Decided This Token Is Good?).

Generation 5 -- Signing a binary message

The newest ambition is signing binary remote-procedure-call payloads, and it runs straight into a wall the earlier generations only grazed: some formats have no canonical byte form at all. Protocol Buffers is the clearest case. Its own documentation warns against assuming stable output.

"Deterministic serialization only guarantees the same byte output for a particular binary. The byte output may change across different versions of the binary." -- Protocol Buffers documentation [@protobuf]

If two versions of your service can serialize the same logical message to different bytes, then "sign the bytes and compare" is not even well defined: the sender and receiver may disagree on what the bytes are before any attacker shows up [@protobuf]. The fix is to refuse the premise. Sign the exact bytes you received and never re-serialize them; or, if you must sign structure, move to a format with a specified deterministic form, such as deterministic CBOR (RFC 8949, Section 4.2) or the JSON Canonicalization Scheme (RFC 8785); or sign a hash over explicit, typed fields rather than over a serializer's mood [@rfc8949] [@rfc8785].

Five generations, five fixes, one shape. Every fix was a variation on "make the authenticated bytes be exactly, and unambiguously, the bytes you act on." By the time the field had patched the fifth, it could finally state out loud what the first four had only whispered.

Generation	Named break (year)	Which move	The fix	Status
1 Keyed hash	Flickr length extension (2009)	Attacker-influenced binding: extends the span	HMAC, SHA-3, truncated SHA-2	Solved
2 Crypto structure	Bleichenbacher e=3 (2006), BERserk (2014)	Ambiguous encoding: BER versus DER	Re-encode to DER and byte-compare; RSA-PSS	Solved if disciplined
3 Document	On Breaking SAML (2012), Duo (2018)	Attacker-influenced binding plus ambiguous canonicalization	Sign the exact bytes; avoid for new designs	Recurring
4 Token	alg none, RS256/HS256 confusion (2015)	Attacker-influenced binding: message picks the rule	RFC 8725 allow-list, key-to-algorithm binding	Solved if disciplined
5 Binary or RPC	protobuf non-determinism	Ambiguous encoding: no canonical form	dCBOR, JCS, or sign the received bytes	Design guidance

5. Authenticate Bytes, Not Parses

Here is the sentence the five generations were spelling out. Cryptography authenticates bytes, so make the bytes you authenticate be exactly the bytes the consumer parses, make those bytes mean only one thing, and bind the type, context, and algorithm into what you sign so a valid signature can never be replayed into a second meaning. That is not three separate ideas competing for your allegiance. It is one idea with a strict order of preference.

Key idea: The cure for every break in this family is not a stronger algorithm. It is a change in what and how you sign: authenticate the exact bytes the consumer parses, in an encoding that can mean only one thing, with type, context, and algorithm bound in. The algorithm was never the problem, so a better algorithm was never going to be the answer.

flowchart TD Start["You must authenticate structured data"] --> Q{"Can you sign the exact bytes the consumer parses?"} Q -->|Yes, preferred| P1["Pattern 1: sign-the-encoding, as in JWS, COSE, TLS 1.3"] Q -->|No, structure is detached from the wire| P2["Pattern 2: canonical encoding such as DER, deterministic CBOR, JCS, then byte-compare"] P1 --> P3["Pattern 3, always on top: bind type, context, and algorithm, i.e. domain separation"] P2 --> P3

Pattern one, and the one to reach for first, is to sign the encoding.

The discipline of authenticating the *exact serialized bytes* the consumer will parse, rather than an abstract structure that must be re-serialized to check. Because the signed bytes and the parsed bytes are byte-identical, no re-serialization or parser-differential gap can open between verification and use. JWS signs the base64url `header.payload` string it transmits; COSE signs a CBOR `Sig_structure`; TLS 1.3 signs its transcript directly [@rfc7515] [@rfc9052] [@rfc8446].

When the bytes that were signed and the bytes that get parsed are literally the same bytes, moves one and two have nowhere to stand. There is no second parse to differ, and no separate span to relocate. JWS makes this concrete: the signature covers the exact base64url-encoded header.payload, so the verifier and the application see identical input [@rfc7515].base64url is the URL-safe base64 variant: it swaps the plus and slash characters for hyphen and underscore and drops the trailing padding, so a token survives being placed in a URL or header without further escaping. COSE does the same for CBOR in constrained and IoT settings via its Sig_structure [@rfc9052].

Pattern two is the disciplined fallback for when you genuinely cannot sign the wire bytes -- when a structure must be signed once and survive re-serialization by intermediaries. Then, and only then, use an encoding with exactly one legal form and verify by re-encoding and comparing bytes: DER for ASN.1, deterministic CBOR (RFC 8949, Section 4.2), or JCS for JSON (RFC 8785) [@x690] [@rfc8949] [@rfc8785]. This is strictly weaker than pattern one, because it is only as safe as your canonicalizer, a caveat that becomes a hard limit in Section 8.

Pattern three sits on top of whichever of the first two you chose, always.

Binding a signature to its intended type, context, and algorithm by folding those into the signed input, so a signature produced for one purpose cannot be replayed as if produced for another. TLS 1.3 prefixes its signed transcript with a context string (RFC 8446, Section 4.4.3); Ethereum's EIP-712 prepends a domain separator; RFC 8725 binds each JWT key to a single algorithm [@rfc8446] [@eip712] [@rfc8725].

EIP-712 shows the pattern in one line: the value actually signed is $\texttt{0x1901} ,|, \text{domainSeparator} ,|, \text{hashStruct}(m)$, so a signature for one contract, chain, or message type is meaningless anywhere else [@eip712]. This is what stops the Generation 4 move: if the key is bound to one algorithm and the context is bound into the bytes, the token can no longer talk the verifier into a different rule.

The gap between the abstract object and the bytes is not a detail; it is the entire subject. A worked example makes it visceral.

{` // Two "equal" objects serialize to different bytes -> different tags. const a = JSON.stringify({ user: "root", exp: 1710000000 }); const b = JSON.stringify({ exp: 1710000000, user: "root" }); // keys reordered console.log("a:", a); console.log("b:", b); console.log("byte-equal:", a === b); // false: a signature over 'a' will not verify 'b'

// A canonical pass (here, just sorted keys) makes these two agree. A real // canonicalizer (JCS, RFC 8785) must also pin number and string forms -- see section 8. function canonical(obj) { const keys = Object.keys(obj).sort(); const parts = keys.map(function (k) { return JSON.stringify(k) + ":" + JSON.stringify(obj[k]); }); return "{" + parts.join(",") + "}"; } console.log("canonical a:", canonical(JSON.parse(a))); console.log("canonical b:", canonical(JSON.parse(b))); console.log("now equal:", canonical(JSON.parse(a)) === canonical(JSON.parse(b))); // true `}

That is the discipline in principle. But principles ship as code, and code ships on deadlines. What does the state of the art actually look like from 2024 to 2026, and, two decades after signature wrapping was first named, is this class of attack finally dead?

6. What Is Shipping, and What Is Still Breaking

It is not dead. In 2025, two decades after McIntosh and Austel named signature wrapping, the attack produced an unauthenticated administrator takeover of GitLab instances [@github-seclab-2025] [@portswigger-2025]. The defenders have converged on the right patterns, and the attackers have responded by moving the wedge somewhere the patterns do not yet reach.

Start with the offense, because the 2024 to 2025 SAML cluster is the two-move lens at its sharpest. In September 2024, ruby-saml failed to verify the signature of a SAML response strictly enough, and NVD records the result plainly: an attacker "can forge a SAML Response/Assertion with arbitrary contents" and "log in as arbitrary user," which is exactly what happened to GitLab's SAML single sign-on [@cve-2024-45409] [@gitlab-advisory]. Weeks earlier, GitHub Enterprise Server had shipped a fix for a signature-wrapping bug in its handling of publicly exposed signed federation metadata that granted "site administrator privileges" to an unauthenticated attacker [@cve-2024-6800].

Then, in March 2025, the ruby-saml story got worse and more instructive. CVE-2025-25291 and CVE-2025-25292 are a parser differential: the library used two different XML parsers, REXML and Nokogiri, and, as NVD states, "the parsers can generate entirely different document structures from the same XML input," which "allows an attacker to execute a Signature Wrapping attack" [@cve-2025-25291] [@cve-2025-25292]. GitHub's Security Lab, which found it, summarized the payoff: an attacker holding a single valid signature can construct assertions themselves and "log in as any user," with an exploitable instance in GitLab [@github-seclab-2025].

Note: The 2025 ruby-saml break is the purest specimen in this whole article, because it is both moves fused into one. REXML and Nokogiri parsing the same bytes into different trees is an ambiguous encoding (move one). Using that difference to make the verifier check one assertion while the application consumes another is an attacker-influenced binding (move two). The checked tree is not the consumed tree [@cve-2025-25291] [@github-seclab-2025].

The same shape recurred across the wider SAML space in 2025: samlify allowed an attacker to "forge a SAML Response to authenticate as any user," rated CVSS 9.9 [@cve-2025-47949], and passport-wsfed-saml2 allowed impersonation of "any user during SAML authentication by crafting a SAMLResponse" using a valid IdP-signed object [@cve-2025-46572].

CVE (year)	Component	Move	Outcome
CVE-2024-45409 (2024)	ruby-saml with omniauth-saml	Improper signature verification	Forge any user; GitLab SSO bypass
CVE-2024-6800 (2024)	GitHub Enterprise Server	Signature wrapping	Unauthenticated site administrator
CVE-2025-25291 and CVE-2025-25292 (2025)	ruby-saml, REXML versus Nokogiri	Parser differential enabling wrapping	Unauthenticated GitLab admin
CVE-2025-47949 (2025)	samlify	Wrapping via injected assertion	Authenticate as any user (CVSS 9.9)
CVE-2025-46572 (2025)	passport-wsfed-saml2	Signature wrapping	Impersonate any user

The obvious advice, "stop using XML-DSig for new designs," is correct and nearly useless to the teams shipping these fixes. SAML still fronts enterprise single sign-on across large deployed systems, which is why the 2024 and 2025 breaks landed on GitLab and GitHub Enterprise rather than on toy projects [@cve-2024-45409] [@cve-2024-6800]. Ripping out a federation protocol is a multi-year migration that competes with every other roadmap item, so the pragmatic reality is that hardened SAML libraries have to keep existing. That tension is the honest core of one of this subject's live open problems.

Now the defense, which is genuinely encouraging. The right patterns are not just written down; they are shipping. RFC 8725 codified the JWT discipline in 2020, and its allow-list-and-bind rules are the baseline new JOSE code is measured against [@rfc8725].

The deterministic and canonical formats matured into real standards: deterministic CBOR (RFC 8949) and the JSON Canonicalization Scheme (RFC 8785) give designers a specified single form when they truly need one [@rfc8949] [@rfc8785]. And "sign-the-encoding" now anchors an entire generation of software supply-chain provenance: C2PA content credentials sign their manifests as COSE structures [@c2pa] [@rfc9052], Sigstore signs with ephemeral keys and records every signing event in a tamper-resistant transparency log [@sigstore] [@sigstore-docs], and the in-toto and SLSA frameworks carry signed, typed provenance through a build pipeline [@intoto] [@slsa].

So the score in 2026 is split. On the tokens-and-provenance side, the field adopted sign-the-encoding and the class is receding. On the legacy-XML side, the attackers simply relocated the wedge to the seam between two parsers, where no single canonicalizer can see it. That split sharpens the real design question. When you must sign structured data, which pattern do you pick, and what is the genuine, still-live tension between them?

7. Sign the Encoding, or Canonicalize First?

This is the one genuinely live design tension in the whole subject, and the honest framing is that it is a hierarchy, not a contradiction. Three approaches compete, and history has already ranked them.

At the top sits sign-the-encoding: JWS, COSE, and the TLS 1.3 transcript all authenticate the exact bytes that get consumed [@rfc7515] [@rfc9052] [@rfc8446]. The middle option is canonicalize then sign: reduce a structure to a single legal byte form (DER, deterministic CBOR, JCS) and sign that [@x690] [@rfc8949] [@rfc8785]. At the bottom, for legacy reasons only, sits XML-DSig with canonicalization, which signs a mutable tree by reference and canonicalizes it at verify time [@xmldsig].

Score them on what actually matters: which of the two moves each one forecloses, what verification costs, and what the empirical record says.

Approach	Move 1: ambiguous encoding	Move 2: attacker-influenced binding	Verify cost	Empirical record
Sign-the-encoding (JWS, COSE, TLS 1.3)	Closed: signed bytes are the parsed bytes	Closed when paired with domain separation	Low: hash the exact bytes	Clean where applied
Canonicalize then sign (DER, dCBOR, JCS)	Reduced: one form if the canonicalizer is correct	Needs separate binding	Medium: re-encode and byte-compare	BERserk when done leniently
XML-DSig with C14N (reference by Id)	Open: canonicalization ambiguity	Open: reference and wrapping	High: transforms plus canonicalize	Worst: unbroken 2005 to 2025

The ranking falls out of the table. Sign-the-encoding structurally removes move one, because there is no second serialization to disagree with the first. Canonicalization only reduces move one, because it is exactly as trustworthy as the canonicalizer, and it does nothing about move two on its own. XML-DSig leaves both moves open, which is why its CVE record runs, unbroken, from 2005 to 2025.

Two distinctions sharpen the choice. First, detached versus enveloped signatures: a signature can wrap the data (enveloping), sit inside it (enveloped), or travel beside it (detached). The more the signature and the data can be rearranged relative to each other, the more room move two has to operate, which is precisely XML-DSig's problem.

Second, and more often confused, message-layer versus transport-layer integrity. TLS protects the channel; it says nothing about a forged assertion carried inside that channel. Every SAML break above happened over perfectly good TLS. The twenty-year SChannel story is about transport-layer integrity (Rotating Every Cipher), a different and non-substitutable guarantee from a signed message that must survive being forwarded.

Note: Prefer signing the exact bytes the consumer parses. Treat canonicalize-then-sign as a spec-pinned, high-risk fallback, used only when a structure genuinely must be signed apart from its wire bytes, and always verified by re-encoding and byte-comparing, never by lenient parsing [@rfc8785] [@rfc8446].

History has largely adjudicated this tension in favor of the top of the hierarchy. But "largely" is carrying real weight in that sentence, because sometimes you inherit a rich format you cannot replace and a canonicalizer you cannot fully trust. Which raises the uncomfortable question the next section has to face: is there anything in this subject we cannot escape, no matter how much discipline we bring?

8. The Wall You Cannot Out-Discipline

Most of this article is about discipline: check the canonical form, sign the exact bytes, bind the context. But some of the subject is not a habit you can perfect. It is a wall, and it helps to know exactly where the wall stands.

The first stone is provable. Length extension is not a bug in MD5 or SHA-256; it is a structural property of any hash whose output is its full internal state. You cannot fix it by validating harder, adding checks, or trying again more carefully. You can only fix it by changing the construction: nest the hash (HMAC), switch to a sponge that never outputs its capacity (SHA-3), or withhold part of the state (truncated SHA-2) [@rfc2104] [@bowes]. No amount of care rescues H(secret || m), because the leak is in the shape, not the effort.Length extension is not a collision attack. Collision resistance -- the difficulty of finding two inputs with the same digest -- is a separate primitive property, treated in a sibling part of this guide. A hash can be flawlessly collision-resistant and still be trivially length-extendable, because the two properties constrain entirely different things [@bowes].

The second stone is deeper, and it comes from language-theoretic security. When you canonicalize a rich format, you are asking a program to fully recognize a complex input language, and that is not always a solvable problem.

For complex input languages, "the problem of full recognition of valid or expected inputs may be UNDECIDABLE, in which case no amount of input-checking code or testing will suffice to secure the program." -- LangSec [@langsec]

Read that carefully, because it is the ceiling on the entire canonicalization strategy [@langsec]. If deciding whether an input is well-formed can be undecidable for expressive grammars, then two independent parsers of such a grammar are not guaranteed to agree, ever, and no test suite can prove they do. Parser differentials like the 2025 REXML-versus-Nokogiri break are therefore not fully eliminable for rich formats [@cve-2025-25291]. Canonicalization can only ever be as trustworthy as the weakest recognizer that touches the document, and for a format like XML that recognizer is very complex indeed.

The third stone follows from the second: for genuinely rich formats, a universal canonical form may simply not exist. The JSON Canonicalization Scheme is instructive here, because even for the comparatively tame grammar of JSON it has to special-case string and number subtypes, spelling out in its Appendix E how stream- and schema-based parsers must treat numeric and date-like values so they do not diverge [@rfc8785]. Protocol Buffers refuses the goal outright: its documentation states the byte output is not stable across versions [@protobuf]. If the tamest formats need footnotes and the binary ones decline entirely, "just canonicalize everything" is not a general escape.

The fourth stone is the one this whole guide rests on. A signature can never carry meaning that the encoding does not pin down. The primitive authenticates a string of bytes; if those bytes admit two readings, the signature endorses both, and no cryptographic strength changes that. The gap between bytes and meaning is intrinsic to "authenticate bytes," not an implementation defect waiting for a patch.

So the reader who concluded, at the end of Section 5, "fine, we will just canonicalize everything and sign the exact bytes, and be safe" has to take one step back. Where you control the format and can sign the wire bytes, you really are safe from this class. Where you inherit a rich legacy format and must canonicalize a mutable tree, you are working under a proven ceiling, and the best you can do is shrink the attack surface, never close it. If that wall is real, the honest question is where this class is still failing today, and what, if anything, could move the wall even slightly.

9. Where It Is Still Failing

The settled parts of this subject are settled engineering. What follows is the honestly contested frontier, the places where a thoughtful designer in 2026 still has to make a judgment call.

Universal canonicalization for rich formats. JCS gives JSON a specified single form, but adoption is thin and its own Appendix E shows how many Unicode and numeric edge cases survive even for JSON [@rfc8785].A related canonicalization cousin bites one layer up, at identifiers: Unicode normalization and homoglyph folding decide whether two usernames that look identical on screen -- a Latin letter and its Cyrillic look-alike, or a name carrying an invisible combining mark -- resolve to the same account. Get it wrong and one byte string quietly impersonates another before any signature is even checked. For richer grammars there is no comparable standard, and Section 8 explains why there may never be one.

Is XML-DSig salvageable? The unbroken chain of wrapping and canonicalization CVEs from 2005 to 2025 is strong evidence, though not a proof, that the reference-by-Id model cannot be made safe by patching, and that new systems should not adopt it [@somorovsky-2012] [@cve-2025-25291]. Reasonable engineers still disagree about whether hardened SAML libraries can be trusted or must be phased out.

Parser-differential defense across trust boundaries. This is the deepest of the open problems, and the root of the 2025 GitLab bypass: any time two recognizers see the same bytes -- a proxy and an origin, a web application firewall and a backend, REXML and Nokogiri, an identity provider and a service provider -- they can disagree, and an attacker lives in the disagreement [@github-seclab-2025]. The same shape shows up one layer up as HTTP request smuggling [@kettle-2019] and JSON interoperability bugs from duplicate keys [@bishopfox-2020]. It is the systems-level restatement of the LangSec ceiling, and no one has a general defense.

The next three problems are less famous but more tractable, and each has real, partial progress worth understanding in detail.

Signing streamed, partial, or very large messages. Sign-the-encoding wants the exact transmitted bytes, but a streaming consumer must act on a prefix before the whole message, and its signature, even exist, and you cannot buffer a multi-gigabyte asset in memory just to canonicalize it. The state of the art is Merkle-tree or hash-chain signing: hash each chunk, build a tree over the chunk hashes, and sign only the root, so every chunk carries a logarithmic-size inclusion proof and verifies on its own.

C2PA deploys exactly this as its c2pa.hash.bmff.v3 assertion, a Merkle-tree hash over the ISO-BMFF mdat box, so fragmented or streamed media segments (fMP4, DASH, HLS) each verify independently against one signed manifest, itself a detached COSE Sign1 structure [@c2pa] [@rfc9052]. It is strong and shipping for content-addressed, chunkable data. What stays unsettled is a low-latency, exact-byte guarantee for arbitrary, non-chunkable streams: the guarantee is per chunk, not per message, and the chunk boundaries themselves become security-relevant.

Making typed and context binding the default rather than an add-on. Domain separation is almost always advisory. Most formats let a signature omit its type, context, or algorithm, so binding is something a careful designer remembers rather than something the format enforces. A minority get it right structurally: EIP-712 folds a type hash and a domain separator inside the signed bytes, $\texttt{0x1901} ,|, \text{domainSeparator} ,|, \text{hashStruct}(m)$, and TLS 1.3's CertificateVerify signs 64 fixed octets, a role-specific context string, a separator, and the transcript hash, so a signature made in one role cannot be replayed in another [@eip712] [@rfc8446].

JOSE is the cautionary opposite: it carries alg in-band, so the token still names its own verification rule, and RFC 8725 can only make binding a discipline -- enumerate algorithms, bind each key to one, reject none -- not a structural property [@rfc8725]. That is why alg:none keeps returning as a zombie default: RFC 7518 legalizes the none algorithm, and verification APIs historically read the algorithm from the token, so the insecure path is reachable out of the box on every fresh implementation [@rfc7518].

Formally verified parsers, serializers, and canonicalizers. For a fixed grammar, the only route past the LangSec ceiling is a machine-checked proof that a parser recognizes exactly its grammar, round-trips with its serializer, and is non-malleable, meaning each value has one accepted encoding. EverParse, presented at USENIX Security 2019, generates such parsers in the F* proof assistant and demonstrated them for TLS 1.0 through 1.3 in miTLS and for the ASN.1 DER payload of PKCS#1 RSA signatures [@everparse-2019]. The same line of work has since produced verified parsers for other network protocols, including QUIC [@everparse-quic], and has shipped inside the Windows kernel network stack, both steps beyond that original paper [@everparse-pldi-2022].

ASN1*, at CPP 2023, built a verified non-malleable DER parser on top of EverParse, giving the X.509 and PKI format its unique-encoding guarantee by proof rather than by convention [@asn1star-2023]. The catch matches the theory exactly: verified non-malleable parsers ship for constrained binary grammars, but a verified canonicalizer for a rich text format -- XML C14N, or JSON with the JCS Appendix E edge cases -- does not exist at industry scale, precisely as the no-universal-canonical-form limit predicts [@rfc8785].

Open problem	Why it matters	What has been tried	Best partial result
Signing streamed / very large messages	Sign-the-encoding needs the exact bytes, but you cannot buffer a multi-gigabyte stream to canonicalize it	Merkle-tree / chunk signing; C2PA Merkle-over-`mdat` with a detached COSE `Sign1` manifest	Solved for chunkable, content-addressed data; open for low-latency non-chunkable streams
Typed / context binding by default	Most formats leave domain separation optional, so designers forget it	EIP-712 and TLS 1.3 bind it structurally; RFC 8725 binds it by discipline	Structural in a few designs; still opt-in and zombie-prone in JOSE
Formally verified parsers and canonicalizers	Only a machine-checked proof escapes the LangSec ceiling for a fixed grammar	EverParse (F) and ASN1 verified non-malleable DER parsers	Ships for binary grammars; no industry-scale verified canonicalizer for rich text

You can apply the two-move lens to a report you have never seen. Find two things in the advisory: the *authenticated span* (which exact bytes did the signature or MAC cover?) and the *verification rule* (how did the code decide the check passed?). Then ask which one the attacker touched. If they changed which bytes get parsed, or made one byte string parse two ways, it is move one. If they moved the authenticated span, or talked the verifier into a different rule, it is move two. Almost every advisory in this family resolves in one sentence once you ask those two questions.

And then the callback that reframes everything. Suppose every system above had already migrated to post-quantum signatures, swapping RSA and ECDSA for ML-DSA (FIPS 204, module-lattice) or SLH-DSA (FIPS 205, stateless hash-based). How many of these breaks would that have prevented? Almost none. Flickr's length extension, alg:none, the RS256-to-HS256 confusion, and every SAML wrapping from 2005 to 2025 are all orthogonal to the signature algorithm: swap the primitive and the attack computes the same correct answer over the same wrong bytes [@fips204] [@fips205].

The two exceptions prove the rule. Bleichenbacher's 2006 forgery and BERserk are RSA e=3 malleability forgeries, and a non-malleable scheme -- RSA-PSS, or any strongly unforgeable (SUF-CMA) post-quantum signature -- already stops them, which is exactly why this article prescribed RSA-PSS as the BERserk fix; simply raising the public exponent to 65537 also denies the low-exponent construction its foothold [@rfc8017] [@valsorda]. Everything that remains is a bytes-not-meaning failure no algorithm transition can touch. That is the most important thing to carry out of this article, and it collapses the whole subject into one operational question, plus a checklist you can apply on Monday morning.

10. The Discipline, Made Operational

Everything above collapses into one decision procedure and one checklist of anti-patterns. Read the tree top to bottom and stop at the first rule that matches your situation.

flowchart TD Root["Choose the first rule that matches"] --> Start{"What are you authenticating?"} Start -->|Shared-secret integrity| M["Use HMAC or KMAC, never H of secret then message"] Start -->|You control the serialization| SE["Sign-the-encoding: JWS, COSE, TLS 1.3"] Start -->|Structure detached from the wire| CE["Canonical encoding: DER, dCBOR, JCS, then byte-compare"] Start -->|Binary or RPC such as protobuf| PB["Sign the exact received bytes or a hash of typed fields"] Start -->|XML or SAML| XM["Prefer not, if forced use one parser and verify the consumed element"] M --> Bind["Then always bind type, context, and algorithm"] SE --> Bind CE --> Bind PB --> Bind XM --> Bind

1. Shared-secret integrity? Use HMAC (RFC 2104) or a SHA-3-based KMAC. Never build a MAC as H(secret || m). If some constraint forces a bare hash, choose one that is not length-extendable: SHA-512/256 or the SHA-3 family [@rfc2104] [@bowes].

2. Do you control the serialization, and does the consumer parse exactly what you signed? Then sign the encoding: JWS, COSE, or the TLS 1.3 transcript, and you have closed move one by construction [@rfc7515] [@rfc9052] [@rfc8446].

3. Must you sign a structure detached from its wire bytes? Use a canonical encoding -- DER, deterministic CBOR (RFC 8949), or JCS (RFC 8785) -- and verify by re-encoding and byte-comparing, never by lenient parsing [@x690] [@rfc8949] [@rfc8785].

4. Binary or RPC payloads such as protobuf? Never sign freshly re-serialized bytes, because there is no canonical form. Sign the exact bytes you received, or sign a hash over explicit, typed fields with a domain separator [@protobuf].

5. Always, on top of rules 2 through 4, bind type, context, and algorithm. For JWT specifically: pin an explicit alg allow-list (prefer EdDSA or ES256), bind each key to exactly one algorithm, reject none in secured contexts, validate iss, aud, and exp, and treat header fields like kid, jku, and x5u as attacker-controlled, since they invite path traversal and server-side request forgery [@rfc8725].

6. XML or SAML? Prefer not, for new designs. If you are stuck with it, use a vetted and patched library, parse the document exactly once and verify the same element your application will consume, pin the schema, enforce Id uniqueness, disable DTD and external-entity processing, reject comments and stray whitespace inside security-relevant nodes, and never let two different parsers touch one signed document [@somorovsky-2012] [@duo-2018] [@cve-2025-25291].

7. RSA signatures? Prefer RSA-PSS. If you must verify PKCS#1 v1.5, re-encode the expected DigestInfo to strict DER and compare bytes, and never combine a public exponent of 3 with a lenient parser [@rfc8017] [@bleichenbacher-2006].

Note: Never share a single key across RS256 and HS256, and never let one key serve two algorithms. The RS256-to-HS256 confusion is alive precisely because a public key that is safe to publish becomes an HMAC secret the attacker also knows the moment the verifier lets the token pick the algorithm. Bind every key to exactly one algorithm [@rfc8725] [@mclean-2015].

Rule 5 is worth seeing as code, because the RFC 8725 discipline fits in a short function and every line closes one historical break. Note one easy-to-miss detail: a JWT segment is base64url, not standard base64, so decoding it with a raw atob on the segment is itself a latent bug.

{` // The header's "alg" is attacker-controlled. Never trust it -- pin your own set. const ALLOWED = new Set(["ES256", "EdDSA"]); // no RSA-or-HMAC ambiguity in the mix

// JWT segments are base64url, NOT standard base64: translate -_ to +/ and restore '=' padding. function decodeSegment(seg) { let b64 = seg.replace(/-/g, "+").replace(/_/g, "/"); while (b64.length % 4) b64 += "="; // base64url drops padding; put it back return JSON.parse(atob(b64)); // now standard base64 -> bytes -> JSON }

function verifyJwt(token, expected, keyForAlg, verifySignature) { const parts = token.split("."); const h64 = parts[0], p64 = parts[1], sig = parts[2]; const header = decodeSegment(h64);

if (header.alg === "none") throw new Error("alg none rejected in secured context"); if (!ALLOWED.has(header.alg)) throw new Error("algorithm not on the allow-list");

// Bind key to algorithm: one key, one alg. Never reuse a public key as an HMAC secret. const key = keyForAlg(header.alg); if (!key) throw new Error("no key bound to this algorithm"); if (!verifySignature(header.alg, key, h64 + "." + p64, sig)) throw new Error("bad signature");

const claims = decodeSegment(p64); const now = Math.floor(Date.now() / 1000); if (claims.iss !== expected.iss) throw new Error("wrong issuer"); if (claims.aud !== expected.aud) throw new Error("wrong audience"); if (typeof claims.exp !== "number" || claims.exp < now) throw new Error("expired or missing exp"); return claims; } `}

The other side of the guide is the mirror: every anti-pattern you will meet in real code maps one-to-one to a named break from the failure catalog. If you recognize the left column in a code review, you already know the fix.

Misuse pattern in real code	Maps to break	Fix
A MAC built as SHA-256 of secret then message	Flickr, 2009	HMAC or KMAC
Verifying an RSA signature by scanning for a DigestInfo	Bleichenbacher 2006, BERserk 2014	Re-encode to DER and byte-compare; RSA-PSS
Trusting the algorithm named in the JWT header	alg none, RS256/HS256, 2015	Allow-list; bind each key to one algorithm
Verifying one XML element and consuming another	On Breaking SAML 2012; ruby-saml 2025	One parser; verify the consumed element
Signing freshly re-serialized protobuf bytes	protobuf non-determinism	Sign received bytes or a typed-field hash
Two parsers touching one signed document	ruby-saml 2025, REXML versus Nokogiri	A single recognizer across the trust boundary

On Windows, the HMAC, hashing, and signing calls this guide keeps invoking are not abstractions; they live in a specific place in the platform (the CNG architecture behind BCrypt and NCrypt), and choosing the right one is the first line of every rule above.

Notice that every entry in both tables is the same rule wearing different clothes: make the bytes you authenticate be exactly the bytes you act on, and make them mean only one thing. Which is the single question this entire article has been walking toward, and the one worth pinning above your desk. Before that, a handful of misconceptions deserve to be named and corrected, because they are the folklore that keeps regenerating these bugs.

11. Misconceptions, Named and Corrected

The folklore around this subject is dense with half-truths, and each one causes real bugs. Here are the seven that do the most damage, every one of them dissolving into the two-move lens.

It is exactly the boundary where cryptography meets parsing, which is why it belongs in a cryptography field guide. The algorithm is always fine in these breaks; the attack surface is the *bytes* it was handed. Treating "the crypto" and "the parsing" as separate concerns is what lets the authenticated bytes drift from the consumed bytes in the first place. No to both. The vulnerable thing is the *construction* `SHA-256(secret || message)` used as a MAC, not the hash itself: SHA-256 is not broken, and HMAC-SHA256 is not length-extendable. Section 4 carries the full reason its fixed outer structure makes HMAC immune even though the tag can be resumed, and why truncated SHA-2 and the SHA-3 family are not susceptible either [@bowes] [@rfc2104]. Because it keeps coming back as a zombie default in new libraries, and because its more dangerous cousin, RS256-to-HS256 key confusion, is very much alive. Both are the same move: the message chooses its own verification rule. It recurs by default because RFC 7518 legalizes the `none` algorithm and verify APIs read the algorithm from the token, so the insecure path ships reachable [@rfc7518]. The durable fix is RFC 8725's discipline of an explicit algorithm allow-list and one key bound to one algorithm [@mclean-2015] [@rfc8725]. No. DER is the canonical form with exactly one legal encoding per value; BER is the permissive form that allows many [@x690]. Verifying a signature by accepting lax BER where the specification requires DER is not a shortcut, it is the BERserk vulnerability, which forged RSA signatures in shipping browsers in 2014 [@mfsa-2014-73]. No. Protocol Buffers' deterministic mode only guarantees stable output for a *particular* binary; the byte output can change across versions of your own software [@protobuf]. That is not a canonical form, so signing the serialized bytes remains undefined across versions. Sign the exact received bytes, or a hash over explicit typed fields, instead. Almost none of it. The only exceptions are Bleichenbacher's 2006 forgery and BERserk, RSA `e=3` malleability forgeries that any non-malleable scheme such as RSA-PSS already stops [@rfc8017]; every other break here is orthogonal to the algorithm, so a post-quantum swap computes the same correct answer over the same wrong bytes [@fips204] [@fips205]. Section 9 works through why, and the conclusion returns to it as the point the whole article turns on. No, and the distinction matters. Insecure deserialization is a code-execution topic: an attacker ships a serialized object that runs code when it is loaded. This family is about *data* whose bytes were authenticated ambiguously or bound loosely. Same word, "serialization," entirely different failure and fix.

Every one of these dissolves into a single sentence, and delivering that sentence with the full weight of the evidence behind it is the last thing left to do.

12. The Bytes Were Always the Wound

Line up the whole catalog. Flickr's forged API signature in 2009. Bleichenbacher's cube in 2006 and its rerun as BERserk in 2014. The alg:none bypass and the RS256-to-HS256 confusion in 2015. Every XML signature-wrapping forgery from McIntosh and Austel in 2005 through the ruby-saml parser differential that took over GitLab logins in 2025. Protocol Buffers used as a signing input it was never fit to be. In almost every one of those breaks, the algorithm computed exactly what it was asked to compute. The hash hashed correctly. The RSA verification did precisely what the math prescribes. The signature was valid. The message was forged.

Key idea: A post-quantum signature would have prevented almost none of these breaks. The two exceptions -- Bleichenbacher's 2006 forgery and BERserk -- are RSA e=3 malleability forgeries that a non-malleable scheme like RSA-PSS already stops, which only sharpens the point: everything else rode on the gap between the bytes that were authenticated and the bytes that were consumed, and a stronger, or quantum-resistant, algorithm computes the same correct answer over the same wrong bytes. The encoding gap is orthogonal to the algorithm [@fips204] [@rfc8017].

Part 1 of this guide opened on the same note from the confidentiality side: Bleichenbacher did not break RSA in 1998, and the RSA math was always fine (Secure Against Whom?). It is fitting that the same researcher bridges both parts, because it is the same lesson pointed at two different seams. Confidentiality failed when the environment handed an adversary an oracle the proof never modeled. Integrity fails when the serialization hands an adversary a second reading the signature never pinned down. The primitive is not the variable. The bytes are.

So carry one question out of all of this, and apply it the next time you sign, verify, or review anything: are the bytes I authenticated exactly the bytes I will act on, and can they mean only one thing? If yes, this entire family of attacks has nowhere to stand. If you are not sure, you have just found the wedge before an attacker did.

That question survives every algorithm transition the field will ever make. When today's signatures are replaced by their post-quantum successors, and those by whatever comes after, the lens will still read the breaks, because it was never about the algorithm. That is why serialization and canonicalization deserve a full part of a field guide for protocol designers, and not a footnote at the end of a chapter on hashing.

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.