Parag Mali - tag: aes

How AES Breaks in Real Life: The Attacks That Never Touched the Cipher

noreply@paragmali.com (Parag Mali) — Fri, 17 Jul 2026 00:00:00 GMT

**AES-the-cipher has never been broken in the field. Your AES traffic was decrypted anyway.** The best publicly known attack on the full cipher costs about $2^{126}$ operations for AES-128 -- its own authors say it does "not threaten the practical use of AES in any way" [@biclique-2011]. Yet real Wi-Fi sessions were decrypted, real HTTPS connections were forged, and real AES keys were lifted out of running servers. None of it touched the 128-bit block math. AES is a *permutation*, not a cryptosystem: to protect a message you wrap it in an *implementation*, a *mode*, and a *protocol*, and it was those three wrappers that failed -- a T-table lookup leaked the key through cache timing [@bernstein-2005; @osvik-shamir-tromer-2006]; 184 live HTTPS servers repeated an AES-GCM nonce and weaponized Joux's 2006 forbidden attack into forgery [@nonce-disrespecting-2016; @joux-2006]; and KRACK's replayed handshake rewound the AES-CCMP nonce and reused a keystream [@krack-2017]. Every fix changed *how AES is used*, never AES.

1. AES Is Unbroken. Your AES Traffic Was Decrypted Anyway.

The best publicly known attack on the full AES cipher costs roughly $2^{126}$ operations for AES-128 -- a number so far beyond feasible that its own discoverers wrote it does "not threaten the practical use of AES in any way" [@biclique-2011]. To put $2^{126}$ in scale: if every one of the billions of computers on Earth checked a billion keys a second, you would still wait longer than the age of the universe, many times over. By any honest measure, the cipher stands.

And yet, in the same decade that number was published, attackers decrypted live Wi-Fi sessions, forged authenticated HTTPS connections, and lifted AES keys straight out of running servers -- none of them going anywhere near that $2^{126}$ wall. How does a cipher nobody can break keep producing decrypted traffic and stolen keys?

The resolution is the thesis of this article, and you can hold it right now: none of these breaks touched the 128-bit block math. AES is a keyed permutation -- a function that scrambles one 16-byte block into another -- and nothing more. It is not a cryptosystem. To protect a real message you wrap that permutation in three things: an implementation that computes it on real silicon, a mode that chains it across a message, and a protocol that establishes keys and drives the mode. Each wrapper is a new, independent way to fail. And it was the wrappers, every time, that failed.

That gives you a diagnostic sentence to carry through the rest of this piece. When your encrypted traffic falls, the question is never "was AES broken?" It is: which layer around AES failed -- the implementation, the mode, or the protocol? By the end you will be able to drop KRACK, the GCM nonce scandal, and tomorrow's not-yet-published incident into that one question on sight.

To break AES in the field, you never touch AES. The table lookup leaks, the nonce repeats, the handshake rewinds -- and the 128-bit block math never moves.

This is Part 1 of How It Breaks in Real Life, a series with a single recurring claim: the primitive's mathematics almost never caused the break; the deployment did -- the nonce, the padding, key generation, a downgrade, a validation bug, or a deprecated-but-still-live algorithm. AES is the cleanest case, which is why it goes first. Its companion piece, How AES Would Break, asks what it would take to move the block itself: the key schedule, related-key cryptanalysis, the slow erosion of the security margin. That is the would-break-in-theory story. This is the did-break-in-the-field one.

If the cipher was intact and the block math never moved, then everything that broke was built around it. To see how "unbroken cipher" and "decrypted traffic" can both be true, you have to go back to what AES actually is -- and, more to the point, what it is not.

2. Why a Cipher Is Not a Cryptosystem

In October 2000, after a three-year open competition in which the world's cryptographers were invited to attack the candidates, NIST selected Joan Daemen and Vincent Rijmen's Rijndael as the Advanced Encryption Standard [@nist-press-2000]. The choice followed a public evaluation of fifteen submissions narrowed to five finalists, judged on security, performance, and efficiency from servers to smart cards [@nist-aes-dev; @nist-jres-r1-1999; @nist-jres-r2-2001]. That adversarial process is why the core math has held for over two decades -- and why, when things break in the field, the fault lies elsewhere. Winning the competition made Rijndael a cipher, not a cryptosystem.

Here is the distinction the whole article turns on. AES, standardized as FIPS 197 in 2001 and editorially refreshed in 2023 with no technical change to the algorithm, is a keyed 128-bit permutation [@fips-197]. It maps one 128-bit block to one 128-bit block under a 128-, 192-, or 256-bit key, and that is all it does.AES applies 10, 12, or 14 rounds for the 128-, 192-, and 256-bit keys. The round function is identical across all three; key size changes only the round count and the key schedule that feeds it [@fips-197]. It has no notion of a message longer than 16 bytes, no integrity, no session or conversation. Feed it the same block and key twice and you get the same output twice. On its own it cannot safely encrypt a paragraph, let alone a Wi-Fi session.

A **block cipher** is a keyed permutation on fixed-size blocks -- AES maps one 16-byte block to another under a key. A **mode of operation** (CTR, CCM, GCM, and others) is the wrapper that chains that permutation across an arbitrary-length message and, in authenticated modes, adds integrity. The block cipher is the engine; the mode is the car. You do not drive an engine.

To turn that engine into something that protects real data, you add three wrappers, and each one is a new, independent failure surface:

an implementation that computes the permutation on a real CPU, and may leak through timing or cache behavior;
a mode of operation that chains the permutation across a whole message and, in AEAD modes, adds integrity -- and imposes a contract on how you feed it nonces;
a protocol that establishes keys and drives the mode, and can mismanage them.

flowchart TD B["AES 128-bit permutation -- never broken in the field"] I["Implementation layer -- computes the block in code or silicon"] M["Mode layer -- chains the block, adds integrity, imposes a nonce contract"] P["Protocol layer -- establishes keys and drives the mode"] B --> I --> M --> P I -. break .-> AtkI["Cache timing leaks the key"] M -. break .-> AtkM["A repeated nonce reuses a keystream"] P -. break .-> AtkP["A replayed handshake rewinds the nonce"]

This map is the lens for everything that follows. The block sits at the center, untouched. The implementation wraps it, the mode wraps that, the protocol wraps that -- and the three field breaks in this article land on the three outer rings, in order, working outward from the silicon.

Note: AES has a 128-bit block size for all three variants; only the key is 128, 192, or 256 bits. When this article says "the 128-bit block math never moved," it means the block permutation, not the key. Hold onto a foreshadow: key size will turn out to be irrelevant to every break here. Against nonce reuse and a reinstalled handshake key, AES-256 fails exactly as fast as AES-128; against cache timing it is just as vulnerable, though a longer key takes proportionally more leakage to extract.

One more piece of honesty before we watch the wrappers fail. The series this article opens says the primitive's math almost never causes the break -- "almost," not "never" -- and the hedge is load-bearing.Every break in this article is independent of key size. That is not a rhetorical flourish; it is a literal property of cache timing, nonce reuse, and handshake replay, none of which involve guessing key bits.

Some deployed primitives genuinely fell as *math*, not deployment. DES died to brute force because its 56-bit key was too short, which is *why* NIST ran the AES competition in the first place. RC4's keystream biases were turned into real plaintext recovery against TLS [@alfardan-2013]. MD5 and SHA-1 fell to collision attacks -- the SHAttered project produced the first SHA-1 collision at roughly $2^{63}$ hash computations [@shattered-2017]. Those are real breaks of the primitive's mathematics. AES is simply not one of them, which is what makes its deployment-versus-primitive split so clean. Never harden "almost never" into "the math never breaks."

Three wrappers, three contracts, three ways to fail -- none of them the cipher. Before watching each one break in the field, you need to see the contracts up close: what a mode actually promises, what a nonce is, and why the humble table lookup is a loaded gun.

3. The Layers Around the Block, and the Contracts They Impose

Every one of the three field breaks is the violation of a single, specific promise. If you see the promise clearly now, the break will look obvious later. So here are all three contracts, one per layer, in order.

The implementation contract: a lookup should not leak what it looked up

Computing AES the naive way -- byte by byte through its S-box and its field multiplications -- is slow in software. So fast implementations fold an entire round into precomputed lookup tables. Four tables of about 1 KB each, conventionally called T0 through T3, turn each output column of a round into T0[a] XOR T1[b] XOR T2[c] XOR T3[d]: four reads and three XORs, so a full round is four of those -- sixteen reads in all [@bernstein-2005].

A set of precomputed lookup tables (typically four tables of 256 four-byte entries, about 4 KB total) that fold AES's SubBytes, ShiftRows, and MixColumns steps into a handful of table reads per round. It is purely a speed optimization. The block permutation it computes is identical to the slow version -- but *how* it computes it now depends on secret-derived indices.

The hidden assumption is that a table read takes the same time regardless of which entry you read. On a real CPU with a cache hierarchy, that is false: the first access to a memory line is slow, a cached line is fast, and an attacker can measure the difference. And the indices a, b, c, d are secret -- state bytes derived from the key XORed with the plaintext. So which table lines get touched, and therefore the timing, depends on the key. The implementation's contract is that a data-dependent lookup must not leak the data. The cache breaks it for free.

The mode contract: never repeat a (key, nonce) pair

A mode turns the one-block permutation into something that encrypts messages and detects tampering. Modern modes aim for AEAD.

Authenticated Encryption with Associated Data: a mode that provides confidentiality *and* integrity at once. It encrypts the plaintext and produces an authentication tag over both the ciphertext and some associated data (headers, sequence numbers) that is authenticated but not encrypted. GCM and CCM are AEAD modes; if the tag does not verify, the receiver rejects the message.

The workhorse construction is counter mode. AES is run on a counter to produce a keystream, and the keystream is XORed with the plaintext: keystream block $k_i = \mathrm{AES}_K(\text{nonce} \parallel i)$, and ciphertext $C_i = P_i \oplus k_i$. This is elegant and fast and fully parallel. It also carries one absolute obligation.

A **nonce** is a "number used once." In counter-based modes the pair (key, nonce) must be **unique for every encryption under that key**. The nonce need not be secret or random -- a counter is fine -- but it must never repeat. This is the single most load-bearing rule in practical symmetric cryptography, and it is the rule every mode-and-protocol break in this article violates.

Watch what happens if you break it. If two messages are encrypted under the same key and the same nonce, they get the same keystream. XOR the two ciphertexts and the keystream cancels:

$$C_1 \oplus C_2 = (P_1 \oplus k) \oplus (P_2 \oplus k) = P_1 \oplus P_2$$

The key never appears. The attacker who captures two same-nonce ciphertexts learns the XOR of the two plaintexts, and if they know or can guess one, they get the other -- with the cipher fully intact.

The failure that follows from a repeated (key, nonce) in a counter-based mode: identical keystream for two messages, so $C_1 \oplus C_2 = P_1 \oplus P_2$. The plaintext XOR leaks and the key is never touched. This one mechanic drives *both* the GCM break and the WPA2/CCMP break later in this article.

Key idea: A block cipher in a counter-based mode is a keystream generator. Feed it the same (key, nonce) twice and you get the same keystream, so $C_1 \oplus C_2 = P_1 \oplus P_2$ -- the plaintext XOR leaks and the key is never touched. The nonce-uniqueness contract is the one promise that stops this. Break it and the strongest cipher in the world protects nothing.

You can watch the cancellation happen. Nothing below is real AES -- the toy keystream stands in for AES-CTR output -- but the XOR algebra is exactly the algebra of the real break.

{` // Same (key, nonce) => same keystream for BOTH messages. That is the whole bug. const keystream = [0x9e, 0x37, 0xb1, 0xa4, 0x55, 0x0c, 0xd2, 0x6f];

function xorBytes(a, b) { const out = []; for (let i = 0; i < a.length; i++) out.push(a[i] ^ b[i]); return out; } const toBytes = (s) => Array.from(s).map((c) => c.charCodeAt(0));

const p1 = toBytes("ATTACK 0"); const p2 = toBytes("defend!!");

const c1 = xorBytes(p1, keystream); // what the attacker sees const c2 = xorBytes(p2, keystream); // what the attacker sees

const leaked = xorBytes(c1, c2); // C1 ^ C2, computed with NO key const truth = xorBytes(p1, p2); // P1 ^ P2, the secret relationship

console.log("C1 ^ C2 =", leaked.join(",")); console.log("P1 ^ P2 =", truth.join(",")); console.log("keystream cancelled?", JSON.stringify(leaked) === JSON.stringify(truth)); // Know one plaintext, recover the other. The cipher stayed perfectly strong. `}

GCM adds one more thing to worry about. Its integrity tag is built from a secret authentication subkey derived from the key alone, and a repeated nonce exposes that subkey to attack as well -- which is how confidentiality loss becomes forgery. We will pull that thread in the next section.

Even with perfectly unique nonces, GCM has a budget. With random 96-bit nonces, NIST caps a single key at fewer than $2^{32}$ invocations, because random 96-bit values begin colliding around the birthday bound [@sp-800-38d]. Uniqueness is not just a coding rule; it is a counting problem.

When AES-GCM came to TLS 1.2, RFC 5288 let the implementation choose part of each record's nonce -- an "explicit nonce" -- and its own security-considerations text carried a "Counter Reuse" warning that a repeated counter is catastrophic [@rfc-5288]. The contract was not merely implied; it was written down, in the same document that shipped the feature. A decade later, a scan of the live Internet found servers breaking it anyway.

The protocol contract: install a key once, so its nonce only ever counts up

A mode still needs a protocol to establish keys and supply nonces. WPA2's 4-way handshake derives a fresh Pairwise Transient Key, and AES-CCMP then encrypts each frame with a nonce built from an incrementing packet number; CCM, like GCM, forbids repeating that counter under one key [@sp-800-38c; @ieee-80211i-2004]. The assumption is simple and, on its face, obviously true: a key is installed exactly once, so the packet number only ever counts up and never rewinds.

Here are the three contracts side by side. Keep the last column in view -- it is the bill each violation runs up.

Layer	What it is	The contract it imposes	What a violation costs
Implementation	Code or silicon that computes the AES round	A data-dependent lookup must not leak the data	Cache/timing side channel recovers the key
Mode	CTR, GCM, CCM chaining the block across a message	The (key, nonce) pair must be unique per encryption	Keystream reuse leaks $P_1 \oplus P_2$; in GCM, forgery
Protocol	Handshake and key management driving the mode	A key is installed once, so its nonce only counts up	A reinstalled key rewinds the nonce, forcing reuse

Three contracts, each reasonable, each unenforced by the cipher -- the permutation cannot know whether you fed it a repeated nonce or read a leaky table. Which raises the only question that matters: in the real world, running on real servers and real routers, do these contracts actually hold? They do not. Here is where, when, and how each one broke.

4. Three Field Breaks, Three Layers, One Pattern

The comfortable belief is "we standardized a strong cipher, so our encrypted traffic is safe." What follows are three independent refutations of that inference -- one at each layer around the block, ordered by when the field break landed. Read them as a catalog, not a lineage: these are not ciphers that replaced one another but three simultaneous layers, every real deployment has all three at once, and the chronology is the attacker's frontier moving outward as each inner layer hardened.

timeline title From the silicon outward -- one pattern, three layers 2005-2006 : Implementation layer : Cache timing recovers AES keys (Bernstein, Osvik-Shamir-Tromer) 2016 : Mode layer : 184 HTTPS servers repeat a GCM nonce (Böck et al., weaponizing Joux 2006) 2017 : Protocol layer : KRACK rewinds the AES-CCMP nonce (Vanhoef and Piessens)

Generation 1: the implementation leaked (2005-2006)

In 2005, Daniel J. Bernstein did something the FIPS 197 math says is impossible: he recovered a full AES key remotely, over a network -- without breaking AES at all [@bernstein-2005; @bernstein-index]. The target was a server doing nothing but AES under clean timing conditions, so the demonstration was remote in principle rather than turnkey -- and alarming precisely because it was not purely local. It ran ordinary T-table AES, whose secret-dependent indices left the encryption's timing faintly correlated with the key; enough samples pinned the key bytes. A year later, Dag Arne Osvik, Adi Shamir, and Eran Tromer formalized the idea into two reusable cache attacks -- Prime+Probe and Evict+Time -- recovering keys with a modest number of encryptions on a shared machine [@osvik-shamir-tromer-2006].

Recovering a secret from the physical *side effects* of a computation -- its timing, its cache footprint, its power draw -- rather than from the algorithm's inputs and outputs. A cache-timing attack on T-table AES watches which cache lines the lookups touch; because the touched lines depend on key-derived indices, the access pattern leaks the key.

The mechanism is worth seeing as a chain, because every link is outside the cipher:

flowchart LR K["Secret index = key byte XOR plaintext byte"] --> L["Which T-table cache line is touched"] L --> M["Cache hit or miss changes measurable timing"] M --> R["Attacker narrows and then pins the key byte"]

You can feel the leak in miniature. A real CPU caches memory in lines of 64 bytes, so a 256-entry table falls into a handful of cache lines. The attacker never sees the secret index -- only which line was touched. Watch a single observation cut the keyspace:

{` // A CPU caches memory in 64-byte lines, so 256 one-byte table entries fall into // a few "cache lines." The attacker sees ONLY which line was touched -- not the index. const LINE = 64; const touchedLine = (index) => Math.floor(index / LINE);

const secretKeyByte = 0xB7; // unknown to the attacker const plaintextByte = 0x2A; // attacker-chosen, known const realIndex = secretKeyByte ^ plaintextByte; const observed = touchedLine(realIndex); // the only thing that leaks

// Which key bytes are consistent with the observed cache line? const candidates = []; for (let k = 0; k < 256; k++) { if (touchedLine(k ^ plaintextByte) === observed) candidates.push(k); } console.log("observed cache line:", observed); console.log("key-byte candidates remaining:", candidates.length, "of 256"); console.log("true key byte still in the set?", candidates.includes(secretKeyByte)); // One measurement: 256 -> 64. Vary the known plaintext, intersect the sets, and the byte falls out. `}

The insight is the sharpest edge of the whole thesis, so state it plainly.

Note: Cache timing recovers AES keys in the field -- that is real, and it is the reason "AES is unbroken" does not mean "your key is safe." But the leak lives in the T-table's memory-access pattern, not in the permutation. The table is a speed optimization; swap it for a leak-free implementation and the key stops leaking while the cipher stays byte-for-byte identical. Keys fall, the cipher stands. Keep that distinction sharp -- collapsing it is the reader's default error.

The fix pointed straight at the next era, and it changed how AES is computed, never what AES computes. Two responses followed: constant-time bitsliced software, which replaces the tables with data-independent boolean logic so no secret ever indexes memory [@kasper-schwabe-2009]; and, decisively, hardware AES-NI, which executes each round in silicon with no lookup tables and data-independent latency [@intel-aes-ni]. Once AES-NI reached mainstream CPUs in the early 2010s, this surface largely closed -- and the attacker's frontier moved one ring outward, to the mode.The formalization is due to Osvik, Shamir, and Tromer -- not Biham, a common misattribution [@osvik-shamir-tromer-2006].

Generation 2: the mode's contract was violated (2006, then 2016)

In June 2006, Antoine Joux submitted a public comment to NIST with a quietly devastating observation about GCM, now known as the "forbidden attack" [@joux-2006]. GCM, designed by David McGrew and John Viega, authenticates with a one-time polynomial MAC over the field $\mathrm{GF}(2^{128})$, keyed by a secret subkey derived from the encryption key alone [@mcgrew-viega-2004].

GCM's authentication secret, computed as $H = \mathrm{AES}_K(0^{128})$ -- the encryption of an all-zero block under the key. Every authentication tag is a polynomial in $H$ evaluated over the ciphertext, masked by $\mathrm{AES}_K(J_0)$ where $J_0$ comes from the nonce. Security depends on $H$ staying secret, which in turn depends on the nonce never repeating.

Joux's point: if a (key, nonce) pair repeats, the mask $\mathrm{AES}_K(J_0)$ is identical across the two messages, so the difference of their tags becomes a polynomial equation over $\mathrm{GF}(2^{128})$ whose unknown is $H$. Solve for the roots and you recover $H$; with $H$ in hand, you can forge a valid authentication tag for a message you chose -- universal forgery [@joux-2006]. The confidentiality loss from keystream reuse was already bad; this makes integrity fall too.

flowchart TD N["Same (key, nonce) used for two messages"] --> KS["Identical CTR keystream"] KS --> C["C1 XOR C2 equals P1 XOR P2, confidentiality lost"] N --> J["Identical tag mask AES_K of J0"] J --> EQ["Tag difference becomes a polynomial equation in H over GF(2 to the 128)"] EQ --> F["Roots reveal the subkey H, enabling forgery"]

For ten years this was a footnote -- a warning about a contract nobody, surely, would break. Then, in 2016, Hanno Böck, Aaron Zauner, Sean Devlin, Juraj Somorovsky, and Philipp Jovanovic scanned the Internet and found it broken in the wild [@nonce-disrespecting-2016]. Their paper, "Nonce-Disrespecting Adversaries," reported 184 live HTTPS servers actually repeating GCM nonces -- "which fully breaks the authenticity of the connections" -- among them large corporations, financial institutions, and a credit-card company, plus more than 70,000 servers using random nonces at volume risk.

They then did the thing Joux only described: they weaponized the repeats into working forgeries and injected content into live sessions. The root cause was mundane and entirely operational -- buggy hardware and firmware nonce generators, and counters that reset. The mode's assumption failed; AES did exactly what it was told.

Note: GCM will not stop you from repeating a nonce. Never generate a nonce you might repeat across process restarts, threads, forks, or virtual-machine clones and snapshots. A saved counter that resets to zero on restart is worse than useless -- it guarantees the reuse. AES-256 offers exactly zero protection here: key size is irrelevant to nonce reuse.

Two precisions keep this honest. First, the mechanism is layer-agnostic in the worst way: this is the same keystream-reuse atom from Section 3, now carrying a forgery payload because GCM's integrity also leans on the nonce. Second, resist the tempting overstatement.Precision lock. One nonce reuse is already a break: it immediately leaks $C_1 \oplus C_2 = P_1 \oplus P_2$ and gives one root-finding equation for $H$. But uniquely pinning $H$ for reliable universal forgery generally needs at least two collisions. Say "one reuse is already catastrophic, and more reuse pins the subkey" -- never "one reuse recovers the key" [@joux-2006]. The evidence for live reuse is the Böck et al. scan, five authors, 184 servers -- not the frequently miscited IBM Domino CVE [@nonce-disrespecting-2016].

The fixes, once again, changed the usage and left the cipher alone: nonce-misuse-resistant AES-GCM-SIV, where a repeat leaks only whether two messages were equal [@rfc-8452], and TLS 1.3's deterministic per-record nonce, which deletes the implementation-chosen "explicit nonce" that RFC 5288 had exposed [@rfc-8446]. As the mode hardened, the frontier moved one final ring outward -- to the protocol.

Generation 3: the protocol reused the nonce (2017)

WPA2's 4-way handshake exists to install a fresh key on both sides. The client installs its Pairwise Transient Key after message 3, and AES-CCMP then encrypts every frame with a nonce built from a packet number that only counts up. For reliability, the standard lets message 3 be retransmitted -- and there the trap was set. In 2017, Mathy Vanhoef and Frank Piessens showed that an attacker who captures and replays message 3 forces the client to reinstall a key it is already using, resetting the CCMP packet number and replay counter to their starting values [@krack-2017]. The nonce rewinds. The keystream repeats. This is KRACK: Key Reinstallation Attack.

Installing a key that is already in use. Because installing a key also initializes its associated nonce or packet-number counter, reinstalling an in-use key *rewinds* that counter to its starting value -- forcing the same (key, nonce) pairs, and therefore the same keystream, to be used again. KRACK triggers this by replaying a handshake message the protocol was willing to accept twice. sequenceDiagram participant C as Client participant A as Access Point participant M as Attacker A->>C: Message 1 (ANonce) C->>A: Message 2 (SNonce) A->>C: Message 3 (install key) Note over C: Installs PTK, packet number starts counting up C->>A: Message 4 (acknowledge) M->>C: Replay Message 3 Note over C: Reinstalls the same key, packet number resets to start Note over C,A: Nonce reused, keystream repeats, frames become decryptable

The insight is the same shape as before, delivered one layer further out: AES-CCMP did exactly what it was told. The permutation was flawless; the state machine told it to reuse a nonce, and it obeyed. The consequence is keystream reuse -- identical (key, nonce) yields $C_1 \oplus C_2 = P_1 \oplus P_2$ -- so a known-plaintext frame yields the keystream and decrypts the colliding frame.

Scope lock. Against AES-CCMP specifically, KRACK forces nonce-reuse decryption and replay -- not forgery and not AES key recovery. Forgery arises for the TKIP and GCMP cases, not CCMP. The especially devastating all-zero-key variant was an Android and Linux wpa_supplicant implementation bug that reinstalled an all-zero key, still not a break of AES [@krack-2017].

The fix was a backwards-compatible patch to the handshake state machine -- refuse to reinstall an in-use key -- shipped across Android, Linux, Apple, Windows, and OpenBSD in 2017 [@krack-2017]. Structurally, the Wi-Fi Alliance announced WPA3 in 2018 [@wifi-wpa3-2018]; its Personal mode swaps WPA2's pre-shared-key authentication for the SAE (Dragonfly) key exchange and mandates anti-reinstallation checks plus management-frame protection. The 4-way handshake still installs the pairwise key, so KRACK immunity comes from that mandatory hardening -- the same defense WPA2 received as a patch -- not from SAE removing the handshake [@dragonblood-2019]. The protocol changed. AES did not.

The pattern, seen all at once

Put the three side by side and the shape is unmistakable. Same violated contract in three costumes; same untouched block every time.

Incident	Year	Layer	Mechanism	Root cause	Fix (usage, not cipher)
Bernstein; Osvik-Shamir-Tromer cache timing [@bernstein-2005; @osvik-shamir-tromer-2006]	2005-2006	Implementation	Secret-dependent T-table indices leak via cache/timing	A data-dependent lookup leaks the data	Constant-time bitslicing; AES-NI
Joux forbidden attack; Böck et al. scan [@joux-2006; @nonce-disrespecting-2016]	2006, 2016	Mode	Repeated GCM nonce reuses keystream and exposes $H$	Buggy nonce generators break uniqueness	AES-GCM-SIV; TLS 1.3 derived nonces
KRACK [@krack-2017]	2017	Protocol	Replayed message 3 rewinds the CCMP nonce	State machine reinstalls an in-use key	Handshake patch; WPA3-SAE
Biclique baseline [@biclique-2011]	2011	The cipher itself	Best single-key attack: $2^{126.1}$ for AES-128	--	None needed -- "no practical impact"

Seen one at a time, these look like three unrelated bugs -- a cache thing, a TLS thing, a Wi-Fi thing. Seen together, they are a single pattern: every time, a contract around the permutation was violated, real traffic or keys fell, and the 128-bit block math did not move. That pattern is the whole point, and it is worth naming out loud.

5. The Fixes Changed How AES Is Used, Never AES

Stop treating the three incidents as separate stories. Line them up and one realization collapses the subject: every field break attacked a layer around the permutation, and every fix changed how AES is used -- never AES itself.

This is not a eureka discovery. It is an engineering discipline, and it is visible only because the same shape repeats three times across 2005, 2016, and 2017. Look at what each fix actually touched:

Implementation. Constant-time bitsliced code and hardware AES-NI compute the round with no data-dependent memory access [@kasper-schwabe-2009; @intel-aes-ni]. The tables are gone; the permutation they computed is unchanged.
Mode. AES-GCM-SIV makes a repeated nonce merely detectable rather than catastrophic -- a repeat leaks only whether two messages were equal, never the subkey $H$ [@rfc-8452]. TLS 1.3 derives each nonce deterministically from the record sequence number, deleting the footgun RFC 5288 had exposed [@rfc-8446]. The nonce plumbing changed; AES did not.
Protocol. The KRACK patch forbids reinstalling an in-use key, and WPA3 makes that anti-reinstallation defense mandatory (alongside management-frame protection) while swapping WPA2's pre-shared-key authentication for the SAE key exchange; the 4-way handshake persists, hardened rather than removed [@krack-2017; @wifi-wpa3-2018; @dragonblood-2019]. The state machine changed; AES did not.

Not one of these altered the block permutation. They hardened wrappers.

Key idea: The cipher is the fixed point around which everything else evolved. Every field break attacked a layer around the permutation, and every remedy -- constant-time and AES-NI, misuse-resistant AEAD and derived nonces, patched handshakes and WPA3 -- hardened a wrapper. Soundness requires the weakest of the three layers to hold, and hardening any one of them is an exercise in usage, not cryptanalysis.

There is a dynamic hiding in the chronology, and it is no coincidence. As AES-NI closed the implementation gap around 2010, the weakest remaining link -- the attacker's frontier -- moved to the mode, where the 2016 scan found it. As misuse-resistant modes and derived nonces closed that, the frontier moved to the protocol, where KRACK found it in 2017. The layers did not take turns being weak; the attacker simply always works the current weakest one. That is why "we use a strong cipher" was never the right unit of analysis. The right unit is the weakest wrapper you are still running.

This article is the *did-break-in-the-field* story. Its companion, *How AES Would Break*, is the *would-break-in-theory* one: the key schedule, related-key attacks such as the Biryukov-Khovratovich results on AES-256 that only exist in a related-key model correct deployments never create [@biryukov-khovratovich-2009], and the slow erosion of the security margin. Different question, different article. And the general craft of constant-time code, fault resistance, and key custody belongs to a third sibling on secure implementation. This piece links out to both rather than re-teaching them, because the point here is narrow and sharp: the wrappers broke, and the wrappers were fixed.

If every fix is a species of "use AES correctly," then the state of the art is just the catalog of what "correctly" means at each layer in 2026 -- and, tellingly, where even correct-by-the-book still is not quite enough.

6. What Correct AES Deployment Looks Like in 2026

The modern answer is unglamorous, and that is exactly the point: be sound at all three layers at once, because a hardened mode does nothing for a leaky implementation, and a constant-time implementation does nothing for a protocol that rewinds its nonce. Here is the correct-deployment endpoint, keyed to the three failure loci.

Implementation. Use hardware AES -- Intel and AMD AES-NI, or ARMv8's cryptographic extension -- which runs each round in silicon with no lookup tables and data-independent latency [@intel-aes-ni]. Where the CPU lacks AES instructions, fall back to a constant-time bitsliced software implementation that never lets a secret index memory [@kasper-schwabe-2009]. Mainstream libraries typically make this selection at runtime, preferring hardware AES with a constant-time fallback.

Mode. Use a vetted AEAD, never a hand-rolled chain of primitives. AES-GCM is the performance leader when you can guarantee nonce uniqueness -- either random 96-bit nonces kept under the NIST budget of fewer than $2^{32}$ invocations per key [@sp-800-38d], or TLS 1.3's deterministic per-record nonce derived from the sequence number [@rfc-8446]. Where uniqueness cannot be guaranteed, use AES-GCM-SIV, which survives a repeat gracefully [@rfc-8452].

An authenticated-encryption scheme that does not fail catastrophically when a nonce repeats. In an MRAE scheme such as AES-GCM-SIV, a repeated (nonce, message) pair leaks only the fact that the two plaintexts were identical -- never the keystream across distinct messages, never the subkey $H$. It is the provably strongest guarantee achievable once you admit that nonces sometimes repeat.

Protocol. At the link layer, patch WPA2 against key reinstallation or move to WPA3, which mandates anti-reinstallation checks and management-frame protection to close the defect while still running a 4-way handshake to install the pairwise key [@krack-2017; @wifi-wpa3-2018; @dragonblood-2019]. At the transport layer, prefer TLS 1.3 over 1.2: it deletes the explicit-nonce footgun and the downgrade and renegotiation hazards that made 1.2 fragile [@rfc-8446].

There is one caveat that keeps this from being a victory lap, and it is a good illustration of how deep the "usage" story goes.

Note: "AES-NI is constant-time by construction" is true by design intent, but on Ice Lake and later Intel cores, and Armv8.4-A and later, data-operand-independent timing -- including for AES instructions -- is only guaranteed when the processor's data-independent-timing mode is explicitly enabled [@intel-doit; @biggers-2023]. A constant-time algorithm is necessary but not sufficient for constant-time execution; part of the guarantee lives below your software, in a mode you now have to request.

The practical upshot is that "constant-time" has quietly become a setting rather than an assumption.On recent Intel cores the mode is called DOITM (Data Operand Independent Timing Mode); on Arm it is the DIT (Data-Independent Timing) processor-state bit. Eric Biggers raised the cross-vendor issue publicly in 2023, and it is the reason security-sensitive code on the newest silicon must ask for timing guarantees rather than inherit them [@biggers-2023; @intel-doit].

"Use a vetted AEAD, use hardware AES, patch your handshake" is the whole answer for greenfield code. But engineers inherit constraints -- a fixed nonce source, a distributed system that cannot coordinate a counter, a CPU with no AES instructions. So the real question is rarely "what is best." It is "what are my options, ranked, and exactly when does each one apply?"

7. Closing Each Gap: The Competing Defenses

At two of the three layers a practitioner actually has a choice, and the honest framing is a set of trade-offs, not a single winner. Take the two design spaces in turn.

The side channel: hardware AES-NI versus software bitslicing

These two coexist because they optimize different constraints. Where the CPU has AES instructions, AES-NI is the fastest option and constant-time by construction (subject to the DOIT/DIT caveat from the previous section) [@intel-aes-ni]. Where it does not -- older cores, small embedded parts -- constant-time bitsliced software gives a verifiable timing guarantee at the cost of speed and implementation effort [@kasper-schwabe-2009]. The one option that is never acceptable in security code is the original T-table implementation.

Dimension	T-table AES (broken)	Bitsliced constant-time software	Hardware AES-NI / ARMv8
Secret-dependent memory access	Yes (about 4 KB of tables)	None (boolean logic)	None (silicon datapath)
Timing side-channel resistance	Fails [@bernstein-2005; @osvik-shamir-tromer-2006]	Constant-time by construction	Data-independent by design; DOIT/DIT mode needed on Ice Lake+/Armv8.4+ [@intel-doit]
Throughput	Fast (pre-attack)	Good when blocks are batched	Fastest; line-rate AEAD
Block-parallelism needed	No	Yes (weak for a single block)	No
Hardware requirement	None	None	CPU AES instructions
Best suited for	Nothing security-sensitive	No-AES-NI or verifiable software	Everything with the instruction

The nonce: four live strategies

This is the design space where the 2016 scan drew blood, so it deserves the careful table. The four options trade nonce size, streaming ability, and misuse tolerance against each other.

Dimension	AES-GCM, random 96-bit nonce	AES-GCM, TLS 1.3 counter nonce	AES-GCM-SIV (MRAE)	XChaCha20-Poly1305
Nonce size	96-bit	96-bit (derived)	96-bit	192-bit
Passes	1 (streaming)	1 (streaming)	2 (buffered)	1 (streaming)
On accidental repeat	Catastrophic (leaks $P_1 \oplus P_2$; two collisions give $H$ and forgery)	Structurally prevented per connection	Graceful (leaks only message equality)	Catastrophic on a true repeat, but essentially never collides at random
Safe budget per key	Under $2^{32}$ messages [@sp-800-38d]	Per-connection sequence, no reuse if the counter is sound	Effectively unbounded against misuse	About $2^{96}$ random nonces before collision risk
Relative speed	Fastest (line rate)	Fastest	About 0.92 cpb on Broadwell, 14-19% slower than OpenSSL GCM [@gueron-lindell-2015]	Fast in constant-time software, no AES-NI needed
Primitive	AES	AES	AES	ChaCha20 (not AES)

Read the table as a decision, not a ranking. If you own a reliable per-connection counter, deterministic-nonce AES-GCM is both fastest and safe -- that is what TLS 1.3 does [@rfc-8446]. If you cannot guarantee uniqueness -- distributed writers, stateless functions, restart- or clone-prone systems -- AES-GCM-SIV is the provably strongest answer under misuse, at the price of a second pass and a buffered message [@rfc-8452; @rogaway-shrimpton-2006]. And if AES is not mandated and you just want "a random nonce is always safe," XChaCha20-Poly1305's 192-bit nonce makes accidental collision astronomically unlikely [@xchacha-draft] -- a different primitive, included as the most common answer to the nonce footgun rather than as an AES deployment.

Every option here changes how AES is used -- or swaps AES out entirely -- and each buys its safety with a specific cost: a pass, a throughput hit, a hardware dependency, a different primitive. Which makes the honest way to close the technical arc a question about limits: how little does the attacker actually need, and how much can the defender actually guarantee?

8. Theoretical Limits: What Is Provably True on Both Sides

The thesis has two sides, and each has its own provable frontier. The surprise is the asymmetry: the cipher side is essentially closed, and all the hard, unavoidable limits live in the deployment.

The cipher side: the math that did not break

Biclique cryptanalysis is the entire published erosion of the full-cipher security margin. Bogdanov, Khovratovich, and Rechberger reported the first single-key attacks on the full cipher at $2^{126.1}$, $2^{189.7}$, and $2^{254.4}$ for AES-128, AES-192, and AES-256 -- with no related-key assumption [@biclique-2011]. Against brute force at $2^{128}$, $2^{192}$, and $2^{256}$, that is a gain of at most roughly 1.6 to 2.3 bits: a factor of a few, not a factor that matters.A "bit" of security is a doubling of attacker work, so shaving 2 bits makes the attack about four times faster than brute force -- still astronomically far from feasible.

Metric	AES-128	AES-192	AES-256
Brute-force cost	$2^{128}$	$2^{192}$	$2^{256}$
Best known single-key attack (biclique)	$2^{126.1}$	$2^{189.7}$	$2^{254.4}$
Margin removed	about 1.9 bits	about 2.3 bits	about 1.6 bits
Practical threat	None	None	None
Relevance to the field breaks above	Zero	Zero	Zero

There is no proof that any attack on AES must cost as much as exhaustive search -- concrete block ciphers essentially never come with such a theorem -- so confidence rests on more than two decades of open cryptanalysis since the competition, not on an impossibility result [@fips-197]. But the reading is unambiguous, and the authors said it themselves.

The best known attacks on the full AES "do not threaten the practical use of AES in any way." -- Bogdanov, Khovratovich, and Rechberger, 2011 [@biclique-2011]

Notice the defender's column in the table never moves, and key size is irrelevant to every operational break in the sections above. The cipher side is, for practical purposes, a closed question.

The deployment side: where the real limits live

Now the asymmetry. Three provable boundaries constrain real systems, and none of them is about AES's strength:

The GCM birthday bound. With random 96-bit nonces, collision risk grows by the birthday bound, so NIST caps a single key at fewer than $2^{32}$ invocations [@sp-800-38d]. This is a structural limit of random-nonce GCM, independent of the cipher -- the mathematical reason "just use random nonces at massive scale" eventually fails.
The AEAD trilemma. No single scheme is simultaneously single-pass and line-rate, fully nonce-misuse-resistant, and large-nonce. GCM gives you the first, GCM-SIV the second, XChaCha the third-and-a-half; you cannot have all three at once [@rfc-8452]. And misuse-resistant AE is provably the strongest possible guarantee once nonces may repeat -- an attacker can always at least detect that the same message was encrypted, and a well-designed SIV scheme leaks nothing more [@rogaway-shrimpton-2006].
ISA-guaranteed whole-machine constant time is impossible in general. The instruction set does not, in general, promise data-independent instruction timing, so even AES and XOR instructions may be data-dependent on recent cores unless the timing mode is enabled [@intel-doit; @biggers-2023]. A constant-time algorithm cannot by itself guarantee constant-time execution; part of the guarantee lives below the software, and the general craft of getting it right is the subject of the secure-implementation sibling.

Key idea: The cipher-secure and system-secure claims are different, and the gap between them is inherent, not accidental. The cipher side has a negligible margin nibble -- under two bits. The deployment side has the real, provable limits: the GCM birthday bound, the single-pass / misuse-resistant / large-nonce trilemma, and the structural impossibility of ISA-guaranteed constant time. Key size buys nothing against any of them.

If the cipher side is closed and the deployment side has hard limits, then the live frontier is wherever those deployment limits are still being hit in the wild. That is not a solved problem. It is an active one.

9. Open Problems: Where AES Still Breaks in the Field

The cipher side is closed; the deployment side is not. Here are the places the same three-layer pattern is still live -- each an operational frontier, consistent with the thesis that the weakest link is the wrapper, not the block.

Guaranteeing nonce uniqueness in distributed, multi-writer, restart-prone systems. This is the exact gap that produced Generation 2: buggy counters and generators on 184 live servers repeated GCM nonces [@nonce-disrespecting-2016]. The best partial answer, MRAE via AES-GCM-SIV, makes a repeat detectable rather than catastrophic [@rfc-8452] -- but the single-pass, fully misuse-resistant, large-nonce scheme the trilemma forbids remains unrealized. In a world of stateless functions, cloned VMs, and shared keys across a fleet, "just keep a counter" is still an unsolved systems problem, not a solved one.

Cross-VM cache side channels in multi-tenant clouds. The 2005-2006 threat model assumed a shared physical machine; virtualization brought it back at scale. Irazoqui, Inci, Eisenbarth, and Sunar recovered AES keys across virtual-machine boundaries using Flush+Reload with memory deduplication [@irazoqui-2014]. Hardware AES removes the table channel, which is why AES-NI and constant-time code remain load-bearing in 2026.Even instruction timing can be data-dependent on recent cores unless the timing mode is enabled, so cloud tenancy keeps the Generation-1 question open even for hardware AES [@biggers-2023].

Fault and differential-fault attacks. Inducing a computation fault -- through voltage glitching, a laser, or rowhammer-style effects -- can recover an AES key from a handful of faulty ciphertexts [@piret-quisquater-2003]. This is again an implementation and hardware failure, not a cipher failure; the depth belongs to the secure-implementation sibling, but it is a live operational locus wherever an attacker has physical or near-physical access.

The long tail of devices without hardware AES. Constant-time software is slower than AES-NI, and the performance gap quietly tempts developers back toward leaky tables on the smallest parts [@kasper-schwabe-2009]. On many of those devices the pragmatic answer is to ship a constant-time stream cipher such as ChaCha20 instead of fighting AES's software side channels [@xchacha-draft].

Formal verification of protocol state machines, so the next KRACK is caught before it ships. TLS 1.3 was co-designed with formal analysis and has verified component implementations, such as those in the HACL* library [@hacl-2017]. Wi-Fi's SAE was not fully immunized: Dragonblood found downgrade, denial-of-service, and side-channel leaks the authors argue are "inherent to Dragonfly," and even patched software remained affected by a novel leak [@dragonblood-2019]. The state of the art at the protocol layer is better, not finished.

Every open problem here is the same sentence in new clothes: a contract around the permutation is hard to keep in the real world. Which means the practical guide almost writes itself -- it is the thesis made operational, each rule routed to the incident it prevents.

10. What to Do on Monday

Everything above collapses into a short decision procedure and a shorter list of nevers, each rule tied to the incident it prevents.

flowchart TD S["Deploying AES"] --> Q1{"CPU has AES instructions?"} Q1 -->|Yes| HW["Use AES-NI or ARMv8 crypto, enable timing mode on newest cores"] Q1 -->|No| CT["Use constant-time bitsliced software"] HW --> Q2{"Can you guarantee nonce uniqueness?"} CT --> Q2 Q2 -->|Yes| GCM["AES-GCM with deterministic nonces, TLS 1.3 style"] Q2 -->|No| Q3{"Is AES mandated?"} Q3 -->|Yes| SIV["AES-GCM-SIV, misuse-resistant"] Q3 -->|No| XC["XChaCha20-Poly1305, 192-bit nonce"]

The rules behind the tree:

Implementation. Use a library that selects AES-NI or ARMv8 crypto at runtime and falls back to constant-time software; never table-based AES in security code; on the newest cores, be aware the data-independent-timing mode may need to be requested [@intel-aes-ni; @intel-doit]. Prevents Generation 1: cache-timing key recovery.
Mode and nonce. Reliable per-connection counter, as in TLS or QUIC? Use AES-GCM with deterministic nonces [@rfc-8446]. Cannot guarantee uniqueness across restarts, threads, or clones? Use AES-GCM-SIV [@rfc-8452]. Want "a random nonce is always safe" and AES is not mandated? Use XChaCha20-Poly1305 [@xchacha-draft]. Never hand-roll a mode, and never choose your own explicit GCM nonce. Prevents Generation 2: nonce reuse and forgery.
Protocol. Patch WPA2 against key reinstallation or move to WPA3, keep clients updated, and prefer TLS 1.3 over 1.2 [@krack-2017; @rfc-8446]. Prevents Generation 3: handshake-driven nonce rewind.

The single highest-value check you can add to code review is a nonce-reuse detector. It is the exact contract the 184 servers violated, and it fits in a few lines.

{` // Scan a stream of (key, nonce) pairs and flag the first repeat. function findNonceReuse(records) { const seen = new Set(); for (const r of records) { const tag = r.key + "|" + r.nonce; if (seen.has(tag)) return { reused: true, key: r.key, nonce: r.nonce }; seen.add(tag); } return { reused: false }; }

const stream = [ { key: "k1", nonce: "00000001" }, { key: "k1", nonce: "00000002" }, { key: "k1", nonce: "00000001" }, // counter reset after a restart -- the bug ];

console.log(findNonceReuse(stream)); // { reused: true, key: 'k1', nonce: '00000001' } -- catch it in review, not in an incident. `}

Now hold each pitfall up to the mirror. Every one of these confident sentences reproduces a specific, named incident.

The confident mistake	The incident it reproduces	The fix
Table-based AES is fine in security code	Bernstein; Osvik-Shamir-Tromer cache timing [@bernstein-2005; @osvik-shamir-tromer-2006]	AES-NI or constant-time software
Repeating a nonce across restarts, threads, or clones is unlikely to matter	The 184-server GCM forgery scan [@nonce-disrespecting-2016]	AES-GCM-SIV or a disciplined counter
AES-256 is safer against these attacks	Every break here -- key size is irrelevant [@nonce-disrespecting-2016]	Fix the wrapper, not the key size
Constant-time source means constant-time execution	The DOIT/DIT timing caveat [@intel-doit; @biggers-2023]	Enable the timing mode where required
An unpatched WPA2 handshake is good enough	KRACK [@krack-2017]	Patch WPA2 or deploy WPA3

When you review encryption code, find where the nonce comes from and ask exactly one question: can this value repeat across a restart, a fork, a thread, or a clone? If you cannot prove it never repeats, you are reading a latent Generation-2 incident. Reach for AES-GCM-SIV or a 192-bit-nonce AEAD instead of arguing about how improbable a collision seems.

Note: 1. AES-NI or ARMv8 crypto, with a constant-time software fallback. 2. A vetted AEAD -- deterministic-nonce AES-GCM where a per-connection counter is reliable, AES-GCM-SIV where uniqueness is hard, XChaCha20-Poly1305 where AES is not mandated. 3. Patched WPA2 or WPA3, and TLS 1.3 over 1.2.

The checklist is short because the lesson is one sentence. Before restating it, clear the handful of confident, wrong sentences that keep this bug alive in design meetings.

11. Frequently Asked Questions

No. The best publicly known attack on the full cipher, biclique cryptanalysis, costs about $2^{126}$ operations for AES-128 -- a fraction-of-a-bit improvement over brute force with zero practical impact, and its authors say it does "not threaten the practical use of AES in any way" [@biclique-2011]. Every break in this article happened in a layer around the cipher, not in the cipher. Yes -- via cache-timing side channels [@bernstein-2005; @osvik-shamir-tromer-2006]. But that is *not* a break of the cipher. The T-table implementation's memory-access pattern leaked the key; the block permutation did not. Swap the leaky tables for a constant-time implementation and the key stops leaking while AES stays byte-for-byte identical. "Unbroken cipher" and "stolen key" are both true at once. Be precise here. One reuse immediately leaks $P_1 \oplus P_2$ through keystream reuse, and it gives one equation for the GHASH subkey $H$. But *pinning* $H$ for reliable universal forgery generally needs at least two collisions [@joux-2006]. One reuse is already catastrophic -- do not understate it -- but do not say "one reuse recovers the key" either. No. Every break here is implementation, mode, or protocol; key size provides no protection against cache timing, nonce reuse, or a reinstalled handshake key [@nonce-disrespecting-2016]. For the nonce-reuse and handshake breaks AES-256 fails exactly as fast as AES-128; for cache timing it is just as vulnerable, though a longer key takes proportionally more leakage to extract. If someone proposes AES-256 as the fix for any incident in this article, they have misdiagnosed the layer. No. Against AES-CCMP, KRACK forces nonce-reuse decryption and replay, not AES key recovery [@krack-2017]. The especially damaging all-zero-key case was an Android and Linux `wpa_supplicant` implementation bug, not a weakness in AES. No block-math weakness is involved, and no AES key is recovered by the attack itself. No. A padding oracle is a mode-and-validation failure in CBC deployments -- the receiver leaks whether decrypted padding was valid -- and it never touches the AES permutation. It is the same moral as this article (a wrapper broke), in a different deployment, and it is covered in a dedicated padding-oracle sibling. AES itself is not the weak link there either.

Every correction points at the same root: the cipher was never the weak link. Time to say the sentence the whole article was built to earn.

12. To Break AES in the Field, You Never Touch AES

Return to the paradox we opened with, now resolved. The best attack on the full cipher is a fraction-of-a-bit shave with no practical impact [@biclique-2011] -- and yet Wi-Fi sessions were decrypted, HTTPS connections forged, and keys lifted from running servers, because every one of those breaks happened in a wrapper the cipher knows nothing about. The implementation leaked through cache timing [@bernstein-2005; @osvik-shamir-tromer-2006]. The mode's nonce contract was violated on 184 live servers, weaponizing Joux's decade-old forbidden attack into forgery [@nonce-disrespecting-2016; @joux-2006]. The protocol rewound its nonce when a replayed handshake reinstalled a key [@krack-2017]. Three layers, three field breaks, and the 128-bit block math untouched in all three.

And every fix changed how AES is used, never AES: constant-time code and AES-NI at the implementation, misuse-resistant AEAD and derived nonces at the mode, patched handshakes and WPA3 at the protocol [@kasper-schwabe-2009; @rfc-8452; @rfc-8446; @wifi-wpa3-2018]. The cipher is the fixed point; the engineering happened all around it.

A cipher is not a cryptosystem. When your traffic falls, do not ask whether AES broke -- ask which wrapper did: the implementation, the mode, or the protocol.

One last honesty, because the series depends on it. The claim is "almost never," not "never." Scoped to AES, the split is pristine -- the block math never fell in deployment. But some deployed primitives genuinely broke as math: DES's 56-bit key, RC4's keystream biases [@alfardan-2013], and the MD5 and SHA-1 collisions [@shattered-2017]. AES has not joined them, and naming the cases where cryptanalysis won is what keeps the thesis honest rather than triumphant.

The cipher was never the weak link -- and no bigger key would have saved a single one of these systems. That is why this is Part 1 of a series about how things break in real life, not a chapter on block-cipher cryptanalysis. The companion piece, How AES Would Break, takes up the other question: what it would take to move the block itself. This one answered the question that actually decrypts traffic. It was never the cipher. It was the wrapper, every time.

The Fortress and the Afterthought: How AES Would Break at Its Key Schedule

noreply@paragmali.com (Parag Mali) — Fri, 17 Jul 2026 00:00:00 GMT

**AES is not broken -- but if it ever were, the crack would start at its key schedule, not its celebrated round function.** Twenty-five years of single-key cryptanalysis have plateaued near 7 of AES-128's 10 rounds, which is the wide-trail round function working exactly as designed. The only attacks that reach all rounds faster than brute force either target the linear key schedule directly (related-key attacks: full AES-256 at $2^{99.5}$, full AES-192 at $2^{176}$) or lean on its slow diffusion (the biclique attack: $2^{126.1}$ / $2^{189.7}$ / $2^{254.4}$, a meet-in-the-middle acceleration of brute force, not a pure key-schedule break). The security margin is a living, quantitative measure -- narrow in *rounds reached* under related keys, astronomically wide in *complexity* everywhere -- and the key schedule is where it is thinnest.

1. The Cipher That Guards the Internet

Every time you open a bank app, unlock a laptop, or load a padlocked website, you are trusting AES -- and in twenty-five years of public assault, no one has come close to breaking it in the way that would matter. It underpins TLS sessions [@rfc8446-tls13], the full-disk encryption on laptops and phones, secure messaging, and the tunnels inside most VPNs. So this article does not ask whether AES is broken. It isn't. It asks a sharper, more honest question: if it ever broke, where would the very first crack appear -- and the answer is not the part everyone admires.

The Advanced Encryption Standard was chosen in an open, international contest run by the U.S. National Institute of Standards and Technology between 1997 and 2001, precisely so the world's cryptanalysts could attack the candidates before one became the standard [@nist-aes-dev]. The winner, Rijndael, has since absorbed a quarter-century of that attention. Textbooks celebrate two of its parts above all: the S-box, a slice of finite-field algebra, and MixColumns, a diffusion layer with a provable mixing guarantee. If you asked most engineers where a future break might begin, they would point at that famous mathematics.

They would be pointing at the wrong place. The strongest results against full-round AES do not touch the S-box or MixColumns at all. They exploit the humblest component in the design -- the key schedule, the little routine that stretches your 128-, 192-, or 256-bit key into the sequence of round keys the cipher actually uses. It is fast, simple, and almost entirely linear, and it is exactly where every sub-brute-force full-round result lives or leans.

Key idea: The AES round function is the most-analyzed, most-trusted primitive in symmetric cryptography, and it has held. The key schedule is its least-designed, most-linear component. If AES ever falls, the accumulated evidence says the first crack starts there -- not at the celebrated mathematics, but at the afterthought bolted beside it.

That gap between "the best attack we have" and "trying every key" has a name, and it is the ruler this entire article uses.

The security margin of a cipher is the distance between the best known attack and brute force -- measured two ways at once: how many of the cipher's rounds an attack can reach out of the total, and how far below the $2^{n}$ cost of exhaustive key search the best full-cipher attack sits. A wide margin means attacks fall far short; a thin margin means they are creeping close. It is a living, quantitative number, not a binary "broken or safe."

One boundary before we start. This is a structural story -- about the mathematics of the algorithm itself. The attacks that actually steal data in the real world -- cache-timing side channels, fault injection, repeated GCM nonces, padding oracles, key-reinstallation attacks like KRACK -- never touch the cipher's math at all. Those belong to this article's empirical sibling; here, we stay inside the equations.

Note: Everything below analyzes cryptanalysis of AES's own mathematics: the round function and the key schedule. Side channels, fault and power attacks, implementation bugs, weak random number generators, and protocol or mode misuse are deliberately out of scope, named only to mark the edge. They are the subject of the sibling article in the companion series How It Breaks in Real Life.

To see why the key schedule is the suspect, you first have to see what the designers built -- and what they admitted they left cheap.

2. A Cipher Designed Against Its Own Attack

By the late 1990s the old standard was dying in public. In 1998 the Electronic Frontier Foundation built a purpose-made machine called Deep Crack and brute-forced a DES key in a matter of days, proving a 56-bit key was no longer enough [@eff-des-cracker].DES had been the U.S. standard since 1977 [@eff-des-cracker]. Deep Crack's public key recovery in 1998 was the exclamation point on years of warnings, and it set the clock ticking on the AES competition.

NIST's response was radical for a spy-adjacent agency: instead of designing a replacement behind closed doors, it announced an open, international contest and invited the world to break the candidates first [@nist-aes-dev]. Fifteen submissions were cut to five finalists -- MARS, RC6, Rijndael, Serpent, and Twofish -- and in October 2000 NIST named the Belgian design Rijndael the winner [@nist-round1] [@nist-press-2000].

The cipher is Rijndael, designed by Joan Daemen and Vincent Rijmen (the name blends theirs). AES is the specific profile NIST standardized: Rijndael restricted to a 128-bit block with 128-, 192-, or 256-bit keys. Cryptanalysts often say "Rijndael" for the general cipher and "AES" for the standard.

Here is the part of the story that plants this article's thesis. Daemen and Rijmen did not come to the contest cold. In 1997 they had co-designed an earlier cipher, Square, and -- unusually -- had published the strongest attack against it themselves: the Square attack, a structural technique that tracks a carefully chosen set of inputs through the cipher's byte operations [@square-fse97]. They arrived at the AES competition already knowing the best way to attack their own architecture, and they engineered Rijndael's round function specifically to resist it.

The tool they used was the wide-trail strategy, and it is the reason the round function has held for twenty-five years.

The wide-trail strategy is a design method that makes differential and linear attack paths ("trails") provably improbable by guaranteeing many active S-boxes. In AES, MixColumns has a *branch number* of 5, which forces any two consecutive rounds to activate at least 5 of the byte substitutions. Over four rounds this compounds to a provable minimum of 25 active S-boxes -- and since each S-box caps an attacker's differential probability at $2^{-6}$, no useful high-probability trail can stretch across the cipher [@design-rijndael].

The key schedule got the opposite treatment. Where the round function was engineered against a known attack with a provable bound, the key expansion was designed for speed and simplicity: enough structure to break symmetry between rounds and eliminate equivalent keys, and no more. It is built almost entirely from XOR and word rotation, with only an occasional column of S-box nonlinearity to break symmetry. The designers concentrated their genius on the round function and, by their own account, left the key schedule cheap. Twenty years later, peer-reviewed work put the consequence bluntly.

"The key schedule is arguably the weakest part of the AES." -- Gaëtan Leurent and Clara Pernot, EUROCRYPT 2021 [@leurent-pernot-eurocrypt21]

That asymmetry -- a fortress round function bolted to a lightly-built key schedule -- is the seed of everything that follows. The competition worked exactly as intended: Rijndael was chosen after the community failed to break it and the round function proved resilient [@nist-rijndael-report]. But "resilient round function" and "no weak spot anywhere" are different claims, and the next two decades of attacks would find the difference.

The whole arc, from the contest to the full-round results, fits on one timeline.

timeline title The structural cryptanalysis of AES, 1997 to 2021 1997 : Square cipher and the Square attack, Rijndael's ancestor 2000 : Rijndael wins, round-function attacks reach 6 to 7 rounds 2001 : FIPS 197 standardizes AES 2008 : Single-key meet-in-the-middle line begins, still short of full rounds 2009 : Related-key attacks reach full AES-192 and AES-256 2011 : Biclique, the only single-key full-round result 2021 : New key-schedule structure found after 20 years

The designers told us where they concentrated their effort, and where they did not. To understand why that choice matters, open the machine up and look at the four operations inside.

3. Where the Strength Is, and Where It Isn't

AES is four operations repeated ten to fourteen times. Three of them are among the most-analyzed primitives in cryptography. The fourth -- the one that stretches your key into round keys -- is the one nobody fortified.

Each round of AES transforms a 4-by-4 grid of 16 bytes through the same four steps [@fips197]:

SubBytes replaces every byte using the S-box, the cipher's only source of nonlinearity in the data path.
ShiftRows rotates the rows of the grid by different offsets, spreading bytes across columns.
MixColumns mixes each column through a fixed matrix so that one changed input byte disturbs all four output bytes.
AddRoundKey XORs in the round key for that round.

AES-128 runs 10 rounds, AES-192 runs 12, and AES-256 runs 14. The count grows with the key because a longer key means a longer key schedule and more round keys to derive.The original Rijndael also permitted 192- and 256-bit blocks, but AES fixes the block at 128 bits and varies only the key length. Throughout this article, "AES" means that fixed-block profile.

flowchart TD A["State: 16 bytes in a 4x4 grid"] --> B["SubBytes: S-box on every byte"] B --> C["ShiftRows: rotate each row"] C --> D["MixColumns: mix each column, branch number 5"] D --> E["AddRoundKey: XOR the round key"] E --> F["Next round"]

Two of these steps are why AES is trusted. The S-box is not an arbitrary lookup table; it is algebra.

The AES S-box maps each byte to its multiplicative inverse in the finite field $GF(2^8)$ (with zero mapped to zero), followed by a fixed affine transformation over the bits. The inversion supplies strong nonlinearity -- it caps the probability of any input-to-output difference at $2^{-6}$ -- while the affine step destroys the clean algebraic form that a pure inversion would leave behind, blunting algebraic attacks [@fips197] [@design-rijndael].

MixColumns is the diffusion partner. Its matrix is chosen so that changing a single input byte changes all four output bytes of the column.This is the maximum-distance-separable (MDS) property, summarized by a branch number of 5: the number of nonzero input bytes plus nonzero output bytes of MixColumns is always at least 5. It is what lets four rounds guarantee 25 active S-boxes, and it is unusually strong diffusion for such a cheap operation. Together, SubBytes and MixColumns make the round function mix so thoroughly that after just a couple of rounds every output bit depends on every input bit in a way no attacker has been able to shortcut. This is the fortress.

Now meet the protagonist. The key schedule -- the routine FIPS 197 calls key expansion -- is what turns your master key into the round keys that AddRoundKey consumes.

The AES key schedule expands the master key into one round key per round (plus one for the initial whitening). It processes the key in 32-bit words: most new words are simply the XOR of two earlier words, and once per group of words it applies RotWord (a byte rotation), SubWord (the S-box on four bytes), and a round constant Rcon to break symmetry. AES-256 adds one extra SubWord column at the midpoint of each eight-word group -- two nonlinear columns per group rather than one -- but even then the expansion is overwhelmingly linear, XOR and rotation [@fips197]. flowchart LR W0["Word w0 to w3: the master key"] --> N["Once per group: RotWord, then SubWord, then XOR Rcon"] N --> X["XOR into the next word"] W0 --> X X --> W1["Next four words: round key 1"] W1 --> Y["Mostly plain XOR of earlier words"] Y --> W2["Round key 2, and so on"]

Make the contrast visceral. The round function stirs the state with a nonlinear S-box on all 16 bytes and a strong diffusion layer, every single round. The key schedule stirs its state with XOR and rotation, and touches the S-box only four bytes at a time, once or twice per group of words.A 32-bit word is one column of four bytes, and SubWord runs the S-box on all four at once -- so one word and one S-box column mean the same thing here. One mixes with a sledgehammer; the other barely swirls.

That gap has a consequence worth holding onto: because the expansion is mostly linear, a difference injected into the key propagates through it predictably. If you know the difference going in, you can compute much of the difference coming out -- no probabilities required. Remember that when we reach the related-key attacks.

You can watch the slow, predictable diffusion yourself. The demo below injects a one-byte difference into a master key and follows it through the linear backbone of the expansion. Notice that the earliest words stay untouched, and that once the difference appears it propagates in a fixed, fully determined pattern rather than exploding into randomness the way the round function would scramble it.

{` // A deliberately simplified model of the AES key-expansion BACKBONE: // new word = previous word XOR the word four positions back. // (The real schedule adds one S-box column per group; we skip that // nonlinear part to expose why differences travel predictably.) const Nk = 4; // 128-bit key = 4 words const totalWords = 44; // 11 round keys of 4 words each

function expandBackbone(seed) { const w = seed.slice(); for (let i = Nk; i < totalWords; i++) { // linear step only: XOR of two earlier words w[i] = w[i - 1] ^ w[i - 4]; } return w; }

// Two master keys that differ in exactly ONE word (a single injected difference). const keyA = [0x00000000, 0x11111111, 0x22222222, 0x33333333]; const keyB = [0x00000000, 0x11111111, 0x22222222, 0x33333333 ^ 0x01000000];

const a = expandBackbone(keyA); const b = expandBackbone(keyB);

let firstTouched = -1, touchedCount = 0; for (let i = 0; i < a.length; i++) { const diff = a[i] ^ b[i]; if (diff !== 0) { touchedCount++; if (firstTouched === -1) firstTouched = i; } } console.log("Injected a 1-word difference into word 3."); console.log("First word carrying the difference: w" + firstTouched); console.log("Words disturbed out of " + totalWords + ": " + touchedCount); console.log("The difference is fully determined -- no guessing, no probability."); console.log("A real attacker exploits exactly this predictability."); `}

A fortress bolted to an afterthought. For years, no attacker seemed to notice the afterthought -- they all threw themselves at the fortress. Here is what happened when they did.

4. The First Cracks, at Four to Seven Rounds

The moment Rijndael became a finalist, the world's cryptanalysts opened fire. The first attacks worked -- and then hit a wall almost immediately, at a height that has barely moved since.

A reduced-round attack targets a version of the cipher with fewer than the full number of rounds -- say 6-round AES-128 instead of 10-round. Cryptanalysts study reduced-round variants because they are the natural way to measure the security margin: the highest round count you can break, compared with the full count, is a direct reading of how much cushion remains [@lu-idc-indocrypt08].

The opening salvo was the designers' own weapon, turned up to full power. Integral cryptanalysis -- the generalized Square attack -- does not chase a probabilistic pattern the way classical differential attacks do. It exploits a property that holds with certainty.

An integral attack feeds the cipher a structured set of plaintexts -- a "Lambda-set" of 256 texts in which one byte takes all 256 possible values and the rest are held constant -- and tracks the whole set at once. Because SubBytes is a bijection, an all-values byte stays all-values; the load-bearing invariant is that after a few rounds the XOR (over $GF(2^8)$) of all 256 intermediate states is provably zero, or "balanced." A wrong key guess in the final round breaks the balance, so the attacker keeps only guesses that preserve it [@square-fse97].

That balanced sum gives a 3-round distinguisher, which the Square attack extends by wrapping key-guessing rounds around it to break up to 6 rounds of AES at about $2^{72}$ work [@square-fse97]. The invariant is simple enough that a student can implement it in a few lines.

{` // A Lambda-set's active byte takes all 256 values exactly once. // Claim: after any bijective S-box, the XOR of all outputs is still 0. // This is the "balance" property the Square attack sieves keys with.

// Build a toy S-box: a random permutation of 0..255 (a bijection like AES's). const sbox = Array.from({length: 256}, (_, i) => i); for (let i = 255; i > 0; i--) { const j = Math.floor(Math.random() * (i + 1)); [sbox[i], sbox[j]] = [sbox[j], sbox[i]]; }

// Active byte: all 256 values. XOR them before and after the S-box. let xorInput = 0, xorOutput = 0; for (let v = 0; v < 256; v++) { xorInput ^= v; // XOR of 0..255 is 0 by construction xorOutput ^= sbox[v]; // a bijection just permutes those values } console.log("XOR of the active byte (input): " + xorInput); // 0 console.log("XOR after the bijective S-box: " + xorOutput); // still 0 console.log(xorOutput === 0 ? "Balanced: the distinguisher holds." : "Broken balance (won't happen for a bijection)."); `}

The Square attack's real bottleneck was not the distinguisher but the cost of the final key-guessing summation. In 2000, Niels Ferguson, John Kelsey, David Wagner and colleagues fixed exactly that with the partial-sums technique, reorganizing the summation to reuse intermediate results. It cut the 6-round work to roughly $2^{44}$ and bought one more round, reaching 7-round AES-128 at about $2^{120}$ using almost the entire codebook [@partial-sums-fse00]. The same year, Henri Gilbert and Marine Minier found a different route to the same height: a collision attack on 7 rounds of Rijndael that exploited collisions between partial functions inside the cipher [@gilbert-minier-aes3].

A third family arrived in parallel and turned differential logic inside out. Impossible-differential cryptanalysis of Rijndael originated with Eli Biham and Nathan Keller in an unpublished report at the Third AES Candidate Conference in 2000.That original Biham-Keller report was never formally published and is not indexed in the usual bibliographic databases, so this article attributes only the origin of the technique to it and takes every concrete figure from the peer-reviewed successors below. Precision about what is and is not on the record is part of honest cryptanalysis. Instead of a high-probability pattern, it uses one that occurs with probability exactly zero: AES has a 4-round differential that can never happen, so any key guess that would produce it is provably wrong and can be sieved out.

Jiqiang Lu, Orr Dunkelman, Nathan Keller and Jongsung Kim formalized and optimized the technique in 2008, as did Behnam Bahrak and Mohammad Reza Aref independently. It gave the best impossible-differential attacks of its era: 7 rounds of AES-128 and AES-192, and 8 rounds of AES-256 [@lu-idc-indocrypt08] [@bahrak-aref-iet08].

Step back and the pattern is unmistakable. Integral, partial sums, collision, impossible differential -- four different mechanisms, and every one of them targets the round function, and every one of them stalls far below the full 10 rounds. Around seven rounds, they all hit the same ceiling. Some of these are distinguishers (they tell real AES apart from a random permutation) and some are key recoveries (they actually extract key bytes), but the reach is the same either way.

Different attacks, one shared ceiling: about seven rounds. Was that a coincidence -- or was something stopping them?

5. Climbing the Round Ladder

For fifteen years the single-key attacks improved -- new mechanisms, cleverer bookkeeping, automated search. And still they stalled around seven rounds. The reason they stalled is the whole point of this article.

The next mechanism traded probability for memory. If the distinguishers of Section 4 were too short, why not store a description of several middle rounds rather than propagate a pattern through them?

A meet-in-the-middle attack splits the cipher into two halves and works from both ends toward the middle. The attacker precomputes every possible value of some property in the middle, then, for each key guess, computes the same property from the data and checks for a match. It trades memory for a way around the probability barrier that limits differential and integral attacks -- you look the answer up instead of hoping it appears [@demirci-selcuk-fse08].

In 2008, Hüseyin Demirci and Ali Aydın Selçuk built the first MITM attack on AES, reaching 8 rounds of AES-256 -- past the seven-round wall. But there was a catch that makes the plateau vivid: the precomputed table held on the order of $2^{206}$ entries [@demirci-selcuk-fse08]. That is not a time cost you wait out; it is more storage than exists on Earth. The attack was structurally valid and physically impossible at once -- a memory catastrophe.

Two years later, Orr Dunkelman, Nathan Keller and Adi Shamir rescued it. Their differential-enumeration technique restricted the precomputed table to only the middle states actually reachable from a chosen truncated differential, and a compact "multiset" representation shrank it further -- collapsing the impossible $2^{206}$ down toward the attack's own time complexity and turning a physical impossibility into a coherent shortcut for 8-round AES-192 and AES-256 [@dks-asiacrypt10].

Then, in 2013, Patrick Derbez, Pierre-Alain Fouque and Jérémy Jean treated the search for the best MITM parameters as a computer-search problem, automating the exploration to squeeze out the best single-key numbers anyone has found: 7-round AES-128 with data, time and memory all under $2^{100}$; 8-round AES-192 and AES-256; and 9-round AES-256 [@dfj-eurocrypt13].

Line the generations up and the shape of the wall becomes concrete.

Generation	Year	Rounds reached	The wall it hit
Integral / Square	1997-2000	up to 6	Cost of the final key-guessing summation [@square-fse97]
Partial sums	2000	7 (AES-128)	Distinguisher still only about 4 rounds long [@partial-sums-fse00]
Impossible differential	2000-2008	7-8	The impossible differential is fixed at 4 rounds [@lu-idc-indocrypt08]
Demirci-Selçuk MITM	2008	8 (AES-256)	A physically impossible $2^{206}$-entry table [@demirci-selcuk-fse08]
Differential-enumeration MITM	2010	8	Memory tamed, but still single-key, still 8 rounds [@dks-asiacrypt10]
Automated MITM	2013	7 / 8 / 9	No long single-key characteristic exists to extend [@dfj-eurocrypt13]

Fifteen years, five mechanisms, and the frontier climbs from six rounds to nine and stops. It is tempting to read that trend line as a slow slide toward a break -- seven rounds today, ten rounds soon. That reading is exactly backwards.

Key idea: The single-key plateau near seven rounds is not the attackers failing. It is the wide-trail round function succeeding. By provable design there is no long, high-probability characteristic to extend across the round function, so every single-key attack must bolt a few key-guessing rounds onto a short distinguisher -- and runs out of room. The plateau is evidence of strength, and it is precisely what forces every full-round result off the round function and onto the key schedule.

Not every idea in this era survived. The most famous casualty was an algebraic dream.

In 2002, Nicolas Courtois and Josef Pieprzyk proposed writing AES as a giant system of quadratic equations and solving it with a method they called XSL; a later GF(256) adaptation by Sean Murphy and Matthew Robshaw put the suggested attacks in the range of $2^{87}$ to $2^{100}$ [@xsl-eprint02]. It caused a stir -- an attack that ignored rounds entirely. But the method was heuristic, and its own authors admitted its complexity was "very difficult to evaluate." In 2005, Carlos Cid and Gaëtan Leurent analyzed XSL carefully and showed it did not work as claimed [@cid-leurent-xsl05]. The S-box's affine layer and field structure are part of why algebraic attacks have never dented AES.

If the round function cannot be beaten in the ordinary attack model, there are exactly two ways forward, and both leave the round function untouched. The first is to change the rules of engagement.

In the related-key model, the attacker cannot choose the secret key but *can* obtain encryptions under several keys whose differences it knows -- for example, the real key and the real key XORed with a chosen constant. It is a stronger, more demanding model than the standard single-key setting, and well-designed protocols never grant it. But it is a legitimate measure of a cipher's structural health, and it is the setting in which AES's key schedule first cracked [@bk-asiacrypt09].

The escape route through that model runs directly through the key schedule's linearity: because the expansion is mostly XOR, a difference injected into the key travels through it predictably and can be arranged to cancel a difference in the data over a few rounds -- a "local collision" that, chained, lets a usable characteristic span the entire cipher for the first time. The second escape gives up on beating brute force outright and instead accelerates it, with a structure called a biclique that leans on how slowly the key schedule diffuses. We will need one more idea for both roads.

A distinguisher is an attack that tells the real cipher apart from an idealized random permutation, without necessarily recovering the key. It is weaker than a key recovery, but it still counts as a structural break: an ideal cipher should be indistinguishable from random, so any efficient distinguisher proves the cipher deviates from the ideal. Distinguishers often precede full key-recovery attacks by years [@bkn-crypto09].

Both escapes were walked between 2009 and 2011. Neither one beat the round function. Both went for the key schedule.

flowchart TD S["AES cryptanalysis"] --> A["Single-key round-function line"] S --> B["Full-round results"] A --> A1["Integral, partial sums, impossible differential"] A1 --> A2["MITM and automated MITM"] A2 --> A3["Plateau near 7 to 9 rounds: the round function holding"] B --> B1["Related-key: local collisions in the linear key schedule"] B --> B2["Biclique: leans on slow key-schedule diffusion"] A3 --> K["The key schedule"] B1 --> K B2 --> K

6. Two Ways Past the Full Cipher

In 2009 and 2011, three papers did what nobody had managed in a decade: they reached all the way through AES faster than brute force. Neither road beat the round function. Both went for the key schedule -- one breaking it head-on, one leaning on it.

Road one: related-key attacks break the key schedule directly

The first road exploits the linearity you watched in Section 3. Because AES-256's key schedule is so close to linear, a difference injected into the key propagates through it predictably, and it can be arranged to cancel a difference that the round keys introduce into the data.

A related-key attack queries the cipher under keys whose differences the attacker knows. Its key tool against AES is the *local collision*: a difference introduced into the state by one round key is cancelled by a difference the linear key schedule carries into the very next round key, so the two differences annihilate over a short span. Because the schedule is mostly XOR, these cancellations are cheap to arrange and can be chained into a differential covering the whole cipher [@bk-asiacrypt09].

In 2009, Alex Biryukov, Dmitry Khovratovich and Ivica Nikolić delivered the first full-round result of any kind. They defined a differential q-multicollision and showed AES-256 admits them in about $q \cdot 2^{67}$ operations, against a provable lower bound of roughly $q \cdot 2^{((q-1)/(q+1)) \cdot 128}$ for an ideal cipher -- a gap wide enough to prove, in their words, that AES-256 "can not model an ideal cipher" [@bkn-crypto09].

From that they built the first attack on all 14 rounds: a related-key distinguisher working for 1 out of every $2^{35}$ keys using $2^{120}$ data, convertible to a key recovery at $2^{131}$ time and $2^{65}$ memory [@bkn-crypto09]. It was a weak-key-class result -- powerful, but not yet a universal key recovery.

Months later, Biryukov and Khovratovich closed that gap and extended it. Combining local collisions with the boomerang attack and a trick called boomerang switching -- which buys free middle rounds by reconciling two short differentials where they meet -- they produced a key recovery on the full AES-256 that works for all keys, at $2^{99.5}$ time and data, using four related keys [@bk-asiacrypt09]. The same machinery gave the first cryptanalysis of the full AES-192, at complexity $2^{176}$ [@bk-asiacrypt09].The paper notes the AES-256 figure improves to $2^{99}$. Two precision points that matter: the attack uses four related keys, and the $2^{99.5}$ (or $2^{99}$) number belongs to AES-256 alone. The full AES-192 result is $2^{176}$ -- never attach the AES-256 figure to AES-192.

Sit with what that means, because it inverts a near-universal assumption. AES-256 has more rounds and a longer key than AES-128, and everyone treats it as the stronger choice. Yet under related keys it is weaker: its longer key schedule is more linear structure to exploit, and no comparable all-keys full-round attack exists against AES-128. This is the thesis in its most literal form -- more key material bought more exploitable structure, and the longer key schedule breaks worse.

flowchart TD A["Attacker injects a known key difference"] --> B["Linear key schedule propagates it predictably"] B --> C["Round-key difference cancels the state difference: local collision"] C --> D["Chain local collisions across rounds"] D --> E["Boomerang switching joins two short trails, buys free middle rounds"] E --> F["Characteristic spans full AES-192 and AES-256"]

Road two: biclique leans on the key schedule's slow diffusion

The second road answers a different question. Related-key attacks need a strong model no protocol grants. Could anything reach the full cipher in the ordinary single-key model? In 2011, Andrey Bogdanov, Dmitry Khovratovich and Christian Rechberger answered yes -- with an important asterisk.

A biclique is a meet-in-the-middle structure that lets an attacker test a whole group of keys at nearly the cost of testing one. By precomputing partial encryptions over a few rounds and reusing them across every key in the group, it accelerates exhaustive key search: instead of a full encryption per candidate key, each key costs only the handful of operations that actually differ. It is not a shortcut around the cipher's mathematics -- it is a faster way to try every key [@biclique-asiacrypt11].

Applied to full AES with no related keys assumed, the biclique attack recovers keys at $2^{126.1}$ for AES-128, $2^{189.7}$ for AES-192, and $2^{254.4}$ for AES-256 [@biclique-asiacrypt11]. Those are the only single-key, full-round results faster than brute force that exist.

And here is where the savings come from: between neighboring keys in a group, so few round-key and state bytes change that most of the computation can be reused -- and that is a consequence of the key schedule's slow diffusion, the same sluggish mixing we watched in Section 3. Where the related-key road exploits the schedule's linearity, the biclique road exploits its slowness.

But the honest framing is load-bearing, and this article treats it as non-negotiable.

Note: The biclique attack is a meet-in-the-middle acceleration of exhaustive key search, not a pure structural break of the key schedule. Its recomputation savings depend on the key schedule's slow diffusion, but it does not exploit a mathematical weakness that collapses the cipher. The gain over brute force is about two bits -- a factor of roughly four. Never describe biclique as "breaking" the key schedule the way the related-key attacks do; it leans on the schedule, and that distinction is the difference between honest analysis and hype.

The authors said as much themselves, and it is the most important sentence in the whole biclique story.

The biclique attacks on full AES "do not threaten the practical use of AES in any way." -- Bogdanov, Khovratovich, and Rechberger, ASIACRYPT 2011 [@biclique-asiacrypt11] flowchart TD A["Partition the key space into groups"] --> B["Build a biclique over a few rounds per group"] B --> C["Precompute partial encryptions once per group"] C --> D["Neighboring keys differ in few bytes: slow key-schedule diffusion"] D --> E["Reuse precomputation, recompute only what changed"] E --> F["Each key costs less than one full encryption"] F --> G["Full-round key recovery, about a factor of 4 under brute force"]

Put the two roads side by side and the article's claim stops being rhetoric.

Key idea: The only two ways anyone has reached full-round AES faster than brute force both run through the key schedule. The related-key attacks break it head-on, chaining local collisions through its linearity to recover keys on full AES-192 and AES-256. The biclique attack leans on it, exploiting its slow diffusion to shave a factor of four off exhaustive search in the single-key model. The celebrated S-box and MixColumns are untouched in both. The crack starts at the part nobody fortified.

Two roads to the full cipher, both paved by the key schedule -- one breaking it, one leaning on it. So where exactly does AES stand today?

7. Where AES Stands Today

Strip away the drama and put the numbers on one table. That table is the clearest statement of where AES is strong and where it is thin.

Three ceilings orient everything: brute force costs $2^{128}$, $2^{192}$, and $2^{256}$ for the three key sizes. Every result below is measured against those.

Variant	Rounds	Best single-key reduced-round	Best single-key full-round	Best related-key full-round	Brute-force ceiling
AES-128	10	7 rounds, under $2^{100}$ [@dfj-eurocrypt13]	$2^{126.1}$ [@biclique-asiacrypt11]	none comparable known	$2^{128}$
AES-192	12	8 rounds, $2^{172}$ [@dfj-eurocrypt13]	$2^{189.7}$ [@biclique-asiacrypt11]	$2^{176}$ [@bk-asiacrypt09]	$2^{192}$
AES-256	14	9 rounds, $2^{203}$ [@dfj-eurocrypt13]	$2^{254.4}$ [@biclique-asiacrypt11]	$2^{99.5}$, improved to $2^{99}$ [@bk-asiacrypt09]	$2^{256}$

Read the columns and the whole argument snaps into focus. The single-key reduced-round column stalls at 7, 8, and 9 rounds out of 10, 12, and 14 -- and it has not moved since 2013 [@dfj-eurocrypt13]. The single-key full-round column sits about two bits under the ceiling, a factor of roughly four, courtesy of biclique [@biclique-asiacrypt11].Tao and Wu refined the biclique complexities in 2015, nudging the last digits and cutting the attack's storage requirement, but the headline numbers barely moved -- evidence that the single-key full-round margin has been essentially static for over a decade [@taowu-acisp15] [@wikipedia-aes]. The related-key column is the outlier: $2^{99}$ against a $2^{256}$ ceiling for AES-256 is an enormous complexity gap -- but only in a model real deployments deny.

The frontier keeps yielding small refinements, and where they land is telling. In 2018, Achiya Bar-On, Orr Dunkelman, Nathan Keller, Eyal Ronen and Adi Shamir cut the best 5-round single-key attack from about $2^{32}$ to under $2^{22}$ -- practical enough to run -- and gave the best practical-data attacks on 7-round AES-192 [@barron-crypto18].

And in 2021, Gaëtan Leurent and Clara Pernot found that the AES-128 key schedule can be split into four independent parallel computations on 32-bit chunks, up to linear transformation -- a structural fact, in their words, "not described in the literature after more than 20 years" of analysis [@leurent-pernot-eurocrypt21]. Twenty years on, the fresh cryptanalytic advantage still comes from the key schedule.

So the margin is asymmetric. In rounds reached, the related-key model gets uncomfortably close to full coverage while the single-key model plateaus a few rounds short. In complexity, the numbers are astronomically wide everywhere except the related-key AES-256 corner. And even that "best" single-key number is not remotely a threat.

Note: The biclique attack on AES-128 costs $2^{126.1}$ operations. That is faster than the $2^{128}$ brute-force ceiling -- and it is still roughly $10^{38}$ operations, a number with no physical meaning. If every atom-scale computer that could ever be built ran for the age of the universe, it would not make a dent. "Faster than brute force" is a statement about cryptographic bookkeeping, not about feasibility. AES is not close to breakable; it is close to optimal, and the tiny gap that remains is a ruler, not a wound.

One table, two full-round winners, one common thread. Line them up as competing methods and the thesis stops being a claim and becomes a pattern.

8. Single-Key, Related-Key, and the Common Thread

These attack families are not really competitors -- they optimize for different things. Put them on shared axes and you can see exactly what each one buys, what it costs, and what it leans on.

Attack family	Model	Full rounds?	Best complexity	Threatens deployed AES?	Leans on key schedule?
Biclique	Single-key	Yes (10/12/14)	$2^{126.1}$ / $2^{189.7}$ / $2^{254.4}$ [@biclique-asiacrypt11]	No	Yes, via slow diffusion
Related-key boomerang	Related-key	Yes (AES-192/256)	AES-256 $2^{99}$, AES-192 $2^{176}$ [@bk-asiacrypt09]	No, model denied	Yes, directly, via linearity
Single-key MITM (DS to DKS to DFJ)	Single-key	No (7/8/9)	7-round AES-128 under $2^{100}$ [@dfj-eurocrypt13]	No	Indirectly
Impossible-diff / integral (incl. Bar-On)	Single-key	No (7 or fewer)	5-round under $2^{22}$, practical [@barron-crypto18]	No	Increasingly

The two full-round rows and the two reduced-round rows tell opposite halves of the same story. The reduced-round families cannot cross the wide-trail wall no matter how cleverly they are automated or how practical their data becomes -- they top out short of the full cipher because the round function gives them nothing longer to work with.

The full-round families cross it only by refusing to fight the round function at all. One changes the model to attack the key schedule's linearity; the other accepts brute-force complexity and mines the key schedule's slow diffusion for a discount. Every entry in the "leans on key schedule?" column is a yes or a trending-toward-yes.

AES-256 has more rounds and a longer key than AES-128 -- and under related keys, that longer, still-linear key schedule is exactly what makes it weaker. More key material, more structure to exploit.

The honest caveat rides along in the table too. Biclique's "yes" in the last column is an enabling dependence -- it needs the schedule to diffuse slowly so its precomputation can be reused -- not the structural collapse that the related-key row represents. Reading the two together is the point: the key schedule is the common thread of every full-round result, but it is threaded two different ways, and only one of them is a direct break.

Not every result fits the key-recovery mould. In 2007, Lars Knudsen and Vincent Rijmen introduced *known-key distinguishers*, where the key is public and the goal is merely to show the cipher behaves less randomly than an ideal permutation would [@known-key-ac07]. It sounds academic, but it broadened what counts as "a break" and seeded the rebound attacks that are genuinely productive against AES-based hash and compression functions -- a reminder that a cipher can be perfectly safe as an encryptor while its internals still leak structure when repurposed.

The pattern is undeniable, but a pattern is not a proof. How close can cryptanalysis get -- and could we ever prove it can get no closer?

9. How Close Can Cryptanalysis Get?

Here is the uncomfortable truth that separates cryptography from mathematics: nobody can prove AES is secure. Not "has not proven it yet" -- cannot, even in principle, in the way we mean it for public-key systems.

RSA and Diffie-Hellman rest on the assumed hardness of a specific, well-studied problem -- integer factoring, or the discrete logarithm -- that the world's mathematicians have failed to solve efficiently for decades, and some public-key schemes (Rabin, or lattice systems) provably reduce to such problems. Their security is anchored to a famous open question. Block ciphers have no such anchor.

AES's security is not reducible to any problem believed hard; it rests entirely on the fact that very smart people have attacked it for twenty-five years and failed. That is strong evidence, but it is not a proof, and it means a future structural break can never be ruled out -- only measured, as a margin.

The nearest thing to a proof AES has is a design-level bound, and it is precisely bounded in what it covers.

Note: The wide-trail strategy proves that any differential or linear trail across four AES rounds activates at least 25 S-boxes, capping such a trail's probability at $2^{-150}$ [@design-rijndael]. That is a real theorem -- and it is exactly why single-key differential and linear attacks fail. But it bounds only trails through the round function. It says nothing about the key schedule, nothing about related-key differentials, and nothing about meet-in-the-middle accelerations like biclique. The one thing AES can almost prove is the one thing the round function already does well. The key schedule sits outside the theorem.

That gap is the article's most counterintuitive lesson. Security is not a binary a cipher passes or fails; it is a measured quantity, and the measurement keeps coming back thinnest at the key schedule. Worse for intuition: the AES-256-versus-AES-128 result shows that adding key material can lower the margin rather than raise it, because a longer linear key schedule is more structure to attack. The one genuine impossibility result we do have points the same way -- Biryukov, Khovratovich and Nikolić proved AES-256 cannot instantiate an ideal cipher, using the very key-schedule structure the related-key attacks ride [@bkn-crypto09].

What about quantum computers -- surely they change the answer? For AES, structurally, they do not.

Grover's halving is the main reason to prefer AES-256 for long-term or post-quantum margin -- not because AES-128 is structurally weaker, but because the larger key leaves a more comfortable margin against a generic quantum speedup.

Grover's algorithm gives a generic square-root speedup for key search: $2^{n/2}$ instead of $2^{n}$, so AES-128 drops to roughly $2^{64}$ and AES-256 to roughly $2^{128}$ [@grover-aes-pqcrypto16]. Crucially, that speedup is independent of AES's internal structure -- it applies to any cipher, treating AES as a black box. It does not touch the key schedule, the S-box, or MixColumns; it does not care how AES is built.

That is exactly why Grover sits outside this article's thesis: it is a generic key-search discount, not a structural break. And Shor's algorithm [@shor-siam97], which shatters RSA and elliptic curves, attacks the hidden-subgroup structure of public-key math and simply does not apply to symmetric ciphers.

Grover marks one edge of this article's territory: a generic speedup, not a structural crack, so it is named and set aside. The other edge is the entire world of real-world AES failures -- cache-timing side channels, fault injection, repeated GCM nonces, padding oracles, key-reinstallation attacks like KRACK. None of those touch the cipher's mathematics; they break the wrapper around it. They are the subject of the companion piece, *How AES Breaks in Real Life: The Attacks That Never Touched the Cipher*. This article is the would-break-in-theory story; that one is the did-break-in-the-field story.

No proof, a thin single-key margin, and a key schedule that keeps yielding fresh structure twenty years on. So what would it actually take to break AES?

10. What Would Actually Break AES

If you wanted to be the person who genuinely dented AES, here is the to-do list -- and why every item on it has resisted the field's best for more than a decade.

Close the single-key reduced-round gap. The frontier has sat at 7, 8, and 9 rounds since 2013, despite automated search tools purpose-built to push it [@dfj-eurocrypt13]. Nobody has extended the single-key attacks by even one round in over ten years. Either a genuinely new distinguisher is needed, or the round function really does leave nothing longer to exploit.

Migrate the key-schedule attacks into the single-key model. The related-key attacks reach the full cipher, but only under a model real protocols deny. Can their key-schedule insight be recast into an attack that needs no related keys? So far, no -- and this is the single most important open question for the thesis. If it ever happened, the crack really would start where this article predicts, in a model that matters.

Prove that a nonlinear key schedule would have mattered. Would a heavier, nonlinear key expansion have removed both the related-key local collisions and biclique's recomputation discount? There is strong circumstantial evidence it would: Leurent and Pernot's 2021 discovery that the AES-128 schedule still splits into four independent 32-bit computations shows the linearity keeps handing attackers structure two decades on [@leurent-pernot-eurocrypt21].

Find a real single-key shortcut on full AES-128. Not biclique's two bits -- an attack meaningfully below $2^{126}$ that reflects a structural weakness rather than an accounting trick. None is known.

Push the new structural distinguishers deeper. In 2017, Lorenzo Grassi, Christian Rechberger and Sondre Rønjom found an unexpected structural-differential property of 5-round AES, which Bar-On and colleagues then turned into the best practical 5-round attack [@grassi-eurocrypt17] [@barron-crypto18]. Can such properties reach 6, 7, or more rounds? So far they have not.

A secret-key distinguisher, like the Grassi-Rechberger-Rønjom 5-round property, does not extract a single key byte -- it only shows the cipher behaves less randomly than it should over a few rounds [@grassi-eurocrypt17]. That sounds harmless. But historically, distinguishers are the early-warning system: they reveal structure years before anyone works out how to convert it into a key recovery, and every family in this article began as a distinguishing property before it became an attack. Watching where new distinguishers appear -- and they keep appearing near the key schedule -- is how you predict where the next real attack will come from.

None of these five is close to solved. The standing challenge is stark: outside the related-key model, and beyond biclique's two-bit shave, nothing has meaningfully dented full-round single-key AES-128 in the entire history of its public analysis. Which is exactly why, for everyone who actually ships software, the right question is not "when will AES break?" but "what should I do today?"

11. What This Means for You

Strip all of it down to what changes your decisions. For almost everyone, the answer is: nothing -- and understanding why nothing changes is the real payoff.

AES is not broken. Every structural result in this article is astronomically infeasible, the strongest single-key full-round attack shaves a factor of four off a number no machine will ever reach, and the related-key attacks need access that correctly built systems never grant. Keep using AES.

On key size, choose deliberately rather than superstitiously. AES-128 and AES-256 are both effectively unbreakable in the single-key model your systems actually run in; the related-key paradox that makes AES-256 "weaker" lives entirely in a model deployments deny [@bk-asiacrypt09].

Prefer AES-256 when you want long-term or post-quantum margin, because Grover's generic square-root speedup halves the effective key length and a $2^{128}$ quantum margin is more comfortable than $2^{64}$ [@grover-aes-pqcrypto16]. Prefer AES-128 when you want raw speed and a post-Grover margin of $2^{64}$ is ample for your threat model. Both are sound; the choice is about margin, not about one being broken.

The one pitfall worth internalizing is the related-key boundary.

Note: Related-key attacks only bite if an attacker can influence the relationships between the keys you use -- for example, by driving AES as a hash or compression function where attacker-known differences flow into the key input, or a home-grown key-derivation scheme that XORs chosen constants into a master key. Use AES as a keyed black box under independent, well-generated keys, and the entire related-key family -- including the full AES-192 and AES-256 results -- simply does not apply. Independent keys are the whole defense.

You can make the margin tangible with a few lines of arithmetic. The calculator below reads the AES-128 single-key margin both ways the article measures it: as rounds reached versus total, and as the best full-round complexity versus the brute-force ceiling.

{` // Two ways to feel the margin, using the numbers from this article. const totalRounds = 10; const bestSingleKeyRounds = 7; // best single-key reduced-round (DFJ 2013) const bruteForceExponent = 128; // brute-force ceiling for AES-128 const bestFullRoundExponent = 126.1; // biclique (BKR 2011)

// 1) Round margin: how many full rounds still resist single-key attack. const roundMargin = totalRounds - bestSingleKeyRounds; console.log("Rounds still beyond the best single-key attack: " + roundMargin + " of " + totalRounds);

// 2) Complexity margin: how much "faster than brute force" biclique really is. const speedupFactor = Math.pow(2, bruteForceExponent - bestFullRoundExponent); console.log("Biclique speedup over brute force: about " + speedupFactor.toFixed(1) + "x"); console.log("Brute force itself: 2^128, roughly 1 followed by 38 zeros."); console.log("A 3.7x discount on a never-finishable computation is still never-finishable."); `}

Note: This article covered how AES would break in theory -- the mathematics of the cipher itself. The attacks that actually steal data break the deployment: the nonce, the padding, the key generation, a downgrade, a validation bug. If you want the field's real incident history, read the companion piece, How AES Breaks in Real Life: The Attacks That Never Touched the Cipher.

No. In twenty-five years of public analysis, no attack has come close to breaking full-round AES in any way that matters. The single strongest single-key result -- the biclique attack -- recovers an AES-128 key in about $2^{126.1}$ operations, a factor of roughly four below brute force and still on the order of $10^{38}$ operations, which is physically meaningless [@biclique-asiacrypt11]. Every other full-round result needs a related-key model that real systems deny. AES is not broken; it is close to optimal. Only in the related-key model, and only there. AES-256's longer, still-linear key schedule gives an attacker more structure, which is why a full-round related-key key recovery exists for AES-256 (about $2^{99}$) but no comparable full-round single-key break exists for AES-128 [@bk-asiacrypt09]. In the single-key model your deployments actually use, both are effectively unbreakable, and AES-256 gives you more post-quantum margin. The "paradox" is real cryptanalysis, not a practical warning. No. Its complexity for AES-128 is $2^{126.1}$ -- roughly $10^{38}$ operations -- and its own authors state the attacks "do not threaten the practical use of AES in any way" [@biclique-asiacrypt11]. Biclique is best understood as a precise *measurement* of the thin single-key margin, not a threat to it. It is a meet-in-the-middle acceleration of brute force, not a structural collapse. Not structurally. Grover's algorithm gives a generic square-root speedup for key search -- $2^{n/2}$ instead of $2^{n}$ -- so AES-128 drops to about $2^{64}$ and AES-256 to about $2^{128}$ of quantum security [@grover-aes-pqcrypto16]. That is a black-box discount independent of AES's internal design, which is why it is not a structural break; use AES-256 if you want the larger margin. Shor's algorithm [@shor-siam97], which does break RSA and elliptic curves, does not apply to symmetric ciphers at all. It is this article's well-motivated thesis, carefully bounded. The related-key attacks break the full cipher by targeting the key schedule's linearity directly [@bk-asiacrypt09]; the biclique attack leans on the key schedule's slow diffusion to accelerate brute force [@biclique-asiacrypt11]; and peer-reviewed work in 2021 still calls the key schedule "arguably the weakest part of the AES" [@leurent-pernot-eurocrypt21]. The honest caveat: biclique's dependence is enabling, not a pure structural break, so this is a synthesized argument, not a claim that every full-round result is a key-schedule attack. It is an attack in which the adversary obtains encryptions under several keys whose differences it knows [@bk-asiacrypt09]. It cannot happen unless your construction lets an attacker influence the relationships between keys -- which well-designed protocols never do. Use independent, well-generated keys and treat AES as a keyed black box, and the entire related-key family evaporates. It is a statement about a cipher's structural health, not a common deployment risk. Because "faster" here means a factor of about four below $2^{128}$ -- the difference between $2^{128}$ and $2^{126.1}$ [@biclique-asiacrypt11]. Both are numbers no computation will ever complete. In cryptography, "faster than brute force" is the technical bar for a result to count at all; it is a bookkeeping threshold, not a statement that the cipher is within reach of any attacker, now or ever.

Return to the question this article opened with: not whether AES is broken, but where the first crack would appear if it ever were. The evidence has answered it.

Key idea: The AES round function is the most-analyzed, most-trusted primitive in symmetric cryptography, and twenty-five years of single-key attacks have plateaued a few rounds short of it -- the wide-trail design working exactly as intended. Every full-round result faster than brute force lives somewhere else: the related-key attacks break the linear key schedule head-on, reaching full AES-192 and AES-256, and the biclique attack leans on its slow diffusion to shave a factor of four off exhaustive search. The S-box and MixColumns are untouched. If AES ever falls, the evidence says the first crack starts at the key schedule -- the least-designed, most-linear component -- bounded by the honest caveat that biclique leans on the schedule rather than breaking it.

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

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

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

1. Two Lines of Code

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

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

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

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

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

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

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

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

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

2. A Cipher That Only Speaks in Blocks

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. From CBC to CTR, Generation by Generation

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

CBC: chain the blocks

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

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

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

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

CFB: a self-synchronizing stream

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

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

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

OFB: a pre-computable stream

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

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

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

CTR: the parallel stream that wins

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Malleability Is the Real Bug

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Better still, fuse the two answers into one primitive.

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

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

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

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

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

6. The Field Is Retiring Confidentiality-Only Modes

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CBC versus CTR: a choice that changes nothing that matters

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

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

Which AEAD

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

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

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

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

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

8. You Cannot Get Integrity From a Confidentiality Mode

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

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

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

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

The second wall is the block size.

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

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

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

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

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

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

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

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

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

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

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

9. Where Modes Still Bite

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

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

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

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

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

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

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

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

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

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

10. Use X With These Params In Case Y

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

The decision guide, in priority order:

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

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

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

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

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

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

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

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

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

11. Misconceptions, Named and Corrected

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

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

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

Two Questions, Forty Years

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

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

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

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

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