Chapter 6 of Trappe & Washington: block ciphers as keyed permutations, the Hill cipher and its determinant condition, and the five modes of operation — ECB, CBC, CFB, OFB and CTR — each with its own slide, its feedback path, its IV or nonce requirement and its error-propagation behaviour. Closes on multiple encryption and the meet-in-the-middle attack that reduces double encryption from 2^112 to roughly 2^57.
Subject: Cryptography · 60 slides · diagram-first lesson
Open the interactive version of this deck
Title
Cryptography · Chapter 6
Five modes of operation, the Hill cipher, and why double encryption buys one bit instead of fifty-six
Objectives
A block cipher encrypts exactly one block. Real messages are never exactly one block, and the rule for handling the rest turns out to carry most of the security. This chapter is about that rule.
Figure (svg): The five modes compared on chaining, whether padding is needed, error propagation, and whether they can be parallelised.
Warm-up
AES encrypts 128 bits. You have a 1 GB file.
Discussion prompt
Write down the obvious thing to do, then find the security problem with it.
Hint: The obvious thing is to chop the file up. Ask what happens when two chunks are identical.
Answer:
The obvious thing: split the file into 128-bit blocks and encrypt each one. That is ECB mode, and it is a real mode with a real name.
The problem: the cipher is deterministic, so equal plaintext blocks give equal ciphertext blocks. A 1 GB file has 67 million blocks, and in any structured file — a database, a bitmap, a document with repeated whitespace — a great many of them are equal.
So the ciphertext reveals the file's pattern of repetition, which for an image is the image. This is Chapter 2's substitution-cipher lesson at block granularity, and it is Chapter 4's indistinguishability failure: encrypt the same block twice, get the same output, lose the game.
Everything else in this chapter is a way of making equal plaintext blocks produce different ciphertext blocks.
Section
Section 6.1 · pp. 118-119
Concept
A block cipher collects a fixed number of bits — 64 for DES, 128 for AES — and transforms the whole block at once under the control of a key.
\[ E_K : \{0,1\}^{n} \to \{0,1\}^{n}, \qquad D_K = E_K^{-1} \]
Because decryption must recover the plaintext exactly, E_K has to be a bijection on the set of n-bit blocks — a permutation of all 2ⁿ of them. That is not a design choice; it follows from Chapter 4's correctness requirement.
So a block cipher with a k-bit key is a way of selecting 2^k permutations out of the (2ⁿ)! that exist. For AES that is 2¹²⁸ chosen out of an unimaginably larger set, and the design question is whether the chosen ones look like a random selection.
Figure (svg): A block cipher as a keyed permutation: a fixed-size block in, the same size block out, under the control of a key.
Notation
The signature contains more information than it looks, and three of this chapter's problems are visible in it.
Annotate
On: \( E : \{0,1\}^{k} \times \{0,1\}^{n} \to \{0,1\}^{n} \)
Every mode in this chapter is a way of supplying the randomness the signature does not have room for.
Definition probe
The distinction decides which problems you inherit.
Sort into buckets
Sort each property.
Intuition
A block cipher needs whole blocks, and messages are not whole blocks. So the last block is padded, and the receiver strips the padding after decrypting.
The usual scheme, PKCS#7, appends n bytes each equal to n. One missing byte means one byte 01; five missing bytes means five bytes 05 05 05 05 05. A message that already fills a block gets an entire extra block of 10 bytes, so that stripping is always unambiguous.
Here is the hole. The receiver must check the padding, and if it is malformed the natural thing is to report an error. But that error is a one-bit oracle about the decryption of an attacker-chosen ciphertext — which puts the system in Chapter 1's chosen-ciphertext model without anyone deciding to.
Given that oracle, an attacker recovers the plaintext byte by byte, with about 256 queries per byte and no key recovery at all. That is the padding oracle attack, and it has broken TLS, ASP.NET and many others.
Figure (svg): PKCS#7 padding filling the final block, and the error message that turns padding validation into a decryption oracle.
Section
Section 6.2 · pp. 119-122
Concept
Invented by Lester Hill in 1929. The book is candid that it seems never to have been used much in practice — its significance is that it was perhaps the first time algebraic methods were used in cryptography in an essential way, and algebra now occupies the centre of the subject.
Choose n, say 3. The key is an n × n matrix M with entries mod 26. Write the message as row vectors of n letters and multiply.
\[ (0,\;1,\;2) \begin{pmatrix} 1 & 2 & 3 \\ 4 & 5 & 6 \\ 11 & 9 & 8 \end{pmatrix} \equiv (0,\;23,\;22) \pmod{26} \]
Decryption needs M to be invertible mod 26, which by Section 3.8 means gcd(det M, 26) = 1 — the affine cipher's condition, one dimension up.
Figure (svg): The Hill cipher encrypting the vector 0, 1, 2 by a three by three matrix mod 26 to give 0, 23, 22.
Worked example
The book's own example, with M as above.
Convert abc to the row vector (0, 1, 2)
Why: a = 0, b = 1, c = 2, using Chapter 2's letter numbering.
First component: 0·1 + 1·4 + 2·11 = 0 + 4 + 22 = 26 ≡ 0 (mod 26)
Why: The vector multiplies the matrix on the right, so this component uses the matrix's first column.
Second: 0·2 + 1·5 + 2·9 = 5 + 18 = 23
Why: Which is the letter X.
Third: 0·3 + 1·6 + 2·8 = 6 + 16 = 22
Why: Which is W.
\[ \texttt{abc} \;\longmapsto\; (0, 23, 22) = \texttt{AXW} \]
Verify: the first letter came back as a, unchanged
Why: The book flags this explicitly: it is a random occurrence, not a defect of the method. A block cipher is a permutation of blocks, and a permutation may fix a point — it is the whole block that must be unpredictable, not each letter within it.
Figure (svg): The Hill cipher encrypting the vector 0, 1, 2 by a three by three matrix mod 26 to give 0, 23, 22.
Worked example
To decrypt we need N with MN ≡ I (mod 26).
Compute det M = 1(5·8 − 6·9) − 2(4·8 − 6·11) + 3(4·9 − 5·11)
Why: Expanding along the first row.
= 1(40 − 54) − 2(32 − 66) + 3(36 − 55) = −14 + 68 − 57 = −3
Why: So det M = −3 ≡ 23 (mod 26).
Check gcd(23, 26) = 1, so the inverse exists
Why: If this failed, M would be an illegal Hill key — the same condition that made α = 13 illegal in Chapter 2.
Find the inverse of −3 mod 26: 23 · 17 = 391 = 15 · 26 + 1, so 17 works
Why: The extended Euclidean algorithm of Section 3.2. The book uses 17 in place of −1/3.
Verify: N = 17 · adj(M) mod 26, and MN ≡ I
Why: Multiplying the adjugate by 17 and reducing gives the decryption matrix. Always multiply back — a sign slip in a 3 × 3 adjugate is otherwise silent.
Figure (svg): The determinant condition for a Hill key: gcd of the determinant with 26 must be 1.
Translation
The five modes differ in one line each. Fluency with these five lines is most of the chapter.
Match the pairs
Why: CFB and OFB differ in exactly one symbol — what shifts into the register, Cⱼ or Oⱼ — and every difference between them follows from it. Feed back the ciphertext and the keystream depends on the message, so errors propagate and the keystream cannot be precomputed; feed back the output and it does not, so they cannot. One character of difference, and two different modes with different use cases.
Socratic
The Hill cipher is linear, and Chapter 5 has just shown what linearity costs.
Discussion prompt
Eve knows some plaintext blocks and their ciphertexts. How many does she need to recover an n × n key, and how does she do it?
Hint: Each known block gives you one equation in the matrix's entries — but a vector equation, not a scalar one.
Answer:
She needs n known blocks. Each plaintext block p with ciphertext c gives the vector equation pM ≡ c (mod 26) — n scalar equations in the n² unknown entries.
Stack n of them. Write the plaintext blocks as the rows of a matrix P and the ciphertexts as the rows of C. Then PM ≡ C, so M ≡ P⁻¹C (mod 26), provided P happens to be invertible mod 26 — and if it is not, she takes a different set of blocks.
For n = 3 that is nine known letters. The cipher's key space is enormous — the number of invertible 3 × 3 matrices mod 26 — and completely irrelevant, exactly as in Chapters 1, 2 and 5.
The pattern is now familiar enough to state as a rule: anything linear in the key or the state falls to a linear system whose size is the state, not the key space. It killed the affine cipher, the LFSR, and the Hill cipher, and it is why every serious block cipher from Chapter 7 onwards is built from deliberately non-linear components.
Fill the middle
Complete the condition and the recovery formula.
Fill in the blanks
\textdet M \iff \gcd\bigl(P⁻¹C,\, 26\bigr) = 1, \qquad \text___ M \equiv ___ \pmod___
Why: Invertibility mod 26 requires the determinant to be coprime to 26 — the same condition as everywhere else in this course, because it is the same fact: an element of Z/26 is invertible exactly when it shares no factor with 26. And the attack is the encryption relation solved the other way round, which is available precisely because the encryption is linear.
Error analysis
From a student's project write-up.
Annotate
The correct summary: the Hill cipher is of historical importance and is broken by known plaintext proportional to its block size.
Section
Section 6.3 · pp. 122-129
Concept
A bank sends a terabyte between branches. A terminal must produce ciphertext as fast as a user types single characters. The same block cipher has to serve both, and the mode of operation is what adapts it.
Figure (svg): The five modes compared on chaining, whether padding is needed, error propagation, and whether they can be parallelised.
Concept
Break the plaintext into blocks and encrypt each separately.
\[ C_j = E_K(P_j), \qquad j = 1, \ldots, L \]
The book's account of the weakness is worth following precisely, because it is not the one people usually give. Eve watches traffic for long enough and acquires some plaintext-ciphertext block pairs. She then builds a codebook, and decrypts future traffic by lookup — she never computes the key K at all.
And real messages are full of repeated fragments. An email header beginning Date: Tue, 29 Feb 2000 13:44:38 -0500 (EST) starts with the encryption of Date: Tu. If Eve sees that ciphertext block often on Tuesdays, she can infer the message is email sent on a Tuesday without knowing any plaintext at all.
There is a second problem: Eve can cut and paste. She can extract blocks of a real message and assemble a false ciphertext from her codebook, and Bob will decrypt it into something Alice never wrote.
Figure (svg): ECB mode: each plaintext block encrypted independently, so identical blocks give identical ciphertext.
Anomaly
Take a simple image, split it into blocks, and encrypt every block with AES-256 in ECB mode using a strong random key.
Predict first
What does the ciphertext look like?
Correct: The original picture, in different colours
This is the famous ECB penguin, and it is the most efficient demonstration in cryptography that a primitive can be flawless while the system leaks.
Stated formally: ECB fails Chapter 4's indistinguishability game trivially. Submit m₀ = two identical blocks and m₁ = two different blocks; the ciphertext announces which.
Why: Every block of flat background is identical, so every one encrypts to the same ciphertext block; every block of the figure's edge does likewise. The ciphertext therefore reproduces the map of which blocks are equal to which, and for an image that map is the image. AES-256 is doing its job perfectly — the leak is entirely in the mode, and no strengthening of the cipher touches it.
Figure (svg): Two panels contrasting an image encrypted in ECB mode, where the picture is still visible, with one encrypted in CBC mode, which looks like noise.
Explain it
A colleague asks why encrypting each block separately with an unbroken cipher is not good enough.
Discussion prompt
Explain it without using the word 'mode', and then give the one-sentence version they will remember.
Hint: Reach for an analogy where the identity of the pieces is hidden but their arrangement is not.
Answer:
The analogy: imagine replacing every distinct word in a book with a distinct symbol, consistently. No one can read any individual word — but the paragraph structure, the repeated phrases, the rhythm of the sentences all survive intact. Often that is enough to identify the text.
The mechanism: the cipher is a function, so the same block always gives the same output. Real data is full of repeated blocks — zeroed disk regions, identical file headers, the flat background of an image — and the ciphertext preserves exactly which blocks matched which.
The demonstration: encrypt a picture this way with the strongest cipher available, and you can still see the picture.
The one-sentence version: the cipher hides the contents of each block and not the pattern of which blocks are the same — and for structured data, the pattern is most of the information.
It is worth noticing this is Chapter 2's lesson in a third costume. There it was letters, here it is blocks, and it will return in Chapter 12 as the reason hash functions need salting.
Concept
The fix is feedback: make the encryption of a block depend on everything before it.
\[ C_j = E_K(P_j \oplus C_{j-1}), \qquad P_j = D_K(C_j) \oplus C_{j-1} \]
Now two identical plaintext blocks encrypt differently, because the previous ciphertext blocks differ. The codebook attack dies, and so does the pattern leak.
C₀ is the initialization vector, the IV. The book is explicit about what happens if it is fixed: with C₀ = 0, sending the same message twice produces the same ciphertext twice, which tells Eve that the same plaintext was sent — and that is often valuable enough to reconstruct meaning.
So in practice C₀ is chosen randomly and sent in the clear alongside C₁. The IV is not secret; it only has to be unpredictable and never repeated.
Figure (svg): CBC mode: each plaintext block XORed with the previous ciphertext block before encryption, seeded by an IV.
Worked example
Trace the dependency so the decryption formula stops looking arbitrary.
Choose a random IV = C₀ and transmit it in the clear
Why: It is not secret. Its job is to make the first block's encryption unpredictable.
C₁ = E_K(P₁ ⊕ C₀)
Why: The first plaintext block never enters the cipher unmodified.
C₂ = E_K(P₂ ⊕ C₁), and C₃ = E_K(P₃ ⊕ C₂)
Why: Each block is masked by the previous ciphertext, so C₃ depends on P₁, P₂, P₃ and the IV.
To decrypt: P₂ = D_K(C₂) ⊕ C₁
Why: Apply the cipher's inverse, then undo the XOR using the ciphertext block the receiver already has.
Verify: D_K(C₂) = D_K(E_K(P₂ ⊕ C₁)) = P₂ ⊕ C₁, and XORing C₁ leaves P₂
Why: The chain unwinds because the masking value is a ciphertext block, which the receiver has before it needs it. Masking with the previous plaintext block would have worked mathematically and been useless, since the receiver does not have it yet.
Figure (svg): CBC mode: each plaintext block XORed with the previous ciphertext block before encryption, seeded by an IV.
Edge cases
The IV is sent in the clear, so it is not secret. That leaves the question of what it does have to be.
Discussion prompt
Which properties must an IV have, and what goes wrong if each is missing?
Hint: Consider a fixed IV, a repeating IV, and a predictable-but-not-repeating IV separately.
Answer:
It must not be fixed. With C₀ = 0 always, the same message gives the same ciphertext, so Eve learns when a message repeats — the exact leak CBC was introduced to remove.
It must not repeat. Two messages sharing an IV have identical ciphertext up to their first difference, so Eve learns the length of their common prefix. On a protocol with structured headers that is a great deal.
It must be unpredictable, not merely unique. If Eve can predict the next IV, she can mount a chosen-plaintext attack: choose P₁ = (predicted IV) ⊕ (a guess), and the ciphertext confirms or refutes the guess. This is the BEAST attack on TLS 1.0, which used the previous record's last ciphertext block as the next IV — unique, and entirely predictable.
So: random per message, transmitted alongside the ciphertext. Note this is a stronger requirement than CTR mode's, where a non-repeating counter suffices — because in CTR the nonce is encrypted rather than XORed with the plaintext.
Explain it to yourself
CBC computes Cⱼ = Eₖ(Pⱼ ⊕ Cⱼ₋₁). It could just as easily have been defined as Cⱼ = Eₖ(Pⱼ ⊕ Pⱼ₋₁).
Discussion prompt
Explain why the ciphertext is the right thing to mask with, and what would break with the plaintext version.
Hint: Write down what the receiver has at the moment it needs to decrypt block j.
Answer:
Both are fine for the sender. Alice has all the plaintext, so masking with Pⱼ₋₁ is perfectly computable at encryption time.
Only one is fine for the receiver. Bob computes Pⱼ = Dₖ(Cⱼ) ⊕ (mask). If the mask is Cⱼ₋₁ he already has it — it arrived on the wire. If the mask is Pⱼ₋₁ he needs the previous plaintext, which he can get, because he decrypted it. So the plaintext version also works, in a chain.
The real difference is error behaviour and randomisation. With the plaintext version, an error in one block destroys every block after it, because the chain of masks never recovers. With the ciphertext version, decryption is self-healing after two blocks — as the check slide shows.
And a subtler point: masking with the previous plaintext leaks less randomisation into the chain. Two messages with identical prefixes and different IVs would still produce related structure, whereas the ciphertext mask is already randomised by the IV from the first block onwards.
The general rule for designing feedback: route it through data both parties already hold, and prefer data that is already randomised.
Concept
Both ECB and CBC must wait for a complete block before they can encrypt anything. For an interactive terminal that is unacceptable, so CFB turns the block cipher into a keystream generator.
Work with a 64-bit register X and eight-bit plaintext pieces. For j = 1, 2, 3, …
\[ O_j = L_8\bigl(E_K(X_j)\bigr), \qquad C_j = P_j \oplus O_j, \qquad X_{j+1} = R_{56}(X_j) \, \| \, C_j \]
L₈ is the leftmost 8 bits, R₅₆ the rightmost 56, and ‖ is concatenation. So the ciphertext byte just produced shifts into the right end of the register, and the register's oldest byte falls off the left.
Two consequences worth noticing. Decryption uses E_K, not D_K — the block cipher only ever generates keystream, which is an advantage when a cipher's decryption is slower than its encryption. And the plaintext is XORed, exactly as with a one-time pad, so all of Chapter 4's cautions apply.
Figure (svg): CFB mode: a 64-bit register is encrypted, its leftmost eight bits XOR the plaintext byte, and the ciphertext byte shifts into the register.
Invariant
The book traces what happens to the 64-bit register over successive rounds of 8-bit CFB. The pattern is the key to its error behaviour.
Step through it
If C₁ arrives corrupted, how many plaintext bytes are damaged?
Nine. C₁ itself decrypts wrongly, and the corrupted byte then sits in the register for eight more rounds, garbling P₂ through P₉. At round 10 it has been flushed out and decryption recovers on its own.
Prediction
A single ciphertext bit is flipped in transit, in each mode in turn.
Predict first
In which mode does the damage stay confined to one plaintext bit?
Correct: OFB and CTR
This is genuinely a design consideration on noisy links, and it is why OFB was specified at all.
But read the same fact from the attacker's side: in OFB and CTR, flipping a ciphertext bit flips exactly the plaintext bit you chose. That is a controlled forgery capability, and it is why these modes must always be paired with a message authentication code. Chapter 12 covers those.
Why: OFB and CTR generate keystream that does not depend on the ciphertext at all, so a flipped ciphertext bit flips exactly the corresponding plaintext bit and nothing else. ECB destroys the whole block containing it. CBC destroys that block and flips one bit of the next, since the corrupted ciphertext block is XORed into the following block's decryption. CFB garbles the current unit and the next b/k units while the error sits in the register.
Figure (svg): OFB feeding the cipher's own output back into the register, next to CTR encrypting an incrementing counter.
Concept
CBC and CFB both propagate errors, because both feed the ciphertext back into the state. OFB feeds back the cipher's own output instead.
\[ O_j = L_8\bigl(E_K(X_j)\bigr), \qquad X_{j+1} = R_{56}(X_j) \, \| \, O_j, \qquad C_j = P_j \oplus O_j \]
The one change — O_j rather than C_j shifting into the register — means the keystream depends only on the key and the IV, and not on the message at all.
So the keystream can be generated before the plaintext is available, which suits low-latency links, and a transmission error affects exactly the bits it hits. OFB is a genuine stream cipher whose keystream generator happens to be a block cipher.
The price is that the keystream is a fixed function of (K, IV), so an IV must never repeat — the two-time pad of Section 4.3 is waiting. And because the feedback is the full block, OFB cannot be parallelised or seeked.
Figure (svg): OFB feeding the cipher's own output back into the register, next to CTR encrypting an incrementing counter.
Counterexample
CTR is the modern default and it has one hard requirement: never encrypt two different messages with the same key and the same counter value.
Discussion prompt
Show what an attacker gets from two messages encrypted under the same key and nonce, and say why this is more dangerous in CTR than the equivalent mistake in CBC.
Hint: Write down the two ciphertexts and XOR them.
Answer:
XOR the ciphertexts. C₁ = P₁ ⊕ Eₖ(nonce‖j) and C₂ = P₂ ⊕ Eₖ(nonce‖j), so C₁ ⊕ C₂ = P₁ ⊕ P₂. The keystream cancels exactly as in Section 4.3, and the attacker holds a two-time pad.
Why it is worse than the CBC equivalent. Repeating a CBC IV leaks only that two messages share a prefix, and the damage stops at the first differing block. Repeating a CTR nonce leaks P₁ ⊕ P₂ for the entire length of both messages.
And it is easier to do by accident. A CBC IV is generated per message and is obviously per-message; a CTR nonce is often derived from a counter or a message ID, and those get reset — by a reboot, a restored VM snapshot, a failover to a standby node that started its counter at zero.
Which is why AES-GCM's nonce rules are stated so emphatically, and why nonce-misuse-resistant modes such as SIV exist: they degrade to leaking only equality of messages rather than their XOR.
The chapter-level lesson: CTR's simplicity moves the burden onto the nonce discipline, and the discipline has to be enforced by the design rather than by the operator.
Concept
Remove the feedback entirely. The input to the block cipher for block j is a nonce concatenated with j.
\[ O_j = E_K(\text{nonce} \, \| \, j), \qquad C_j = P_j \oplus O_j \]
Every property follows from there being no chain. Blocks are independent, so encryption and decryption both parallelise across cores. Block 10 000 can be decrypted without touching blocks 1 to 9 999, which is what makes full-disk and database encryption practical. No padding is needed, because the last partial block just uses part of a keystream block.
And keystream reuse is structurally prevented rather than merely discouraged: the counter cannot repeat within a message, and a fresh nonce per message keeps messages apart. That is precisely the fix Section 4.3 said a design must make impossible rather than forbid.
CTR is the modern default. AES-GCM, which secures most HTTPS traffic, is CTR mode plus an authentication tag.
Figure (svg): OFB feeding the cipher's own output back into the register, next to CTR encrypting an incrementing counter.
Matching
Each of these applications has one constraint that decides the answer.
Match the pairs
Why: In every case one property decides it, and it is never the strength of the underlying cipher: seekability for the disk, latency for the terminal, error confinement for the satellite, and simple generality for the one-off message. Note that all four would today be wrapped in an authenticated mode, because none of them provides integrity — the satellite case especially, since OFB's clean single-bit errors are exactly what lets an attacker flip a chosen plaintext bit.
Ranking
Throughput on modern hardware is decided by this more than by the cipher's speed.
Put in order
Why: OFB parallelises in neither direction: each keystream block needs the previous one. CFB and CBC both parallelise decryption only — every ciphertext block is available at once, so all the D or E calls can run together, but encryption is inherently sequential because block j's input needs block j−1's output. CTR parallelises both, since the cipher's input for block j is just the counter. CFB is ranked below CBC only because its unit is smaller, so it makes more cipher calls per byte. On an eight-core machine this ordering is a factor of eight in throughput, decided entirely by the mode.
Figure (svg): The five modes compared on chaining, whether padding is needed, error propagation, and whether they can be parallelised.
Comparison
Fill the blanks. Each column is a property some application cares about more than the others.
Comparison matrix
| Mode | What is fed back | Parallelisable? |
|---|---|---|
| ECB | nothing | both directions |
| CBC | the previous ciphertext block | decryption only |
| CFB | the previous ciphertext unit | decryption only |
| OFB | the cipher's own output | neither |
| CTR | nothing — a counter is the input | both directions |
ECB and CTR both feed back nothing, and one is unusable while the other is the modern default. The difference is that CTR's cipher input varies whether or not the plaintext does.
Figure (svg): The five modes compared on chaining, whether padding is needed, error propagation, and whether they can be parallelised.
Discrimination
Three of the five never apply the block cipher to the plaintext at all.
Sort into buckets
Sort each mode.
Elimination
A disk must let the operating system read sector 200 000 without reading anything before it, and write it without rewriting anything after it.
Eliminate the wrong options
Which mode fits the requirement?
Survives elimination: c
Why: CTR's keystream block for position j depends only on the key and j, so any block can be produced directly and independently — which is exactly the disk's requirement. Real disk encryption uses XTS rather than plain CTR, because CTR alone would reuse keystream whenever a sector is rewritten with the same counter, which is Section 4.3's failure again. But the reason CTR is the starting point is the one this question tests: no feedback means seekability.
Faded example
Decryption is where mode confusion shows up. Fill in each blank.
Fill in the blanks
CBC: Pⱼ = Dₖ(Cⱼ) ⊕ Cⱼ₋₁. CFB: Pⱼ = Cⱼ ⊕ L₈(Eₖ(Xⱼ)) — note it uses Eₖ, not the decryption function. CTR: Pⱼ = Cⱼ ⊕ Eₖ(nonce ‖ j), which needs no chaining at all. And ECB: Pⱼ = Dₖ(Cⱼ).
Why: The second blank is the one worth dwelling on: in all three stream modes the block cipher's decryption function is never invoked, because the cipher is only ever used to make keystream. That is a genuine engineering advantage when a cipher's decryption is slower than its encryption, and it also means a hardware implementation of such a mode needs only half the circuitry.
Real world
Section 6.3's modes need padding, and the padding has to be validated. Vaudenay showed in 2002 what that costs.
Discussion prompt
Describe how an attacker uses a padding-error message to decrypt a CBC ciphertext, and name two deployed systems it broke.
Hint: The attacker controls the previous ciphertext block, which is XORed into the decryption.
Answer:
The mechanism. In CBC, Pⱼ = Dₖ(Cⱼ) ⊕ Cⱼ₋₁. The attacker sends a two-block ciphertext consisting of a chosen block R followed by the target block Cⱼ. The receiver computes Dₖ(Cⱼ) ⊕ R and checks the padding. By varying the last byte of R over all 256 values she finds the one that produces valid padding, and that tells her the last byte of Dₖ(Cⱼ). Then Pⱼ follows by XORing the real Cⱼ₋₁.
Cost: about 256 queries per byte, so a 16-byte block in a few thousand requests. The key is never recovered and never needed.
Deployed victims: TLS in several forms, culminating in the Lucky Thirteen timing variant; ASP.NET in 2010, where the oracle allowed downloading web.config and forging authentication tokens; and a long list of VPN and storage products.
Why it kept happening: the fix is not to hide the error, because the timing difference leaks anyway. The real fix is encrypt-then-MAC — verify a message authentication code before decrypting at all, so a tampered ciphertext is rejected without ever reaching the padding check.
This is the strongest argument in the chapter for authenticated encryption: the flaw is not in AES, not in CBC's algebra, but in the unavoidable act of checking the padding.
Section
Section 6.4 · pp. 129-130
Concept
A cipher ages. Its key becomes searchable and it needs replacing, which is slow — so the other approach is to apply the existing cipher more than once with different keys.
Double encryption looks compelling. A 56-bit key space becomes 2¹¹² key pairs, which should be far beyond reach. It is not. Merkle and Hellman showed that double encryption has the security level of a 57-bit key, using the meet-in-the-middle attack of the next section.
So triple encryption is used instead, at roughly the security of a 112-bit key. There are two arrangements:
\[ \text{EEE: } E_{K_1}\bigl(E_{K_2}(E_{K_3}(m))\bigr), \qquad \text{EDE: } E_{K_1}\bigl(D_{K_2}(E_{K_1}(m))\bigr) \]
The middle D gives no extra cryptographic strength whatever. Its purpose is compatibility: set K₁ = K₂ and EDE collapses to single encryption, so a triple-encryption machine can talk to an older single-encryption one by choosing its keys appropriately.
Figure (svg): EDE triple encryption with two keys, showing that setting the two keys equal reduces it to single encryption.
Two truths and a lie
Two of these are false in ways that matter for different reasons.
Eliminate the wrong options
Which statement is correct?
Survives elimination: a
Why: Both failure modes are real and they are different. Where the cipher's encryptions compose — affine ciphers, RSA with a common modulus — double encryption is literally single encryption and gains nothing at all. Where they do not compose, as with DES, meet-in-the-middle limits the gain to about one bit. Only triple encryption gets you a genuine increase, and the fact that it needs three applications to gain 56 bits is the surprising part.
Trade off
Fill the blanks. Padding is where several of this chapter's problems enter.
Comparison matrix
| Block modes (ECB, CBC) | Stream modes (CFB, OFB, CTR) | |
|---|---|---|
| Padding needed? | yes | no — the keystream is truncated |
| Ciphertext length | rounded up to a whole block | exactly the plaintext length |
| Padding oracle possible? | yes, and it has broken real systems | no padding, so no padding oracle |
| Leaks about length | only the block count | the exact byte length |
| Uses Dₖ to decrypt | yes | no — Eₖ both ways |
The fourth row cuts the other way and is easy to miss: stream modes remove the padding oracle and give away the exact message length, which for short messages — YES against NO — can be the whole content.
Section
Section 6.5 · pp. 130-131
Concept
Alice and Bob encrypt twice: c = E_{K₂}(E_{K₁}(m)). Eve must find both keys, so she faces 2¹¹² pairs. Or so it appears.
Eve has one known plaintext-ciphertext pair. She builds two lists:
Then she looks for matches between the lists. A match means E_K(m) = D_L(c), which means E_L(E_K(m)) = c — a candidate key pair.
There will be at least one match, since the true pair produces one, and probably many spurious ones. She then tests the survivors against a second plaintext-ciphertext pair, and repeats until one pair remains.
Figure (svg): The meet-in-the-middle attack: encrypt the plaintext under every key, decrypt the ciphertext under every key, and look for a match in the middle.
Worked example
The point of the attack is entirely in its arithmetic, so it is worth doing.
Naive search over key pairs: 2⁵⁶ × 2⁵⁶ = 2¹¹² double encryptions
Why: This is the number the designers of double encryption were relying on.
Meet-in-the-middle: 2⁵⁶ encryptions to build the first list, plus 2⁵⁶ decryptions to probe it
Why: Two passes, each the size of a single-key search.
Total work ≈ 2⁵⁶ + 2⁵⁶ = 2⁵⁷
Why: Which is why the book says double encryption has the security level of a 57-bit key.
But storage is 2⁵⁶ entries
Why: This is the real cost, and it is why the book says 'as long as we have a computer with a lot of memory'. At 8 bytes per entry that is 576 exabytes — the attack is a statement about the security model, not a weekend project.
\[ 2^{112} \;\longrightarrow\; 2^{57} \text{ work} + 2^{56} \text{ storage} \]
Verify: count the gain: 56 bits of extra key bought 1 bit of extra security
Why: Doubling the key length gained a single bit. That disproportion is the result, and it is why triple encryption exists.
Figure (svg): The meet-in-the-middle attack: encrypt the plaintext under every key, decrypt the ciphertext under every key, and look for a match in the middle.
Cost model
Meet-in-the-middle is the first of several attacks in this book that buy time with memory. The shape recurs.
Annotate
On: \( T \approx 2^{k+1}, \qquad S \approx 2^{k}, \qquad \text{versus } T \approx 2^{2k} \text{ with } S \approx 1 \)
The honest way to state a key length is therefore against the best known attack, not against exhaustive search — which is Chapter 1's argument arriving with a number attached.
Estimation
Triple DES with three independent 56-bit keys has a 168-bit key. Meet-in-the-middle applies to it too, splitting one encryption from the other two.
Predict first
What is its effective security level?
Correct: About 112 bits
This also explains why nobody uses quadruple encryption: the gain per application is linear while the cost is linear too, so it is always better to adopt a cipher with a longer key.
Which is exactly what happened. Triple DES was a bridge, and Chapter 8's AES — designed from the start with 128-, 192- and 256-bit keys — is where the field went instead.
Why: Split the three encryptions as one against two: build a table of 2⁵⁶ single encryptions and probe it with 2¹¹² double decryptions. The cost is dominated by the 2¹¹² side, so the effective security is about 112 bits — which is what the book states. Note the pattern: n applications give roughly (n−1) × 56 bits, so each extra application buys one more key's worth, and the first one buys almost nothing.
Socratic
The book notes that for affine ciphers and for RSA with a shared modulus, double encryption is the same as single encryption with another key.
Discussion prompt
What property makes double encryption pointless, and why does it matter that DES lacks it?
Hint: Ask whether the set of encryption functions is closed under composition.
Answer:
The property is closure — the cipher's encryption functions forming a group under composition. If for every K₁, K₂ there is a K₃ with E_{K₂} ∘ E_{K₁} = E_{K₃}, then double encryption produces nothing that single encryption could not, and the key space has not grown at all.
Affine ciphers are a group: composing x ↦ α₁x + β₁ with x ↦ α₂x + β₂ gives x ↦ α₂α₁x + (α₂β₁ + β₂), which is affine. RSA with a common modulus likewise: exponent e₁ then e₂ is exponent e₁e₂.
DES is not a group, which was proved in 1992 and was a genuinely open question until then. So double DES really is a function outside the single-DES family, and the key space genuinely is 2¹¹².
And this is exactly why meet-in-the-middle matters. If DES had been a group, double encryption would have been pointless for a trivial reason. Because it is not, double encryption is almost pointless for a subtler one — the key space is real, and the attack finds the pair without searching it.
The moral: showing that a construction is not trivially useless is a long way from showing it is useful.
Scale up
Each extra application of a 56-bit cipher costs a full encryption pass. Track what each one buys.
Step through it
Why did the second application buy one bit and the third buy fifty-five?
Because meet-in-the-middle splits the chain at one point. With two applications the split is one-against-one and both halves are cheap; with three it is one-against-two, and the two-side costs 2¹¹². The attack's cost is set by the larger half.
Missing information
A security questionnaire answer reads, in full: "Data at rest is encrypted with AES-256 in CBC mode."
Discussion prompt
List what a reviewer still does not know, ordered by how badly each gap could fail.
Hint: Everything this chapter has said about IVs, padding and integrity is a gap in this sentence.
Answer:
Is there integrity protection? CBC provides none. Without a MAC an attacker can flip a chosen bit of block j+1 by flipping a bit of ciphertext block j, and the padding check becomes an oracle. This is the gap most likely to be catastrophic.
How is the IV chosen? Fixed leaks message equality; predictable enables BEAST-style chosen-plaintext attacks; repeated leaks common prefixes. The sentence does not say, and all three failures have shipped.
Is the MAC applied before or after encryption? Encrypt-then-MAC prevents the padding oracle by rejecting tampered ciphertext before decryption. MAC-then-encrypt does not, and is what TLS did for years.
Where does the key come from and how is it rotated? Chapter 5's lesson: the generator and the seed, not the cipher, are where key material actually fails.
Is the IV transmitted, and how is it bound to the ciphertext? An IV that can be modified independently lets an attacker control the first plaintext block outright.
Naming the cipher and the mode — the only two things the sentence contains — leaves every question that has actually broken deployed systems unanswered.
Commit first
A team ships a product using AES-256-CBC with a random per-message IV, correct PKCS#7 padding, and keys from the OS entropy pool. There is no MAC.
Predict first
What is most likely to be exploited first?
Correct: The padding oracle, or an attacker-controlled bit flip, because there is no integrity protection
This is why modern practice is to use an authenticated mode — AES-GCM or ChaCha20-Poly1305 — rather than assembling encryption and authentication by hand. The assembly is where the mistakes live.
It also restates the chapter's trap slide with a number attached: every component here is strong, and the system is broken.
Why: Everything named in the description is done correctly, and the one omission is the one that matters. Without a MAC, tampered ciphertext is decrypted and its padding is checked, which is the oracle; and even without an error message, an attacker who can flip a bit in block j flips the corresponding bit of plaintext block j+1 at the cost of destroying block j. AES-256 has no known attack, the IV is meant to be public, and OS entropy is the right source.
Constraint
One product, three subsystems, three different answers.
Discussion prompt
Pick a mode for each: (a) a log stream appended to continuously and read sequentially; (b) a 4 TB backup archive that must support restoring one file without reading the whole archive; (c) a control channel sending 12-byte commands with a strict latency budget.
Hint: For each, name the single property that decides it before considering anything else.
Answer:
(a) The log stream: CTR or CFB. Append-only means no rewriting, so keystream reuse is avoidable with a running counter, and no padding is needed for a stream that never ends. CBC would work too but forces block-aligned writes.
(b) The backup archive: CTR, with the counter derived from the file's offset. Restoring one file must not require decrypting 4 TB, and only CTR gives direct access to an arbitrary block.
(c) The control channel: CTR or CFB, and emphatically not CBC. A 12-byte command padded to 16 wastes a third of the payload, and more importantly the padding introduces an oracle on a channel that will certainly report errors. Stream modes give ciphertext exactly 12 bytes long.
And the answer that applies to all three: use an authenticated mode. For (c) especially, an unauthenticated control channel lets an attacker flip bits in commands, which is a far worse outcome than reading them.
Notice the reasoning pattern: name the binding constraint first — seekability, latency, alignment — and only then check the security requirements. Getting that order backwards produces designs that are secure and unusable.
Pattern
Five modes, one primitive, and every difference between them comes down to answering three questions.
And one thing no mode in this chapter does: none of them provides integrity. Every mode here protects confidentiality only, and in the stream modes an attacker can flip any plaintext bit she chooses by flipping the corresponding ciphertext bit. Authenticated modes — GCM, CCM — exist because this chapter's modes are not enough on their own.
Figure (svg): The five modes compared on chaining, whether padding is needed, error propagation, and whether they can be parallelised.
Trap
The trap. AES-256 has no known attack. So as long as AES-256 is the primitive, the surrounding arrangement is an implementation detail — a matter of buffering and padding, not of security. Any mode will do.
This is a natural conclusion from Chapter 1's emphasis on the strength of primitives, and it is wrong in a way that this chapter's most famous picture settles instantly.
Why it fails. The ECB penguin uses AES-256 with a strong random key and the image survives. The cipher performed perfectly; every block was encrypted to something unrelated to its content. What leaked was the pattern of equal blocks, and no property of the cipher addresses that, because the cipher never sees more than one block.
The mode is where all the cross-block structure lives, so it is where all the cross-block leakage lives too. A primitive can only protect what it is shown.
And modes have their own failure modes that the primitive cannot help with: a fixed IV, a predictable IV (BEAST), a repeated CTR nonce, a padding oracle. Each of these breaks a system built on an unbroken cipher.
The rule to carry: a cryptosystem is a primitive plus the way it is used, and the way it is used is where most real failures happen. Chapter 14 is a whole chapter of examples, and every one of them has sound primitives.
Check
Work it out before you click.
Check your understanding
Alice encrypts a database column so that identical values give identical ciphertexts, deliberately, so she can search it. What has she built?
Answer: B
Why: Deterministic encryption of a column is ECB by another name. It permits equality search, and it hands the attacker the frequency distribution of the column — from which a public reference distribution recovers the values. Encrypted-salary columns fall to a published salary table, exactly as a substitution cipher falls to letter frequencies.
Check
Apply the meet-in-the-middle arithmetic.
Check your understanding
A cipher has a 64-bit key. Applied twice with independent keys, what is the effective security?
Answer: B
Why: Meet-in-the-middle needs 2⁶⁴ encryptions and 2⁶⁴ decryptions, so about 2⁶⁵ operations, plus a table of 2⁶⁴ entries. The 128-bit key space is real but never searched. As with DES, doubling the key length bought one bit of security.
Check
Trace the decryption carefully.
Check your understanding
In CBC mode, one bit of ciphertext block C₂ is flipped in transit. Which plaintext blocks are affected?
Answer: B
Why: P₂ = D_K(C₂) ⊕ C₁, and a changed C₂ makes D_K(C₂) unrecognisable, so P₂ is destroyed entirely. P₃ = D_K(C₃) ⊕ C₂ uses C₂ only in the XOR, so exactly the flipped bit propagates to P₃. From P₄ onwards nothing is affected. The controllable single-bit flip in P₃ is a forgery primitive, which is why CBC needs a MAC.
Connect it up
This chapter is a decision you will actually have to make. Compress it into something you could use.
Draw it
Draw a table with the five modes as rows and these columns: what is fed back; whether padding is needed; how far a corrupted ciphertext bit spreads; whether encryption and decryption can be parallelised; and what must never repeat. Then, underneath, write the three requirements from the pattern slide, and finish with the sentence about what none of the five modes provides — and name the modes that do provide it.
The final line is the one that matters most in practice: every mode here is confidentiality-only, and shipping one without a MAC is the commonest cryptographic mistake in production code.
Exit ticket
One question, about where the security in this chapter actually lives.
Predict first
Why is choosing a mode of operation a security decision rather than an engineering one?
Correct: Because the block cipher only sees one block, so all cross-block structure — and all cross-block leakage — is decided by the mode
Why: A block cipher is a permutation on one block and is entirely blind to everything outside it. Whether two identical plaintext blocks produce identical ciphertext, whether an attacker can predict the next IV, whether a keystream can repeat — none of these is visible to the primitive, and all of them are decided by the mode. The ECB penguin is the demonstration: a flawless cipher, and the picture survives.
Recap
One primitive, five ways of using it, and one attack that reprices multiple encryption.
Chapter 7 next. We have been treating E_K as a black box. DES is the first look inside one: a Feistel network of sixteen rounds, its differential cryptanalysis, and the day it finally fell to purpose-built hardware.
Figure (svg): The five modes compared on chaining, whether padding is needed, error propagation, and whether they can be parallelised.
Want this taught 1-on-1? Alexander tutors Cryptography — $55/session, free consultation.