CS 161, Lesson 25, in 50 slides. It explains what randomness and entropy mean for cryptography, in section 9.1, then covers the pseudorandom generator with its Seed, Reseed, and Generate interface and the computational indistinguishability it aims at, in sections 9.1 and 9.2, and rollback resistance against state compromise in section 9.3. It adds real-world entropy failures - VM snapshots, the Debian OpenSSL bug, and weak entropy at boot - flagged as enrichment. It is anchored to textbook sections 9.1 to 9.3.
Subject: Computer Security · 81 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 25 of 45
randomness vs unpredictability · entropy · the pRNG · Seed/Reseed/Generate · rollback resistance · real-world entropy disasters
Objectives
Warm-up
Discussion prompt
Before we open L25 · Randomness, Entropy, pRNGs & Rollback Resistance: without looking back, what was the main idea of L24 · Authenticated Encryption & AEAD, and what could you do by the end of it that you could not do before?
Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.
Answer:
CS 161, Lesson 24, in 50 slides. It explains why a MAC gives no confidentiality, in section 8.6, then combines encryption with a MAC and compares the two orders in section 8.7: encrypt-then-MAC against MAC-then-encrypt, with the padding-oracle break that the latter allows. It covers authenticated encryption with associated data in section 8.8, and AES-GCM together with its catastrophic failure under nonce reuse. It is anchored to textbook sections 8.6 to 8.8.
Concept
Every cipher so far quietly assumed one thing: that we can produce good random bits for keys, IVs, and nonces. This lesson asks where those bits come from — and what happens when they're bad.
Counterexample
Discussion prompt
Every cipher so far quietly assumed one thing: that we can produce good random bits for keys, IVs, and nonces. This lesson asks where those bits come from — and what happens when they're bad.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Section
Part 1 · §9.1 randomness and entropy
Concept
Generating an AES key, an IV, or a nonce all start the same way: 'pick some random bits.' But not every source that looks random is safe — Eve only has to predict your bits, not literally observe them.
So the real requirement is sharper than 'random.' We need bits that are random and unpredictable to any attacker. This part defines what that means and measures it with entropy.
Concept
Randomness (for crypto) — A source is good for crypto only if its output is both random AND unpredictable: an attacker who knows everything about the source still cannot guess the next output better than chance.
A coin that lands heads 99% of the time is genuinely random — yet wildly predictable. Bet on heads and you're right almost every time. As a key source it is nearly worthless.
A fair coin — heads exactly half the time — is what we want: each flip is a true 50/50 you cannot predict. Crypto wants fair-coin bits, not just any random-looking bits.
Analogy
Discussion prompt
Explain §9.1 Random is not enough — it must be unpredictable by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
A coin that lands heads 99% of the time is genuinely random — yet wildly predictable. Bet on heads and you're right almost every time. As a key source it is nearly worthless.
Concept
Entropy — A measure of the uncertainty — the 'surprise' — in a random source. Low entropy = predictable (little surprise); high entropy = unpredictable (lots of surprise).
The biased 99%-heads coin has low entropy: you can almost always guess it, so there's little surprise. The fair coin has high entropy: every flip is a genuine surprise.
The uniform distribution — every outcome equally likely — maximizes entropy. For one bit, that's the fair coin: maximum possible uncertainty in a single bit.
Definition probe
Sort into buckets
Every line below is part of the definition of Randomness (for crypto) or of Entropy — one or the other, never both. Put each where it belongs.
Intuition
Think of entropy as how many real guesses an attacker has to make. A key built from fair coin flips forces Eve to search the whole space — there's no shortcut, because every bit is a true 50/50.
A key built from biased or patterned bits hands Eve a head start: she guesses the likely bits first and the effective search shrinks. The key is shorter than it looks. Low entropy = a smaller haystack.
Ask yourself: if I need a 128-bit key but each bit is 90% likely to be 0, is the attacker really facing 2^128 guesses? (No — predictable bits collapse the real search far below 2^128.)
Explain it
Discussion prompt
Explain §9.1 Why we want maximum-entropy bits to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Think of entropy as how many real guesses an attacker has to make. A key built from fair coin flips forces Eve to search the whole space — there's no shortcut, because every bit is a true 50/50.
Ranking
Put in order
Put the moves of §9.1 Biased vs fair coin, side by side into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. Both are 'random' in the everyday sense; we want to see which actually resists prediction.
Worked example
Compare two coins as key-bit sources: a biased coin (99% heads) and a fair coin (50/50)
Why: Both are 'random' in the everyday sense; we want to see which actually resists prediction.
Ask of each: how well can an attacker guess the next bit?
Why: Predictability is the whole question — Eve wins by guessing, not by watching.
| Source | P(predict next bit) | Entropy | Fit for keys? |
|---|---|---|---|
| Biased coin (99% heads) | ≈ 0.99 | low | no — guessable |
| Slightly biased (90/10) | ≈ 0.90 | low–medium | no — weakened |
| Fair coin (50/50) | 0.50 | maximum (1 bit) | yes — ideal |
Verify: only the fair, maximum-entropy coin forces a true 50/50 guess per bit
Why: §9.1: crypto wants uniform, maximum-entropy bits; any bias hands the attacker a better-than-chance guess and shrinks the real key space.
Comparison
Comparison matrix
From §9.1 Biased vs fair coin, side by side: refill the P(predict next bit) column from what you know. The rest of the table is as it appeared.
| Source | P(predict next bit) | Entropy | Fit for keys? |
|---|---|---|---|
| Biased coin (99% heads) | ≈ 0.99 | low | no — guessable |
| Slightly biased (90/10) | ≈ 0.90 | low–medium | no — weakened |
| Fair coin (50/50) | 0.50 | maximum (1 bit) | yes — ideal |
Concept
Where do genuinely unpredictable bits come from? From physical processes we believe are unpredictable: electrical noise in CPU circuitry, the exact microsecond a key is pressed, jitter between hardware clocks.
These true-random sources are slow and limited — and worse, they may themselves be biased (a noise source that leans toward 0). So we rarely have abundant, perfectly fair true randomness on tap; we have a trickle of imperfect entropy.
Step zero
Discussion prompt
§9.1 How bias shrinks an attacker's real search — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Want a 4-bit key, but each bit is biased 90% toward 0
Answer:
Worked example
Want a 4-bit key, but each bit is biased 90% toward 0
Why: A '4-bit key' suggests 2^4 = 16 equally likely values — but bias makes some far more likely than others.
Rank candidate keys by likelihood and let the attacker guess most-likely-first
Why: An attacker who knows the bias tries 0000 first, then keys with a single 1, and so on — the uniform-search assumption is gone.
| Key pattern | Relative likelihood | Attacker tries it… |
|---|---|---|
| 0000 (all likely bits) | highest | first |
| one 1 (e.g. 0010) | lower | early |
| 1111 (all unlikely bits) | lowest | last |
Verify: the effective search is far below 16 because guesses are not equally likely
Why: §9.1: low entropy means the attacker's ordered guessing succeeds quickly. A fair coin would make all 16 equally likely, forcing a full search — that's why we demand maximum entropy.
Trade off
Comparison matrix
From §9.1 How bias shrinks an attacker's real search: every row here is a choice with a cost. Fill the Relative likelihood column, then say which row you would actually pick and what you give up for it.
| Key pattern | Relative likelihood | Attacker tries it… |
|---|---|---|
| 0000 (all likely bits) | highest | first |
| one 1 (e.g. 0010) | lower | early |
| 1111 (all unlikely bits) | lowest | last |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'My source spits out unpredictable-looking bytes, so it's fine for keys. Random is random.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: A 99%-heads coin looks random but is highly predictable; a biased or patterned source has LOW entropy, so the attacker's real search is far smaller than the key length suggests.
A student: what actually makes a source fit for keys?
Why: A 99%-heads coin looks random but is highly predictable; a biased or patterned source has LOW entropy, so the attacker's real search is far smaller than the key length suggests. Looks-random ≠ unpredictable.
Trap
A student: 'My source spits out unpredictable-looking bytes, so it's fine for keys. Random is random.'
Treat any noisy / random-LOOKING source as a key source
Why: Wrong. A 99%-heads coin looks random but is highly predictable; a biased or patterned source has LOW entropy, so the attacker's real search is far smaller than the key length suggests. Looks-random ≠ unpredictable.
A student: what actually makes a source fit for keys?
Demand maximum-entropy, unpredictable bits — fair-coin behavior, not just noise
Why: §9.1: a key source must be random AND unpredictable. Bias and structure lower entropy and weaken every key built from them, no matter how random the output looks.
Section
Part 2 · §9.1–9.2 pseudorandom generators
Concept
A busy server needs random bits constantly — a session key here, an IV there, a nonce somewhere else. But true randomness arrives only as a slow trickle from noisy hardware. How do we keep up?
The answer is a pseudorandom generator (pRNG): collect a little true randomness once, then stretch it algorithmically into a long stream that looks random to everyone who doesn't hold the original secret.
Concept
Pseudorandom generator (pRNG) — A deterministic algorithm that takes a short, truly-random SEED and outputs a long sequence that is computationally indistinguishable from true random to anyone who does not know the seed.
Seed — The small piece of true randomness (high entropy) used to initialize the pRNG. The seed is the ONLY secret — everything downstream is computed from it.
So we pay the cost of true randomness once (to get the seed), then generate as many bits as we like — cheaply and quickly — from it.
Intuition
The pRNG output isn't actually random — it's fully determined by the seed. The claim is subtler: to anyone who does NOT know the seed, the stream is computationally indistinguishable from true random. They can't tell it apart in any feasible amount of time.
Think of the seed as a hidden recipe. Without it, the output looks like noise; with it, the whole sequence is reproducible exactly. The security lives entirely in keeping that recipe secret.
Ask yourself: how is this like Kerckhoff's principle from L18? (The algorithm is public; the SEED is the only secret — just like the key in a cipher.)
Concept
Same seed in, same stream out — every time. A pRNG is a deterministic function of its seed. That's a feature (reproducible, testable) and a danger (anyone who learns the seed reproduces every bit you generated).
\[ \textbf{Seed } s \;\longrightarrow\; \text{Generate} \;\longrightarrow\; b_1 b_2 b_3 \cdots \quad(\text{same } s \Rightarrow \text{same } b_i) \]
Concept
Unlike the one-time pad (L19), a pRNG is only computationally secure. The output is shorter on entropy than it looks: there are only as many possible streams as there are seeds.
With unlimited compute, an attacker could try all 2^n possible n-bit seeds, run the pRNG on each, and find the one that reproduces the observed output. The pRNG bets that this brute-force is infeasible — not impossible.
Intuition
A pRNG can hand you gigabytes of output, but it never creates entropy — it only spreads the seed's entropy thin. A 128-bit seed gives you 128 bits of real unpredictability, no matter how many bytes you draw afterward.
So the seed must be large enough on its own. Seed a strong pRNG from a weak, low-entropy source and the whole stream inherits that weakness — the Debian and boot-entropy disasters in Part 4 are exactly this mistake.
Ask yourself: if you seed a pRNG with only 16 bits of true entropy, how many distinct streams can it ever produce? (At most 2^16 — brute-forceable, no matter how long each stream is.)
Explain it
Discussion prompt
Explain §9.2 The seed is a bottleneck on real entropy to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Ask yourself: if you seed a pRNG with only 16 bits of true entropy, how many distinct streams can it ever produce? (At most 2^16 — brute-forceable, no matter how long each stream is.)
Intuition
We don't ask the pRNG for the whole stream at once — we ask for bits on demand, over and over. To do that, it remembers where it is: it carries internal state that advances each time it produces output.
Picture an odometer seeded to a secret start value. Each Generate call cranks it forward and emits some bits; the next call picks up exactly where the last left off. The state IS the secret-in-progress.
Ask yourself: if the internal state is the live secret, what's the disaster if an attacker reads it out of memory? (They can reproduce all future output — and, unless we're careful, past output too. That's Part 3.)
Concept
Seed(entropy) — Initialize the internal state from a fresh pool of true-random entropy. Called once at startup to plant the original secret.
Reseed(entropy) — Mix additional true-random entropy into the existing internal state, refreshing it without discarding what's there.
Generate(n) — Produce n pseudorandom output bits and advance the internal state so the next call continues the stream.
Matching
Match the pairs
Match each term to the definition this lesson gave it — not the one you would guess from the word.
Why: These are the working definitions of Entropy, Seed, Seed(entropy), Reseed(entropy), Generate(n) as L25 · Randomness, Entropy, pRNGs & Rollback Resistance uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.
Ranking
Put in order
Put the moves of §9.2 Tracing the pRNG interface into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. Plant high-entropy true randomness into the internal state once — this is the expensive step we pay only occasionally.
Worked example
Call Seed(entropy) at startup
Why: Plant high-entropy true randomness into the internal state once — this is the expensive step we pay only occasionally.
Call Generate(128) to get a 128-bit key
Why: Emit 128 pseudorandom bits and advance the state; cheap and fast because it's pure computation from the current state.
Later, call Reseed(entropy) when fresh randomness is available
Why: Stir new true entropy into the state, raising uncertainty for an attacker who may have been watching.
| Call | Touches state? | Returns bits? | Needs true entropy? |
|---|---|---|---|
| Seed(entropy) | sets it | no | yes |
| Generate(n) | advances it | yes (n bits) | no |
| Reseed(entropy) | mixes in | no | yes |
Verify: only Seed/Reseed consume true entropy; Generate runs free off the state
Why: §9.2: that's the whole point — pay for true randomness rarely (Seed/Reseed), then Generate as many indistinguishable bits as you need.
Comparison
Comparison matrix
From §9.2 Tracing the pRNG interface: refill the Needs true entropy? column from what you know. The rest of the table is as it appeared.
| Call | Touches state? | Returns bits? | Needs true entropy? |
|---|---|---|---|
| Seed(entropy) | sets it | no | yes |
| Generate(n) | advances it | yes (n bits) | no |
| Reseed(entropy) | mixes in | no | yes |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'The pRNG algorithm is strong, so even if the seed leaks, the output is still good random.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: A pRNG is DETERMINISTIC: same seed → same stream.
A student: what must stay secret for a pRNG to be safe?
Why: A pRNG is DETERMINISTIC: same seed → same stream. If Eve learns the seed (or the internal state), she reproduces every bit you've generated and will generate. The seed/state is the ONLY secret.
Trap
A student: 'The pRNG algorithm is strong, so even if the seed leaks, the output is still good random.'
Treat the algorithm as the secret and shrug off a leaked seed
Why: Wrong. A pRNG is DETERMINISTIC: same seed → same stream. If Eve learns the seed (or the internal state), she reproduces every bit you've generated and will generate. The seed/state is the ONLY secret.
A student: what must stay secret for a pRNG to be safe?
Guard the seed and internal state as the sole secret
Why: §9.2: by Kerckhoff the algorithm is public; security rests entirely on the seed/state being unpredictable and hidden. A known seed means no security at all.
Trap
A student: 'My pRNG passes statistical tests, so its output is genuinely random and as strong as a one-time pad.'
Equate pseudorandom output with true randomness
Why: Wrong. The output is DETERMINED by the seed — there are only 2^n possible streams for an n-bit seed. With unlimited compute an attacker can try all seeds and match the output. It is only COMPUTATIONALLY indistinguishable, not information-theoretically random.
A student: how random is pRNG output, really?
Call it computationally indistinguishable from random — nothing more
Why: §9.2: a pRNG is only computationally secure, unlike the one-time pad's information-theoretic secrecy. It bets brute-forcing all seeds is infeasible, not impossible.
Section
Part 3 · §9.3 rollback resistance
Concept
The basic guarantee — 'output looks random to someone without the seed' — assumes the attacker never sees inside. But real attackers sometimes compromise the internal state: a memory disclosure bug, a core dump, a cold-boot attack.
Once Eve holds the current state she can obviously compute all future output — it's deterministic. The sharper, less obvious question: can she also reconstruct the bits you already generated before the compromise?
Concept
Rollback resistance — Even if an attacker learns the internal state right after bit 100 is generated, they STILL cannot deduce any PREVIOUSLY-generated bit. Past output stays computationally indistinguishable from random.
The name says it: the attacker cannot 'roll back' the state to recover earlier output. A rollback-resistant pRNG makes its state a one-way street — you can step forward, but you can't reverse it to recover the past.
Intuition
A rollback-resistant pRNG updates its state with a one-way step each time it generates bits. Knowing the state after bit 100 doesn't let you compute the state before bit 100 — the update can't be run backwards.
Picture each Generate as shredding the old state into a new one via a one-way function. The new state is enough to march forward, but holds no recoverable trace of the old state that produced your earlier keys.
Ask yourself: if compromising today's state revealed yesterday's output, what would that mean for a key you generated and 'forgot' yesterday? (It would be exposed retroactively — exactly what rollback resistance prevents.)
Sorting
Sort into buckets
These are the pieces of L25 · Randomness, Entropy, pRNGs & Rollback Resistance, out of order. Put each one back under the part of the lesson it belongs to.
Concept
These are two separate promises. Output indistinguishability is about an OUTSIDER who never sees the state. Rollback resistance is about an INSIDER who steals the state and tries to recover earlier bits.
A pRNG can ace the first and fail the second: if its state update is reversible, the stream looks perfectly random to outsiders, yet anyone who grabs the state can wind it back and replay your past keys. Rollback resistance must be designed in deliberately.
Concept
Suppose one pRNG serves a whole system. It first Generates a long-lived secret key, then later Generates a public IV. The IV is meant to be public — but it came from the same generator.
If the pRNG is NOT rollback-resistant, an attacker who grabs the state at the IV stage could roll it back and recover the earlier secret key. Rollback resistance is exactly what stops a later, low-value draw from betraying an earlier, high-value secret.
Step zero
Discussion prompt
§9.3 The key-then-IV scenario, step by step — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Step 1 — the system calls Generate to produce a secret KEY from the…
Answer:
Worked example
Step 1 — the system calls Generate to produce a secret KEY from the pRNG
Why: This key is long-lived and high value; it must never leak. The state advances after this draw.
Step 2 — later, the system calls Generate again to produce a public IV from the SAME pRNG
Why: The IV is fine to publish, but it comes from the same internal state lineage as the secret key.
Step 3 — an attacker compromises the internal state at the IV stage (memory leak)
Why: Eve now holds the state as it stood AFTER the key was generated. Can she walk it backward to the key?
| pRNG | Recover future output? | Recover the earlier KEY? |
|---|---|---|
| NOT rollback-resistant | yes | YES — key exposed |
| Rollback-resistant | yes | NO — key stays safe |
Verify: only a rollback-resistant pRNG keeps the earlier secret key safe after the IV-stage compromise
Why: §9.3: rollback resistance guarantees past output (the key) stays indistinguishable from random even though the current state is known — the one-way update blocks the rollback.
Comparison
Comparison matrix
From §9.3 The key-then-IV scenario, step by step: refill the Recover the earlier KEY? column from what you know. The rest of the table is as it appeared.
| pRNG | Recover future output? | Recover the earlier KEY? |
|---|---|---|
| NOT rollback-resistant | yes | YES — key exposed |
| Rollback-resistant | yes | NO — key stays safe |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'My pRNG output passes every randomness test, so it's automatically rollback-resistant.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: These are DIFFERENT properties.
A student: what does rollback resistance actually require?
Why: These are DIFFERENT properties. A pRNG can be perfectly indistinguishable to an outsider yet, if its state update is reversible, let an attacker who STEALS the state roll back and recover earlier output. Not all secure pRNGs are rollback-resistant.
Trap
A student: 'My pRNG output passes every randomness test, so it's automatically rollback-resistant.'
Assume output indistinguishability implies state-compromise safety
Why: Wrong. These are DIFFERENT properties. A pRNG can be perfectly indistinguishable to an outsider yet, if its state update is reversible, let an attacker who STEALS the state roll back and recover earlier output. Not all secure pRNGs are rollback-resistant.
A student: what does rollback resistance actually require?
Require a one-way state update, separate from output quality
Why: §9.3: rollback resistance is an EXTRA guarantee about state compromise. You must design the state update to be irreversible; passing statistical tests on the output says nothing about it.
Section
Part 4 · ⊕ enrichment — beyond textbook §9
Concept
The next few slides are ⊕ enrichment — outside this textbook's §9, but they show what the theory protects against. All three are cases where the randomness assumption silently broke and crypto collapsed.
Matching
Match the pairs
From ⊕ Three real entropy disasters (beyond the notes) — match each one to what it actually does. The descriptions have been shuffled.
Why: VM snapshots ⊕, Debian OpenSSL ⊕, Weak boot entropy ⊕ are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Ranking
Put in order
Put the moves of ⊕ VM-snapshot replay attacks into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. Snapshots are routine — for backups, cloning, or rolling back after a crash.
Worked example
A virtual machine saves a SNAPSHOT of its full memory, including the pRNG's internal state
Why: Snapshots are routine — for backups, cloning, or rolling back after a crash. They capture state byte-for-byte.
The VM is later RESTORED from that snapshot — twice, or on two clones
Why: Restoring resets the pRNG to the exact state in the snapshot, so its internal state is now duplicated.
Both restored VMs call Generate and get the SAME 'random' bits
Why: A pRNG is deterministic: identical state ⇒ identical output. The same key, IV, or nonce comes out of both — reintroducing the catastrophic reuse from L19–L21.
⊕ Verify the danger: snapshot restore replays the pRNG state, so 'random' values repeat
Why: This is enrichment beyond §9, but it's exactly the failure §9.1's 'unpredictable, fresh entropy' requirement guards against.
Blank canvas
Draw it
Draw what ⊕ VM-snapshot replay attacks just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.
Concept
⊕ In 2006 a Debian maintainer, chasing a memory-analysis warning, removed a line that fed extra entropy into OpenSSL's pRNG. The effect, discovered in 2008 (CVE-2008-0166): the generator was seeded from almost nothing — essentially just the process ID.
⊕ With only ~32,768 possible seeds, every key Debian/Ubuntu systems generated for ~2 years was drawn from a tiny, enumerable set. Attackers could pre-compute them all. Keys that looked random had near-zero real entropy — exactly the §9.1 failure made concrete.
Concept
⊕ Routers, IoT gadgets, and headless servers often generate their long-term keys on first boot — before there's been any user input, disk activity, or network traffic to harvest entropy from. The entropy pool is nearly empty.
⊕ The 'Mining Your Ps and Qs' study (Heninger et al., USENIX 2012) scanned the live internet and found large numbers of devices sharing keys, or with keys factorable because two devices drew overlapping primes from the same weak boot-time entropy. Low boot entropy → predictable, repeated keys at scale.
Intuition
All three disasters share one root cause: the system believed it had fresh, unpredictable bits when it didn't. The pRNG was fine; its seed was empty, stale, or duplicated. The math never failed — the assumption feeding it did.
That's the lesson of §9 made real: a cipher is only as strong as the randomness underneath it. Snapshots replay the seed, Debian gutted the seed, embedded devices seeded before entropy existed — three ways to hand the attacker bits they could predict.
Ask yourself: in all three cases, would a stronger pRNG ALGORITHM have helped? (No — the seed was the problem, so better stretching of bad entropy still yields bad keys.)
Analogy
Discussion prompt
Explain ⊕ The common thread: a broken entropy assumption by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Ask yourself: in all three cases, would a stronger pRNG ALGORITHM have helped? (No — the seed was the problem, so better stretching of bad entropy still yields bad keys.)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Snapshots just save and restore a machine — they can't hurt my cryptography.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The snapshot captured the pRNG's internal state.
A student: how do you safely use crypto across a snapshot restore?
Why: The snapshot captured the pRNG's internal state. Restoring REPLAYS that state, so the deterministic pRNG re-emits the same 'random' values — reused keys/IVs, the L19–L21 break all over again.
Trap
A student: 'Snapshots just save and restore a machine — they can't hurt my cryptography.'
Restore a snapshot, then generate keys/IVs/nonces as usual
Why: Wrong. The snapshot captured the pRNG's internal state. Restoring REPLAYS that state, so the deterministic pRNG re-emits the same 'random' values — reused keys/IVs, the L19–L21 break all over again.
A student: how do you safely use crypto across a snapshot restore?
Reseed with fresh true entropy after any restore / clone before generating secrets
Why: ⊕ Beyond §9, but the fix is pure §9.2: a Reseed(entropy) injects new unpredictability so the restored VMs diverge instead of replaying identical output.
Section
Part 5 · §9.2–9.3 clarifying the guarantees
Concept
Restating it precisely: rollback resistance is about an attacker who compromises the current state. The guarantee protects everything generated before that moment — past output stays indistinguishable from random.
Direction: compromise now → can't recover earlier bits. It defends the key you already generated and moved on from, against a leak that happens later.
Concept
There's a mirror-image concern: an attacker who compromised the state in the past. Can they predict your future output? With a plain deterministic pRNG, yes — until you change the state with something they don't know.
The fix is Reseed: mixing in fresh true entropy updates the state with unpredictability the attacker never saw, so output after the reseed becomes unpredictable to them again. This complementary property is often called forward secrecy / prediction resistance via reseeding.
Intuition
Put both on one timeline with a state compromise marked on it. Rollback resistance looks leftward — protecting what came before the compromise. Reseed-based prediction resistance looks rightward — recovering protection for what comes after.
Rollback resistance is structural: it lives in a one-way state update, automatic. Future protection is active: it needs you to Reseed with new entropy the attacker hasn't seen. Two threats, two distinct defenses.
Ask yourself: which of the three functions restores future unpredictability after a past compromise? (Reseed — it injects fresh entropy the attacker never observed.)
Counterexample
Discussion prompt
Ask yourself: which of the three functions restores future unpredictability after a past compromise? (Reseed — it injects fresh entropy the attacker never observed.)
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'If my state leaked yesterday, I'll just Reseed today and yesterday's leaked keys are protected again.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Wrong direction. Reseed protects FUTURE output by adding unseen entropy.
A student: which property protects which bits?
Why: Wrong direction. Reseed protects FUTURE output by adding unseen entropy. It cannot un-leak bits an attacker already captured — past output is the job of rollback resistance, and only if it held BEFORE the compromise.
Trap
A student: 'If my state leaked yesterday, I'll just Reseed today and yesterday's leaked keys are protected again.'
Expect Reseed to retroactively protect already-generated output
Why: Wrong direction. Reseed protects FUTURE output by adding unseen entropy. It cannot un-leak bits an attacker already captured — past output is the job of rollback resistance, and only if it held BEFORE the compromise.
A student: which property protects which bits?
Match the direction: rollback resistance ⇒ past output; Reseed ⇒ future output
Why: §9.2–9.3: rollback resistance defends bits generated before a current-state compromise; Reseed with fresh entropy defends bits generated after a past compromise. They cover opposite directions in time.
Two truths and a lie
Sort into buckets
Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.
Constraint
Discussion prompt
Run The randomness & pRNG playbook with this step confiscated:
Keep the seed/state secret (Kerckhoff: the seed is the only secret); a leaked seed reproduces every bit.
Is it still possible? If it is, say what takes its place and what it costs you. If it is not, say exactly what that step was providing that nothing else does.
Hint: A step you can drop for free was never load-bearing. If you cannot drop it, name the thing that goes wrong the moment it is gone.
Answer:
Pattern
Edge cases
Discussion prompt
The randomness & pRNG playbook works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".
Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.
Answer:
Elimination
Eliminate the wrong options
Given a rollback-resistant pRNG, what can the attacker recover from the state captured at the IV stage?
3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.
Survives elimination: A
Why: §9.3: a pRNG is deterministic, so knowing the current state lets the attacker compute all FUTURE output. Rollback resistance is the extra guarantee that they CANNOT walk the state backward — the state update is one-way — so the earlier-generated secret key stays computationally indistinguishable from random. That's exactly why rollback resistance matters for a key-then-IV design: the later IV-stage compromise does not betray the earlier key.
Check
A system uses ONE pRNG: it first Generates a secret key, then later Generates a public IV. An attacker reads the pRNG's internal state out of memory right AFTER the IV is generated. The pRNG is rollback-resistant. Reason it through on paper first.
Check your understanding
Given a rollback-resistant pRNG, what can the attacker recover from the state captured at the IV stage?
Answer: A
Why: §9.3: a pRNG is deterministic, so knowing the current state lets the attacker compute all FUTURE output. Rollback resistance is the extra guarantee that they CANNOT walk the state backward — the state update is one-way — so the earlier-generated secret key stays computationally indistinguishable from random. That's exactly why rollback resistance matters for a key-then-IV design: the later IV-stage compromise does not betray the earlier key.
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — Randomness Means Unpredictability · Stretching Randomness: the pRNG · When the State Leaks: Rollback Resistance · When Entropy Fails in the Real World ⊕ · Two Directions: Rollback vs Forward. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now explain why crypto needs randomness that is also unpredictable and rank sources by entropy, state what a pRNG is and define Seed/Reseed/Generate, explain rollback resistance through the key-then-IV scenario, and recognize how VM snapshots, the Debian OpenSSL bug, and weak boot entropy broke real systems.
| Idea | § | The one-line version |
|---|---|---|
| Good randomness | 9.1 | Random AND unpredictable — want fair-coin, max entropy |
| Entropy | 9.1 | Uncertainty/surprise; uniform distribution maximizes it |
| pRNG | 9.1–9.2 | Deterministic: short seed → long stream, computationally indistinguishable |
| Three functions | 9.2 | Seed init · Reseed mix-in · Generate(n) emit + advance |
| Seed is the secret | 9.2 | Kerckhoff: algorithm public, seed/state only secret |
| Rollback resistance | 9.3 | State leak now ⇒ can't recover earlier bits (one-way) |
| Two directions | 9.2–9.3 | Rollback guards the past; Reseed guards the future |
| ⊕ Real failures | — | VM snapshots · Debian OpenSSL · weak boot entropy |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.