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

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 ^[1]. 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 ^[1]. 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:

1. Can the attacker read it? That is confidentiality.
2. 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.

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 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 ^[2][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) ^[4]. The patent's actual title is "Message verification and transmission error detection by block chaining" ^[4]. 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 ^[5][6]. 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" ^[6]. 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 ^[5][6].

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 ^[7]. 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 ^[8].

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 ^[7][8]. 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" ^[6].

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 ^[1].

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

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 ^[9]. 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.

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

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 ^[9].

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 ^[6].

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" ^[6]. ※ 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 ^[6].

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 ^[6]. 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 ^[8]. 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 ^[12][13].

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 ^[6].

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 ^[6]. 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 ^[7][8].

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 ^[6]. Its contract is the simplest of all: the counter must be unique per key, and unpredictability is explicitly not required ^[9][6].

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:

The IV and nonce contracts are SP 800-38A's; the parallelism and malleability columns follow Rogaway's summary tables ^[8][6].

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):

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 ^[6][12]. Read as an evolution, the same five tell a story of steady improvement on every axis but one:

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 ^[6]. 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.

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 ^[9].

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.

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:

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 ^[22]. 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$" ^[23]. 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 ^[25][24].

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 ^[26][27].

Better still, fuse the two answers into one primitive.

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})$ ^[29][30]. CCM equals CTR plus CBC-MAC ^[31][32]. 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 ^[33][34]. 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 ^[35]. 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" ^[36]. 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" ^[11]. 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 ^[34]. "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 ^[37].

AES-GCM-SIV is engineered to be "nonce misuse resistant -- that is, [it does] not fail catastrophically if a nonce is repeated." -- RFC 8452

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 ^[28]; QUIC protects every packet with an AEAD, binding the packet number directly into the AEAD nonce, with no unauthenticated-confidentiality option at all ^[39].

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 ^[40][38]. The 2024-2026 standards are simply retiring the confidentiality-only modes to match a deployment reality that migrated years earlier.

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.

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 ^[6].

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 ^[30]. ChaCha20-Poly1305 is the software default: constant-time by construction, with no AES hardware and no cache-timing hazard ^[33]. AES-CCM is CTR plus CBC-MAC, two-pass and small-footprint ^[31][32]; those documents define CCM, and its compact profile is why the IEEE wireless standards adopt it -- WPA2 (802.11i) ^[40] and IEEE 802.15.4 low-power wireless ^[44][45] both build their link-layer security on it. AES-GCM-SIV is the nonce-misuse-resistant hedge ^[37]. Ascon is the lightweight standard for microcontrollers ^[34].

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 ^[40]. 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 ^[38]. 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.

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 ^[9]. 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 ^[26][27].

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.

"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.

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 ^[9][20]. 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 ^[30]. 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

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 ^[30]. 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" ^[38].

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 ^[35].

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 ^[47]. 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 ^[48]. The "invisible salamanders" attack built AES-GCM ciphertexts that decrypt to valid files under two keys, defeating message franking ^[49], a technique later generalized across file formats ^[47]. A genuine lower bound -- compactly committing AE is provably impossible at AES-GCM's exact performance profile ^[49] -- meets a cheap upper bound -- committing GCM and GCM-SIV variants at no ciphertext expansion ^[50]. 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 ^[17]. This is effectively solved on hardware with AES-NI and CLMUL, and ChaCha20-Poly1305 is constant-time by design ^[33]. 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 ^[28], and IR 8459 audits the whole series ^[35], 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.

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 ^[52].

The decision guide, in priority order:

1. 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 ^[30].
2. Cannot guarantee unique nonces: AES-GCM-SIV ^[37], or XChaCha20-Poly1305, which widens the RFC 8439 ChaCha20-Poly1305 construction to a 192-bit random nonce ^[33]. 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 ^[33]. The wider nonce is exactly what lets you pick nonces at random without tracking a counter.
3. No fast AES hardware, or you need constant-time software: ChaCha20-Poly1305 ^[33].
4. Constrained or IoT, small code budget: Ascon-AEAD128 ^[34] or AES-CCM ^[31].
5. Need key or context commitment (password-based encryption, franking, envelope, rotation): a committing AEAD ^[50].
6. 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 ^[8][26].
7. 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 ^[22][53][39].
8. 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:

Those requirements come straight from SP 800-38A ^[8]; 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:

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.

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 ^[1], Vaudenay's padding oracle ^[14], BEAST ^[16], Lucky Thirteen ^[17], POODLE ^[19], Sweet32 ^[21], Efail ^[12], and GCM nonce reuse ^[24]: 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 ^[35][34]. 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.