Chapter 14 of Trappe & Washington: three case studies in which the cryptography was sound and the system failed anyway. Enigma's no-self-map guarantee and the 1941 intercept that exploited it; three ways of choosing RSA primes badly, from Netscape's timestamp seed to the 2012 surveys that found 26 965 moduli sharing a factor; and WEP in full — a 24-bit IV colliding after four thousand packets, a related-key structure, and a linear CRC used where a message authentication code was needed.
Subject: Cryptography · 60 slides · diagram-first lesson
Open the interactive version of this deck
Title
Cryptography · Chapter 14
Three systems whose mathematics was correct and whose assembly was not
Objectives
Twelve chapters of primitives, and none of them has been broken by an attack on its mathematics. This chapter is the other half of the story, and the book puts it here deliberately — after the tools and before the protocols.
Figure (svg): The pattern across all three case studies: sound primitives, and a failure in the assembly around them.
Warm-up
Thirteen chapters have covered dozens of attacks. Sort them by what was attacked.
Discussion prompt
How many of the breaks in this course so far were attacks on the underlying hard problem, and how many were something else?
Hint: Think about DES, WEP, the PlayStation 3, Venona and Debian.
Answer:
Attacks on the mathematics: very few. DES fell to exhaustive search, which the designers had been warned about; MD5 and SHA-1 fell to real cryptanalysis. That is close to the whole list.
Attacks on parameters: several. A 56-bit key, a 24-bit IV, a 128-bit digest, a 512-bit modulus. Each was a number chosen against yesterday's hardware or yesterday's algorithms.
Attacks on constructions: more. ECB leaking patterns, length extension, unhashed RSA signing, a MAC that was really a plain hash. The primitive was right and the wrapper was wrong.
Attacks on randomness: the largest single category. Venona's duplicated pads, WEP's IV, the PlayStation 3's constant nonce, Debian's OpenSSL, Netscape's timestamp seed.
This chapter is the fourth category made explicit, and the ordering is the point: the further you get from the mathematics, the more likely the failure.
Section
Section 14.1 · pp. 282-283
Concept
The book is generous about Enigma: for its time it was an excellent system, and the German troops' belief in it was itself a security problem. If your ship is sinking, do you escape or stay to destroy a machine you have been told is unbreakable?
But the design had a consequence that looked like a virtue. The reflector wired the contacts in pairs, so the permutation applied at each step was an involution with no fixed points — a letter could never encrypt to itself. A would never come out as A.
To people unfamiliar with cryptography this looked excellent. There would always be 'complete encryption'; the plaintext would always be completely changed.
In practice it meant that certain guesses for the plaintext could immediately be discarded as impossible — at no computational cost whatever. Slide a suspected word along the ciphertext, and every alignment where any letter faces itself is ruled out.
Figure (svg): A ciphertext containing every letter except L, which under Enigma's no-self-map rule means the plaintext was all L.
Worked example
One day in 1941, British cryptographers intercepted an Enigma message from the Italian navy.
Mavis Batey, at Bletchley Park, noticed the ciphertext contained no letter L at all
Why: In a message of any length, an absent letter is remarkable — in ordinary text every letter appears.
Knowing that no letter encrypts to itself, she reasoned that L was the one letter the plaintext could not have produced anywhere else
Why: If the plaintext were all L, then L is exactly the letter that could never appear in the ciphertext.
Her guess: a bored radio operator tapping the L key repeatedly while waiting for the next message
Why: A plausible human explanation, and a complete crib for the whole message.
With the full plaintext known, the day's Enigma key could be determined
Why: Known plaintext of that length against a machine whose wiring was understood is enough.
Verify: one of the messages read “Today's the day minus three.”
Why: It alerted the British to a surprise attack on their Mediterranean fleet. The resulting Battle of Cape Matapan established the dominance of the British fleet in the eastern Mediterranean — from one letter's absence and a design guarantee.
Figure (svg): A ciphertext containing every letter except L, which under Enigma's no-self-map rule means the plaintext was all L.
Socratic
The no-self-map rule was a deliberate feature. Modern ciphers guarantee nothing about their output at all.
Discussion prompt
State the general principle, and give an example from a modern cipher.
Hint: Ask what an attacker does with any statement that is always true of the ciphertext.
Answer:
Any structure you guarantee about the output is a structure the adversary can test for. A property that always holds is a filter she applies for free — no computation, no cryptanalysis, just rejection of everything inconsistent with it.
A modern cipher aims to guarantee nothing. The design target is that the output be indistinguishable from random, which by definition means no property holds more often than chance. Chapter 4's game states this precisely.
The modern example is ECB mode. It guarantees that equal plaintext blocks give equal ciphertext blocks — presented as determinism, not as a security feature, but the effect is identical. Eve tests for equal blocks and reads the structure of the plaintext off the ciphertext.
And a subtler one: deterministic encryption of a database column, which guarantees that equal values encrypt equally and is therefore searchable — a feature deliberately built on a leak.
The rule to carry: when a design offers a guarantee about the ciphertext, ask what an attacker does with it. The answer is usually 'discards candidates', and discarding candidates is what cryptanalysis is.
Section
Section 14.2 · pp. 283-284
Concept
RSA's security rests on the inability to factor n = pq, so p and q must be chosen unpredictably. That needs a good pseudorandom generator, and a generator needs a random seed.
The book gives three failures, and they are increasingly systemic:
None of these is an attack on RSA. All three are attacks on the process that produced the key.
Figure (svg): Netscape's RSA key generation seeded from a timestamp, collapsing an enormous key space to a few million possibilities.
Worked example
Goldberg and Wagner were graduate students at Berkeley reading the documentation for an early web browser.
When a secure transaction was needed, the browser generated an RSA key on the spot
Why: Which is reasonable — ephemeral keys are good practice.
The seed for the pseudorandom generator was formed from a time stamp
Why: This is the whole flaw. Everything downstream was correct.
A timestamp has very little entropy: the attacker knows roughly when the transaction occurred
Why: Within a second or two, so a few thousand candidate seeds; within a day, a few hundred thousand.
For each candidate seed, run the same generator and derive the same primes
Why: The generator is public — Kerckhoffs's principle — so the attacker reproduces it exactly.
Verify: the primes for a transaction, deduced in a few seconds on a desktop computer
Why: Netscape shipped a repair quickly. And the president of RSA Data Security noted pointedly that Netscape had declined help with the implementation the first time and asked for it the second. The mathematics was never in question.
Figure (svg): Netscape's RSA key generation seeded from a timestamp, collapsing an enormous key space to a few million possibilities.
Worked example
The 2012 result is the most worrying of the three, because nothing in a single key reveals it.
Two teams collected RSA moduli from the web — from X.509 certificates and similar sources
Why: The Lenstra team gathered 11.4 million of them.
They computed the gcd of each pair of moduli
Why: Naively this is 10¹⁴ gcds, but a batch algorithm computes all pairwise gcds against a product tree in near-linear time.
They found 26 965 moduli where a gcd gave a non-trivial factor
Why: Each such gcd breaks two keys at once — the shared prime factors both moduli.
Why it happened: a generator producing too few distinct primes, plus the birthday bound
Why: The book's illustration: a generator capable of only a million primes, used to make 2000 primes, is 2√N people in an N-birthday room. A repeat is likely.
Verify: and there is no way to check your own key without the data
Why: You cannot tell from n alone whether some other modulus shares a factor with it. You would have to compute the gcd against the millions of others — and if you found one, you would have broken someone else's system in the process. That asymmetry is what makes the flaw so awkward.
Figure (svg): Two RSA moduli sharing a prime factor, broken by a single gcd.
Anomaly
Two organisations independently generate RSA moduli. Neither key is weak in isolation.
Predict first
What happens if their generators drew the same prime?
Correct: gcd(n₁, n₂) reveals the shared prime in microseconds, breaking both keys
The asymmetry with factoring is stark: factoring one 2048-bit modulus is infeasible, and computing a gcd of two is instant. The attacker needs only that two keys were generated carelessly, and she does not need to know which two.
This is also why the attack scales: a batch gcd over millions of collected keys is cheap, so the attacker sweeps the whole internet rather than targeting anyone.
Why: The Euclidean algorithm computes gcd(n₁, n₂) in microseconds even for 2048-bit numbers — it is logarithmic, as Section 3.1 established. If the result is not 1, it is the shared prime p, and then q₁ = n₁/p and q₂ = n₂/p. Two private keys recovered by an algorithm from 300 BC, with no factoring at all.
Figure (svg): Two RSA moduli sharing a prime factor, broken by a single gcd.
Explain it to yourself
The book explains the shared factors with a birthday argument: a generator producing a million distinct primes, used to make 2000 of them.
Discussion prompt
Work the numbers, and say what the generator would have to produce for the problem to disappear.
Hint: N = 10⁶ and the number of 'people' is 2000.
Answer:
The numbers: N = 10⁶ possible primes, and 2000 = 2√N draws. The birthday bound says a repeat is likely once the draws reach √N = 1000, so 2000 draws makes a collision near-certain.
And a repeat across different moduli is what matters. Two primes equal within one modulus would be caught by any competent implementation; two primes equal across two different moduli is invisible to both parties.
What a good generator gives: there are roughly 10¹⁵¹ primes below 2¹⁰²⁴, so a generator drawing uniformly from them would need 10⁷⁵ draws before a repeat became likely. The problem simply does not arise.
So the failure is entirely about the generator's effective range, which is bounded by its seed entropy — Chapter 5's rule once more. A generator seeded with 20 bits produces at most a million distinct outputs however many primes exist.
And the setting where this bites is embedded devices, which generate keys at first boot before any entropy has accumulated. The Heninger study found exactly that: routers and firewalls, not general-purpose computers.
Section
Section 14.3 · pp. 284-288
Concept
Wired Equivalent Privacy, the standard for wireless access from 1997 to 2004. The intent was to make wireless communication as secure as a wired connection. Every laptop on a router shares the same WEP key.
The book's summary is exact: except for the authentication step, this is essentially a one-time pad, with RC4 supplying the pseudorandom stream. Every component is from an earlier chapter.
Figure (svg): The WEP protocol: a 24-bit IV concatenated with the shared WEP key seeds RC4, whose keystream XORs the message and its CRC.
Concept
The usual WEP key length was 40 bits, giving 2⁴⁰ ≈ 10¹² possibilities — searchable.
Why so short? US export regulations at the time prohibited exporting stronger cryptography, so 40 bits was chosen to allow international use. Later versions moved to 104 bits.
But the book is emphatic: WEP is insecure at any key size, because of the full collection of design flaws in the protocol. The key length is the least of them, and lengthening it fixed nothing.
This is worth noting as a counter-example to the whole 'bigger key' instinct one last time. Here is a protocol where the obvious parameter was genuinely too small, it was genuinely fixed, and the system remained broken.
Figure (svg): WEP's key length increased from 40 to 104 bits, with the other flaws unchanged.
Concept
The designers knew that reusing a one-time pad is insecure. That is exactly why they included the IV — it makes the RC4 key different per packet, so the keystream should differ too.
With 24 bits there are about 1.7 × 10⁷ IVs. The book notes that a heavily used router might get through almost all of them in a short time. But the real problem arrives much sooner.
The birthday bound. With N = 2²⁴ values, √N = 2¹² = 4096. So after about 10 000 communications, some IV has very likely been used twice — and because the IV travels unencrypted, Eve can see the repeat happen.
Two packets with the same IV have the same RC4 keystream, so their XOR is the XOR of the two messages: Section 4.3's two-time pad, in a shipping standard.
Figure (svg): The 24-bit IV space against the birthday bound: a repeat is likely after about four thousand packets.
Worked example
The consequence goes further than reading two messages, and this is the step people miss.
Two ciphertexts with the same IV: C₁ ⊕ C₂ = M₁ ⊕ M₂
Why: The keystream cancels. Eve now has a classical language problem, exactly as in Section 4.3.
With plausible guesses about one message — headers, protocol structure — she recovers both
Why: Network traffic is highly structured, which makes this far easier than the book's ASCII example.
And she now has the RC4 keystream for that IV
Why: Because keystream = C₁ ⊕ M₁, and she knows both.
That is everything step 5 of the protocol needs to encrypt
Why: She can construct C = keystream ⊕ (message, ch) for any message she likes, and send it with that IV.
Verify: the WEP key is not required once the keystream for an IV is known
Why: So Eve gains the ability to send authenticated traffic through the router without ever learning the shared key. She has access to the network, not merely visibility of it — which is a much more serious outcome than reading two packets.
Figure (svg): The 24-bit IV space against the birthday bound: a repeat is likely after about four thousand packets.
Concept
The third flaw needs no repeated IV at all. It uses the checksum.
CRC-32 is an error-detecting code, and it is linear: ch(M ⊕ M₁) = ch(M) ⊕ ch(M₁). That is exactly the property that makes it good at detecting burst errors, and it is fatal here.
Eve intercepts C = RC4 ⊕ (M, ch(M)) and guesses correctly that the message contains an IP address at a known offset — say Send to IP address 69.72.169.241. Here is my credit card number...
She builds M₁: all zeros except, at the address's position, the XOR of the real address with her own, 172.16.254.1. Then:
\[ C \oplus \bigl(M_1, \, ch(M_1)\bigr) = RC4 \oplus \bigl(M \oplus M_1, \; ch(M) \oplus ch(M_1)\bigr) = RC4 \oplus \bigl(M_2, \, ch(M_2)\bigr) \]
The router accepts it as authentic and forwards it to Eve's address. She never decrypted anything and never learned M — she redirected it, and then read it at the destination.
Figure (svg): The CRC-32 forgery: because the checksum is linear, XORing a chosen difference into the ciphertext produces a message the router accepts.
Anomaly
Eve modifies an encrypted WEP packet so that it is delivered to her, without knowing the key or the plaintext.
Predict first
Which property of the design makes this possible?
Correct: CRC-32 being linear, combined with a stream cipher's bit-for-bit XOR
The fix is a message authentication code, not a checksum. A CRC detects accidental corruption and was designed for exactly that; a MAC resists an adversary choosing the corruption. Chapter 12's HMAC is the tool, and WEP's designers used the wrong category of primitive.
The general error is worth naming: an error-detecting code and a message authentication code look alike — both append a value that the receiver checks — and they defend against completely different adversaries. Substituting one for the other is a recurring mistake.
Why: Two properties combine. A stream cipher lets Eve flip any plaintext bit by flipping the corresponding ciphertext bit — the controlled forgery Chapter 6 warned about. And CRC-32's linearity means she can compute the matching checksum change without knowing the message. Either alone would be survivable; together they let her make a targeted, verifying modification to a message she cannot read.
Figure (svg): The CRC-32 forgery: because the checksum is linear, XORing a chosen difference into the ciphertext produces a message the router accepts.
Error analysis
The protocol, stated as its designers would have stated it.
Annotate
Four decisions. One was a compliance constraint, one was a miscalculation, and two were the wrong category of primitive. None was a mistake about RC4.
Picture it
Four failures, and the two columns that matter are what was sound and what was not.
Figure (svg): The pattern across all three case studies: sound primitives, and a failure in the assembly around them.
Read the left column and every entry is a respectable piece of engineering. Read the right and not one entry is about the mathematics.
Prediction
Thousands of deployed RSA keys shared a prime because their generators had too small an effective range.
Predict first
Which single change at design time would have prevented it?
Correct: Blocking entropy — refusing to generate a key until the pool has enough randomness
The trade is a real one: a device that will not boot until it has entropy is a device that appears broken, and that pressure is exactly why non-blocking sources are chosen.
The modern answer is to seed from a hardware random source at manufacture, or from a CPU instruction such as RDRAND, so the pool is never empty. Chapter 5's layered design — slow real entropy stretched by a fast one-way function — is the shape that works.
Why: The failure was devices generating keys at first boot before any entropy had accumulated, so the generator's effective range collapsed. A blocking entropy source — refusing to produce output until enough real randomness is available — makes the failure a delay rather than a silent weakness. Everything else in the list is good practice against a different attack, and none of it enlarges the seed's entropy.
Figure (svg): Two RSA moduli sharing a prime factor, broken by a single gcd.
Two truths and a lie
Two of these overstate what was found.
Eliminate the wrong options
Which statement is accurate?
Survives elimination: a
Why: 26 965 out of 11.4 million moduli in the Lenstra collection had a non-trivial gcd with another. The mathematics of RSA is untouched; the generators were at fault. And option (c) matters practically — it is why the affected parties had to be told rather than being able to check, and why the surveys were published as a warning rather than as a tool.
Error analysis
From an embedded device's provisioning routine, written to run at first boot.
Annotate
Four lines, four documented attacks, and the RSA arithmetic on the last line is entirely correct.
Socratic
The IV was not an oversight. It was there specifically because the designers understood keystream reuse.
Discussion prompt
What does that tell you about how this class of failure happens, and what would have caught it?
Hint: They knew the requirement and got the arithmetic wrong.
Answer:
They knew the rule. Reusing a one-time pad is insecure, so they added a per-packet value to make the keystream differ. The reasoning was correct.
They did not do the arithmetic. 2²⁴ ≈ 17 million looks like a lot of values, and the intuition 'it will take a long time to use them all' is the wrong question. The right question is when two of them coincide, and the answer is the square root.
So the failure is not ignorance of cryptography — it is a missing calculation. One square root, performed once at design time, would have shown 4096 and forced a wider field.
Which is why this category is worth a checklist rather than expertise. Anyone can compute 1.25√N for every field in a specification; nobody needs to be a cryptographer to do it.
And it generalises to the other failures here. Netscape's designers knew a seed was needed; they did not count how many seeds there were. The prime-generator failures knew randomness mattered; they did not count the generator's range.
The pattern is: the requirement was understood and the quantity was not checked.
Ranking
All four were found after deployment. Rank by how cheaply each was findable beforehand.
Put in order
Why: The IV needed one square root — a calculation on the specification, before any code existed. The seed needed a reading of the key generation path, which Goldberg and Wagner did from the public documentation. The shared factors needed the insight that a generator's range could be small enough for the birthday bound to apply across independent devices, which is subtler. And Enigma's feature required inventing the crib-dragging attack — genuine cryptanalysis, which is why it took a codebreaker rather than a reviewer. The ordering is really by how much creativity the discovery required, and the first two required almost none.
Real world
WEP's 40-bit key was not an engineering judgement. It was a legal constraint.
Discussion prompt
What were the export regulations, and what did they leave behind?
Hint: The rules changed; the deployed systems did not.
Answer:
US export regulations through the 1990s classified strong cryptography as a munition, capping exportable key lengths at 40 bits. Products shipped internationally used the weak version, and often the weak version was the only version.
So a generation of protocols carries a 40-bit mode: WEP, export-grade SSL ciphersuites, and the DES variants. Each was known to be inadequate at the time and shipped anyway.
The regulations relaxed around 2000. The protocols did not. Export ciphersuites remained in TLS implementations for compatibility, unused but negotiable — and that is where FREAK and Logjam came from in 2015, fifteen years later. An attacker downgraded a modern connection to an export-grade key and broke it.
The lesson about legacy is general: a weak option that is never used is not harmless, because negotiation can select it. TLS 1.3's response was to delete whole families of ciphersuites rather than deprecate them.
And the lesson about policy: a deliberate weakening for one purpose becomes a permanent structural weakness, because deployed protocols outlive the policies that shaped them by decades.
Analogy
Every WEP failure has appeared before in this course, in a different setting.
Match the pairs
Why: Four flaws, four earlier chapters, and no new cryptography anywhere. That is what makes WEP such a good case study: a reader who had internalised Chapters 1, 4, 5 and 6 could have predicted every one of its failures from the protocol description alone, without knowing any of the published attacks.
Estimation
A busy access point handles perhaps 500 packets per second.
Predict first
How long before an IV repeat is likely?
Correct: About 8 seconds
The related-key attack does even better in practice: rather than waiting for a collision, it collects packets with particular IV patterns and recovers the WEP key directly, needing tens of thousands of packets — minutes on a busy network, and injectable traffic can generate them on demand.
Which is the practical difference between a break and a vulnerability. Sweet32 needs 32 GB and hours; WEP needs seconds, and that is why replacement was urgent rather than scheduled.
Why: The birthday bound gives about 5100 packets, and at 500 per second that is roughly ten seconds. Even a lightly used home network reaches it in minutes. This is the number that made WEP not merely theoretically broken but practically trivial — tools that recover a WEP key in under a minute have existed since the mid-2000s.
Figure (svg): The 24-bit IV space against the birthday bound: a repeat is likely after about four thousand packets.
Sorting
The six review questions from this chapter, applied to failures across the whole course.
Sort into buckets
Sort each failure by the question that would have found it.
Six questions, six failures, and none of them required cryptanalysis to find.
Trade off
WEP's central category error, laid out. Fill the blanks.
Comparison matrix
| Checksum (CRC-32) | MAC (HMAC) | |
|---|---|---|
| Designed against | line noise and burst errors | an adversary who chooses the modification |
| Involves a secret? | no | yes — a shared key |
| Linear? | yes — which is what makes the forgery work | no |
| Cost | a few operations per byte | two hash computations |
| Appropriate for | detecting transmission errors | any setting with an adversary |
Both append a value the receiver checks, and they answer different questions. Substituting one for the other is the error, and the two rows that separate them are 'involves a secret' and 'linear'.
Counterexample
Replacing WEP meant new hardware for many devices. Suppose you had to keep the 24-bit IV field.
Discussion prompt
Could the protocol have been made secure within that constraint?
Hint: Ask what the IV is actually for, and whether 24 bits used differently would suffice.
Answer:
Use the field as a counter rather than a random value, and the birthday bound disappears entirely — 2²⁴ ≈ 17 million packets before a repeat instead of 4096. That is a four-thousand-fold improvement from reinterpreting the same 24 bits.
Rekey before the counter wraps. A fresh session key every few million packets means the counter never repeats under one key at all.
Derive the RC4 key by hashing rather than concatenating, so related-key weaknesses in the key schedule are not exposed. Same field, different combination.
But the CRC cannot be fixed within the format, because a MAC needs its own bytes and there is nowhere to put them. Integrity would have to move into the payload, which is a format change in all but name.
So three of the four flaws were fixable within the constraint, and the fourth was not — which is roughly what WPA with TKIP did as an interim measure, running on existing hardware while WPA2 waited for new silicon.
The exercise is worth doing because it separates the flaws that were design errors from the one that was a structural limitation. Three were choices; one was a missing field.
Explain it to yourself
Across this course, more systems failed on randomness than on any other cause.
Discussion prompt
Explain why, in terms of where the requirement lives and who is responsible for it.
Hint: Ask where in the codebase a nonce requirement appears, and who reads it.
Answer:
The requirement is stated in the cryptography and satisfied somewhere else. 'Choose a fresh random k' appears in the signature scheme's specification; the value is actually produced by a generator seeded by an operating system, in code no cryptographer reads.
A failure is invisible from both sides. The cryptographic code looks correct — it calls a random function. The system code looks correct — it returns bytes. Nothing in either place says the pool was empty at boot.
The output looks fine. A weak generator produces bytes that pass inspection, so there is no artefact to notice. Contrast a mode-of-operation bug, which produces a visibly repeating ciphertext.
And the consequence is total rather than gradual. A predictable nonce gives up a private key entirely; a weak seed collapses the whole key space. There is no partial failure to notice early.
Which is why the mitigation is structural rather than vigilant: deterministic nonces where possible, blocking entropy sources, hardware random sources at manufacture, and never generating long-term keys at first boot.
The general principle: a security requirement that crosses a component boundary is the one most likely to be dropped, because nobody on either side owns it.
Commit first
Four systems, all using current primitives correctly.
Predict first
Which is most likely to be compromised in the next five years?
Correct: A system generating keys on embedded devices at first boot
Notice that the question is not about which cryptography is weakest — all four are equally sound. It is about which process is most likely to violate a hypothesis, and that is where this chapter says to look.
The mitigation is cheap and well known: provision a hardware seed at manufacture, or refuse to generate long-term keys until the pool has entropy. It is not done because a device that boots slowly looks broken and a device with a weak key looks fine.
Why: First-boot key generation on embedded devices is precisely where the 2012 surveys found their shared factors, and the conditions have not changed — devices still boot with empty entropy pools, and the failure is invisible until someone runs a batch gcd across the internet. The other three are all comfortably within their parameters: 10⁶ messages against a 96-bit nonce is nowhere near 2⁴⁸, and both hash and signature choices are current.
Edge cases
WEP borrowed RC4 from cryptography and CRC-32 from networking, and combined them.
Discussion prompt
What has to be checked when a component designed for one purpose is used for another?
Hint: Each component was designed against a specific adversary, or against none.
Answer:
What adversary was it designed against? CRC-32 was designed against noise, which has no strategy. Using it against an attacker who chooses the corruption is a category change the component's specification never contemplated.
What does it guarantee, and over what range of inputs? RC4 is a keystream generator, guaranteeing nothing about related keys — so concatenating a varying IV onto a fixed key is outside what its analysis covered.
What does it assume about its inputs? A stream cipher assumes a fresh key per message. WEP's IV was an attempt to satisfy that, sized without checking.
And what happens at the seams? The CRC is computed over the plaintext and encrypted with it, so the integrity check is inside the confidentiality layer — which is what makes the linear forgery possible. Encrypt-then-MAC would have put it outside.
The rule: a component's security argument is scoped to the setting it was analysed in. Borrowing it into another setting means the argument does not transfer, and someone has to redo it.
This is the same statement as Chapter 4's, about hypotheses of a proof — and it is why 'we used standard components' is not a security argument.
Concept
Enigma, RSA key generation, and WEP have nothing in common technically. The failure has the same shape in all three.
That last point is the one worth sitting with. These are not stories about incompetence. They are stories about the difficulty of reasoning across a boundary — where a component's guarantee ends and the system's requirement begins.
Figure (svg): The pattern across all three case studies: sound primitives, and a failure in the assembly around them.
Ranking
Four separate problems, and fixing them in the wrong order is what actually happened.
Put in order
Why: The key length is the least damaging: it was fixable and was fixed, and the system stayed broken. The related-key structure enables the Fluhrer-Mantin-Shamir key-recovery attack, which is severe but needs traffic. The IV collision gives keystream reuse and — worse — the ability to inject traffic without the key, after only thousands of packets. And CRC-32 lets an attacker forge a verifying, redirected message with no repeated IV and no key at all, which is the most direct path to harm. The industry fixed them in exactly the reverse order of importance.
Definition probe
Sort these failures from across the whole course by what was actually wrong.
Sort into buckets
Classify each.
Socratic
WEP transmits the IV unencrypted alongside every packet, which is what lets Eve see collisions happen.
Discussion prompt
Why was that necessary, and could it have been avoided?
Hint: Ask what the router needs in order to decrypt.
Answer:
The router needs the IV to reconstruct the RC4 key, and it does not remember which IV it sent — the protocol note says so explicitly. So the IV must travel with the packet.
And it does not need to be secret. An IV's job is uniqueness, not confidentiality, exactly as with CBC's IV in Chapter 6 and a password salt in Chapter 7. Sending it openly is correct.
So the visibility is not the flaw. The flaw is that a value which must not repeat was given 24 bits, and the birthday bound was not applied. Had it been 96 bits, sending it in the clear would be entirely fine — that is what AES-GCM does.
Could it have been avoided? Yes, by using a counter rather than a random value. A per-session counter cannot repeat until it wraps, and 24 bits of counter would give 16.7 million packets rather than 4096. Even the same field width would have been an order of magnitude better used.
The lesson generalises: where a design needs a non-repeating value, a counter beats randomness by a square, and randomness must be sized against the birthday bound rather than against the total count.
Comparison
WPA and WPA2 fixed the flaws one by one. Fill the blanks.
Comparison matrix
| Flaw | WEP | WPA2 |
|---|---|---|
| Cipher | RC4 with a related-key structure | AES in CCM mode |
| Integrity | CRC-32 — linear, forgeable | CBC-MAC — a real authenticator |
| IV / nonce width | 24 bits, colliding after ~4000 packets | 48 bits, with a packet counter |
| Key per station | one key shared by everyone on the router | per-session keys derived from a handshake |
| Replay protection | none | the packet counter is checked |
Five rows, and only the first is about the cipher. WPA2 is what WEP would have been if each requirement had been matched to the right primitive.
Counterexample
The obvious response to a 40-bit key is to make it 104 bits, which is what the industry did.
Discussion prompt
Show that each of the three remaining attacks is entirely unaffected.
Hint: Write down what each attack actually uses.
Answer:
The IV collision is unchanged. The birthday bound depends on the IV's 24 bits and nothing else. 4096 packets still gives a repeat, and a longer WEP key does not widen the IV field.
The keystream-reuse consequence is unchanged. Once Eve has the keystream for an IV she can encrypt with it, and she never needed the WEP key — of any length.
The CRC-32 forgery is unchanged. It uses linearity of the checksum and bit-for-bit XOR of the stream cipher. Neither mentions the key.
**And the related-key attack gets better for the attacker in one sense:** a longer key means more key bytes to recover, but the Fluhrer-Mantin-Shamir attack recovers them incrementally, so it scales gently.
So three of four attacks are untouched and the fourth is barely slowed. This is the clearest demonstration in the book that fixing the parameter everyone can see is not the same as fixing the system — and it is Chapter 1's key-length argument arriving with a real deployment behind it.
Real world
The three case studies date from 1941, 1995 and 1997. The categories have not changed.
Discussion prompt
Name a recent instance of each of the chapter's three failure types.
Hint: A guaranteed property, a weak seed, and a mis-sized field.
Answer:
A guaranteed property, exploited: compression before encryption. CRIME and BREACH exploited the guarantee that compressed length reflects redundancy, so an attacker who can inject text into a request learns whether her guess matches the secret — from the ciphertext length, which no cipher hides.
A weak seed: the 2012 shared-factor surveys are the headline, and the pattern continued. Embedded devices generating keys at first boot, virtual machines cloned with their entropy pools, and containers starting from identical images have all produced duplicate keys since.
A mis-sized field: Sweet32 in 2016 — 64-bit block ciphers in long-lived TLS and VPN connections, where the birthday bound on the block gives a repeat after 32 GB. Exactly WEP's arithmetic, in a different field, twenty years later.
And the category error keeps recurring too: using a hash where a MAC is needed, which is Chapter 11's length extension, still appears in API authentication schemes written this year.
The value of this chapter is not the history. It is that the four categories are stable, so they can be checked for.
Commit first
You have limited time to review an unfamiliar cryptographic protocol.
Predict first
Which single question finds the most problems?
Correct: Which values must never repeat, how wide are they, and how are they generated?
The runner-up is the third category: is any value used as an authenticator that was designed as an error-detecting code, and is any hash being used where a MAC is needed?
The cipher choice is almost never the problem. Every system in this chapter used a reasonable primitive for its era, and the review time is better spent elsewhere.
Why: Nonces, IVs, salts and signature nonces are where this chapter's failures live, and where Chapters 4, 5, 6, 10 and 13 placed their failures too — Venona, WEP, the PlayStation 3, Debian, the shared factors. One question covers all of them, and the answer is usually either 'we did not size it' or 'from the system clock'.
Faded example
Four rules, one from each failure.
Fill in the blanks
Guarantee nothing about the ciphertext, because any guaranteed property is a free filter. Audit the seed, not the algorithm. Size any non-repeating value against the birthday bound. And never use an error-detecting code where a MAC is required.
Why: Four rules, four case studies, and each is checkable in a design review without running any cryptanalysis. That is what makes them useful: they turn a class of failures that took decades to discover into questions anyone can ask on a first reading of a specification.
Discrimination
The WEP failure was a category error, and the category is easy to mistake.
Sort into buckets
Sort each mechanism by what adversary it withstands.
Cost model
One formula, and it would have caught two of this chapter's failures at design time.
Annotate
On: \( \text{expected draws before a repeat} \approx 1.25\sqrt{N} \)
It is one square root, and it is the single most productive calculation to perform on an unfamiliar design.
Explain it
A colleague asks why WEP was replaced when RC4 was a respected cipher at the time.
Discussion prompt
Explain without attacking RC4, and give the one-sentence summary.
Hint: The cipher was never the problem, and saying so first makes the rest land.
Answer:
Start by conceding the point: RC4 was fine for its era, and no attack on WEP begins by breaking it.
Then the IV. WEP changes the encryption key per packet using a 24-bit counter sent in the open. Twenty-four bits sounds like plenty until you realise a repeat becomes likely after about four thousand packets — seconds of traffic. Two packets with the same key means the encryption cancels between them.
Then the consequence they will care about: once an attacker has recovered the keystream for one of those repeated values, she can send traffic through the access point. Not read it — send it. She is on the network.
Then the checksum. WEP checks integrity with a CRC, which is designed to catch line noise, not an attacker. Because a CRC is linear, an attacker can alter a packet in a chosen way and fix up the checksum without knowing what the packet says — the book's example redirects a message to the attacker's own IP address.
The one-sentence summary: WEP used good components to build a system whose non-repeating value repeated in seconds and whose integrity check was designed for noise rather than for an adversary.
Edge cases
The primitives are standard, the key sizes are current, and the code compiles.
Discussion prompt
What still has to be checked before a design can be signed off?
Hint: This chapter supplies four categories, and earlier chapters supply two more.
Answer:
Every value that must not repeat, with its width compared against 1.25√N and the system's lifetime volume — and whether it is a counter or random, and what resets it.
Every place a guarantee is made about the output, since a guaranteed property is a filter. Deterministic encryption, fixed-length outputs, and anything that 'always' holds.
Every check that distinguishes accidental from adversarial change, and whether a secret is involved in it.
Every source of randomness, back to its seed — Chapter 5's rule, and the one that has caused the most real damage.
Every construction, asking whether it is standard or invented: H(K‖m), a hand-rolled mode, a custom padding scheme. Chapter 6 and Chapter 11 both showed sound primitives in unsound wrappers.
And every parameter's expiry date, with a plan to change it — because Chapter 7's DES lesson is that the number will need to move within the system's life.
Six checks, none of which requires cryptanalysis, and between them they cover essentially every failure in this book.
Constraint
Same problem, 1997 constraints — modest hardware, a shared password, and packets of a few hundred bytes.
Discussion prompt
Specify it, and say which WEP flaw each decision removes.
Hint: Take the four flaws in turn and choose the right primitive for each.
Answer:
Derive a per-session key from the shared password and a handshake nonce, rather than using the password directly. This removes the related-key structure: RC4 never sees a key differing only in its first bytes.
Use a 48-bit packet counter as the nonce, not a 24-bit random IV. A counter cannot repeat until it wraps, so the birthday bound does not apply at all — 2⁴⁸ packets rather than 4096.
Rekey when the counter approaches its limit, so wrapping never happens in practice.
Authenticate with a MAC over the ciphertext and the nonce, not a CRC over the plaintext. This removes the forgery and, by covering the nonce, also removes replay when combined with the counter check.
Reject any packet whose counter is not greater than the last accepted one. Replay protection, one integer per peer.
And per-station session keys, so one compromised laptop does not give access to every other station's traffic — which WEP's single shared key did.
Five decisions, each removing one named flaw, and all of them available in 1997. That is roughly what WPA2 turned out to be.
Missing information
You are handed a specification for a new cryptographic protocol and have one page of questions.
Discussion prompt
Write the questions, in the order that finds the most problems fastest.
Hint: This chapter has just given you the ordering.
Answer:
1. What must never repeat, how wide is it, and how is it generated? Nonces, IVs, salts, signature nonces. This finds the most, fastest.
2. What provides integrity, and does it involve a secret? A CRC, a plain hash or a truncated checksum here is a category error.
3. Where does the randomness come from, and what happens at first boot or after a restore? The Netscape flaw, the shared factors, the Debian bug and the PlayStation 3 all live here.
4. What does the ciphertext guarantee? Determinism, fixed lengths, ordered fields — every guarantee is a filter.
5. Which constructions are standard and which were invented for this document? Invented ones need a reason, and rarely have one.
6. What is the plan when a parameter or algorithm ages? Is there a version field, a negotiation, a migration path?
And the meta-question: which of the answers depends on an assumption about the world rather than about mathematics? Those are the ones that quietly stop being true.
Matching
Four failures, four rules — and each rule is checkable without any cryptanalysis.
Match the pairs
Why: Four rules that fit on a card, and between them they cover the whole chapter. What makes them valuable is that none requires expertise to apply: reading a specification and asking these four questions would have caught three of the four failures before any code was written, and the fourth — Enigma's — is the one that genuinely needed a cryptanalyst.
Pattern
Fourteen chapters of attacks sort cleanly into four boxes, and their sizes are wildly uneven.
The practical consequence is a review order: randomness first, constructions second, parameters third, and the primitive last — which is close to the reverse of how most reviews are conducted.
Figure (svg): The pattern across all three case studies: sound primitives, and a failure in the assembly around them.
Trap
The trap. The design uses AES-256, SHA-256, RSA-3072 and a well-reviewed library. Every primitive is standard, current and unbroken. Therefore the system is secure, and the review can concentrate on other things.
This is a reasonable-sounding position, and it is the position the designers of WEP were in — RC4 and CRC-32 were both standard, respected and correctly implemented.
Why it fails. Not one of this chapter's failures involved a broken primitive. Enigma's rotors were sound and a design guarantee gave away the key. Netscape's RSA was correct and a timestamp seed collapsed the key space. WEP's RC4 was fine and a 24-bit field, a linear checksum and a shared key finished it.
A primitive's guarantee has boundaries, and systems fail at the boundaries. AES guarantees a permutation of one block; it says nothing about the second block, about who sent it, about whether it is fresh, or about where the key came from. Every one of those is somebody else's job.
And the standardness of the components can make things worse, by creating exactly this confidence. A team that has chosen good primitives feels finished, and the questions that remain are the ones this chapter's failures live in.
The correct claim is much narrower: using standard primitives removes one category of risk — the rarest one. It leaves the other three untouched, and they account for almost every failure in this book.
The habit: after checking the primitives, treat the review as not yet started. Then ask the six questions.
Check
Work it out before you click.
Check your understanding
An Enigma ciphertext contains every letter of the alphabet except Q. What does that suggest?
Answer: B
Why: Enigma's reflector guaranteed no letter encrypts to itself, so a plaintext of all Q could never produce a Q in the ciphertext. An absent letter in a message of any length is therefore evidence about the plaintext, obtained for free. This is exactly Mavis Batey's 1941 deduction with L, and it gave the day's key.
Check
Apply the birthday bound to WEP's field.
Check your understanding
WEP uses a random 24-bit IV. After roughly how many packets is a repeat likely?
Answer: B
Why: The birthday bound gives √N = 2¹² = 4096 — a few seconds of traffic on a busy access point. A repeated IV means a repeated RC4 keystream, which is Section 4.3's two-time pad; and recovering that keystream lets an attacker inject traffic without ever learning the WEP key.
Check
Identify what WEP's checksum was doing wrong.
Check your understanding
Why is CRC-32 unsuitable as WEP's integrity check?
Answer: B
Why: ch(M ⊕ M₁) = ch(M) ⊕ ch(M₁), so an attacker who wants to flip specific bits computes the corresponding checksum change without knowing the message. Combined with a stream cipher's bit-for-bit XOR, this lets her modify a packet in a chosen way and have it accepted. A CRC detects accidental corruption, which is what it was designed for; resisting an adversary needs a secret, and a CRC has none.
Connect it up
This chapter's value is a checklist, and writing it out is the way to keep it.
Draw it
List the four categories of failure with one example each from this course. Then write the six review questions in the order that finds problems fastest, and beside each write the case study from this chapter that it would have caught. Finish with the birthday formula and four worked instances: WEP's IV, a 64-bit block, a 96-bit nonce, and a prime generator with a million outputs.
Keep the checklist. Every chapter from here to the end of the book is protocols and applications, and these are the questions to read them with.
Exit ticket
One question, about what this chapter is for.
Predict first
What do the Enigma feature, Netscape's RSA primes and WEP have in common?
Correct: In all three the primitives were sound and the failure was in a parameter, an assumption or a category error around them
Why: Enigma's rotors, RSA's arithmetic and RC4's keystream were all sound and none was attacked. What failed was a guaranteed property that acted as a filter, a seed with almost no entropy, and a protocol combining a 24-bit non-repeating field with an error-detecting code used as an authenticator. Every break was on the outside of the mathematics, which is why the chapter exists and why it sits immediately before the protocols chapter.
Recap
Three case studies, four categories, and a checklist.
Chapter 15 next. Security protocols proper — intruders in the middle, key distribution, Kerberos, public key infrastructure, X.509 certificates, PGP, SSL and TLS. Every one of them is an assembly, and this chapter is the right frame to read them with.
Figure (svg): The pattern across all three case studies: sound primitives, and a failure in the assembly around them.
Want this taught 1-on-1? Alexander tutors Cryptography — $55/session, free consultation.