Secure Against Whom? The Security Definitions Every Protocol Designer Needs

noreply@paragmali.com (Parag Mali) — Fri, 03 Jul 2026 00:00:00 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.

Parag Mali - tag: aead