CS 161, Lesson 18, in 50 slides. It covers Kerckhoff's Principle, which holds that the key is the only secret, then the hierarchy of attacker models running from COA through KPA, replay, CPA, and CCA to CCA2, and an informal IND-CPA security game. Together these set the rules of the game for the whole cryptography unit. It is anchored to textbook sections 5.8 to 5.9 and to section 6.1.
Subject: Computer Security · 83 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 18 of 45
Kerckhoff's Principle · the attacker-model hierarchy · the IND-CPA game
Objectives
Warm-up
Discussion prompt
Before we open L18 · Kerckhoff's Principle, Attacker Models & IND-CPA: without looking back, what was the main idea of L17 · Confidentiality, Integrity, Authenticity & the Scheme Families, 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 17, in 51 slides. It covers the three core goals of cryptography - confidentiality, integrity, and authenticity - plus deniability, and lays out the two-by-two grid of scheme families, crossing symmetric against asymmetric with confidentiality against integrity. It is anchored to textbook sections 5.6 to 5.7.
Concept
Before we can build a cipher, we have to agree on the rules of the game — what the attacker knows, what the attacker can do, and what 'winning' means for each side.
Matching
Match the pairs
From Three questions this lesson answers — match each one to what it actually does. The descriptions have been shuffled.
Why: What does Eve know?, What can Eve do?, What is 'secure'? are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Section
Part 1 · §5.8 Kerckhoff's Principle
Concept
Imagine you ship an encrypted messaging app to a million phones. Some day an attacker reverse-engineers one copy and learns exactly how it works. Is your security over?
If the answer is 'yes,' you built the wrong system. The fix you'd want is one where leaking the design changes nothing — and only a small, swappable secret matters.
Counterexample
Discussion prompt
Imagine you ship an encrypted messaging app to a million phones. Some day an attacker reverse-engineers one copy and learns exactly how it works. Is your security over?
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.
Answer:
If the answer is 'yes,' you built the wrong system. The fix you'd want is one where leaking the design changes nothing — and only a small, swappable secret matters.
Concept
Kerckhoff's Principle — A cryptosystem should remain secure even when the attacker knows all internal details of the system. The key should be the only thing kept secret, and the system should be designed so that leaked keys are easy to change.
So we assume the attacker knows the encryption and decryption algorithms. The one thing they lack is the secret key.
Intuition
It is far easier to change a key than to replace every running copy of the software. A key is a short string you can rotate in seconds; the algorithm is baked into millions of installed binaries.
So we deliberately concentrate all the secrecy into the one part that is cheap to replace. If it leaks, you swap it and move on — you don't recall a million phones.
Ask yourself: which would you rather have to change after a breach — one 256-bit number, or the entire codebase the world already downloaded?
Analogy
Discussion prompt
Explain §5.8 Why a key, and not the whole design? 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: which would you rather have to change after a breach — one 256-bit number, or the entire codebase the world already downloaded?
Ranking
Put in order
Put the moves of §5.8 Breach response: rotate the key, not the app 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. Under Kerckhoff this is allowed: the design was never the secret, so nothing is lost yet.
Worked example
An attacker reverse-engineers a shipped binary and publishes the full algorithm
Why: Under Kerckhoff this is allowed: the design was never the secret, so nothing is lost yet.
Separately, suppose one device's key also leaks
Why: Now the actual secret is exposed for that device — this is the part that matters.
Generate and distribute a fresh key; revoke the old one
Why: A key is a short string designed to be easy to change, so recovery is a rotation, not a recall.
Compare the alternative: re-architecting and re-shipping the algorithm to a million devices
Why: If security had depended on the secret design, the only fix would be replacing every running copy — infeasible. Kerckhoff makes the cheap fix the only fix you ever need.
Blank canvas
Draw it
Draw what §5.8 Breach response: rotate the key, not the app 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
Kerckhoff's Principle is closely related to Shannon's Maxim from Lesson 2 (§1.9): don't rely on security through obscurity. Assume the attacker has the design.
Lesson 2 gave the general design rule; the crypto unit gives it teeth: the only thing standing between Eve and the plaintext is a secret key, never a secret algorithm.
Explain it
Discussion prompt
Explain §5.8 This is Shannon's Maxim again 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:
Kerckhoff's Principle is closely related to Shannon's Maxim from Lesson 2 (§1.9): don't rely on security through obscurity. Assume the attacker has the design.
Step zero
Discussion prompt
§5.8 The Enigma story justifies the assumption — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Note how widely the Enigma machine was deployed in WWII
Answer:
Worked example
Note how widely the Enigma machine was deployed in WWII
Why: Thousands of machines were in the field across the German military — a design used that broadly cannot stay physically secret.
Predict what a determined adversary will eventually do
Why: Given how widely Enigma was used, the Allies were bound to capture a machine sooner or later.
Observe the outcome: they did capture one
Why: Once the Allies had a machine, the algorithm was no longer secret — only the daily key settings remained unknown.
Draw the lesson: design for a captured machine from day one
Why: If you assume the device will be captured, you stop relying on the design being secret and put all the secrecy in the key — exactly Kerckhoff's Principle.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A vendor: 'Our cipher is custom and confidential, so even without a strong key it's safe — nobody knows how it works.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Violates Kerckhoff / Shannon's Maxim.
A vendor: 'Our cipher is custom and confidential, so even without a strong key it's safe — nobody knows how it works.'
Why: Violates Kerckhoff / Shannon's Maxim. Reverse engineering, a leaked binary, or a captured device removes the secret — and then there is no security left.
Trap
A vendor: 'Our cipher is custom and confidential, so even without a strong key it's safe — nobody knows how it works.'
Count the secret design as part of the security
Why: Violates Kerckhoff / Shannon's Maxim. Reverse engineering, a leaked binary, or a captured device removes the secret — and then there is no security left.
A vendor: 'Our cipher is custom and confidential, so even without a strong key it's safe — nobody knows how it works.'
Assume the attacker already has the algorithm; rest all security on the secret key
Why: §5.8: the design must be publishable. Secrecy of the algorithm may be a thin extra layer at best, never the foundation.
Section
Part 2 · §5.9 Threat models
Concept
When we say Eve knows the system, we mean the encryption and decryption algorithms — the full procedure, parameters, and any public constants. Everything except the key.
Concretely, assume Eve has read the spec, disassembled the binary, and owns an identical device. The only blank in her copy is the secret key.
Concept
Kerckhoff fixes what Eve knows (everything but the key). A threat model fixes what Eve can do — how much access she has to ciphertexts, plaintexts, and the machinery.
The models form a hierarchy, from weakest to strongest. A scheme secure against a stronger model is automatically secure against the weaker ones.
Concept
Ciphertext-only attack (COA) — Eve intercepts a single ciphertext and wants to recover the plaintext. She has nothing else — no matching plaintexts, no machinery.
This is the weakest attacker. If a scheme can't survive even this, it is useless.
Definition probe
Sort into buckets
Every line below is part of the definition of Kerckhoff's Principle or of Ciphertext-only attack (COA) — one or the other, never both. Put each where it belongs.
Concept
Known-plaintext attack (KPA) — Eve has a ciphertext AND some or all of the corresponding plaintext for it. She uses those known pairs to attack other ciphertexts.
More realistic than it sounds: message headers, fixed greetings, and protocol fields are often predictable, handing Eve plaintext for free.
Intuition
KPA feels like a gift to Eve — 'how would she ever have the plaintext?' But structured data is full of fixed pieces she can guess in advance.
Email headers, 'Content-Type:' lines, file-format magic bytes, the standard 'BEGIN' of a key file — all predictable. Each one hands Eve a plaintext/ciphertext pair for free.
Ask yourself: this is why the Allies could attack Enigma traffic — what predictable word do you think weather reports always contained? (They guessed common words like 'Wetter'.)
Concept
Replay attack — Eve re-sends a captured ciphertext to trigger its effect again — without ever decrypting it.
The shocking part: Eve never needs to know what the message says. Capturing and resending the bits is enough to cause harm.
Step zero
Discussion prompt
§5.9 The 'pay Eve $100' replay — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Alice's bank sends an encrypted instruction: 'pay Eve $100'
Answer:
Worked example
Alice's bank sends an encrypted instruction: 'pay Eve $100'
Why: It is properly encrypted, so Eve cannot read or forge a new instruction.
Eve captures that ciphertext off the wire
Why: Kerckhoff says she can intercept traffic; she now holds the exact bits the bank accepted once.
Eve resends the same ciphertext to the bank, repeatedly
Why: Each replay looks like a fresh, valid 'pay Eve $100' instruction — so Eve gets paid many times over.
Note: Eve never decrypted anything
Why: Confidentiality was intact, yet the system was defeated. Replay attacks bypass secrecy entirely — they target the lack of freshness, not the cipher.
Concept
Chosen-plaintext attack (CPA) — Eve can trick Alice into encrypting messages of Eve's choosing, observe the resulting ciphertexts, and then attack a different, unknown target ciphertext.
Stronger than KPA: Eve doesn't have to wait for useful plaintext to show up — she picks the plaintexts and watches what comes out.
Intuition
It sounds artificial until you remember real systems encrypt attacker-influenced data all the time: a web server encrypts a search term you typed, a VPN encrypts the packet you just sent it.
So if Eve can choose part of what gets encrypted under Alice's key, she's running a chosen-plaintext attack — even though no one 'handed her the key.'
Ask yourself: in HTTPS, who supplies a lot of the plaintext the server encrypts back to you? (Often you — or an attacker injecting requests.)
Ranking
Put in order
Put the moves of §5.9 CPA: the encryption oracle, step by step 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. This is the formal meaning of 'trick Alice into encrypting' — Eve never sees the key, only inputs and outputs.
Worked example
Eve has access to an encryption oracle: she hands in any message and gets back its ciphertext under Alice's key
Why: This is the formal meaning of 'trick Alice into encrypting' — Eve never sees the key, only inputs and outputs.
Eve queries the oracle on plaintexts of her choosing and records the (message, ciphertext) pairs
Why: She is building a custom dictionary of how the cipher behaves on inputs she controls — far more useful than waiting for plaintext to appear (KPA).
A separate target ciphertext C* arrives that Eve did NOT request
Why: The goal is to learn something about C*'s plaintext using everything the oracle taught her.
Verify the threat: if the oracle's behavior reveals structure, C* leaks
Why: CPA is strictly stronger than KPA because Eve picks the probes — and as Part 4 shows, this is exactly the power that breaks a deterministic cipher.
Concept
Chosen-ciphertext attack (CCA) — Eve can trick Bob into decrypting ciphertexts of her choosing — any ciphertext other than the actual target — and learn the results.
Now the oracle is on the decryption side. Eve feeds Bob crafted ciphertexts and studies how he reacts.
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 Ciphertext-only attack (COA), Known-plaintext attack (KPA), Replay attack, Chosen-plaintext attack (CPA), Chosen-ciphertext attack (CCA) as L18 · Kerckhoff's Principle, Attacker Models & IND-CPA uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.
Concept
Chosen-plaintext/ciphertext attack (CCA2) — Eve has BOTH powers at once: she can get Alice to encrypt chosen plaintexts and get Bob to decrypt chosen ciphertexts. This is the most serious threat model.
The one thing Eve still can't do is trick Bob into decrypting the actual target ciphertext — if she could, the game would be trivial.
Worked example
Lay the models out from weakest to strongest
Why: Each row gives Eve strictly more power than the one above it; security against a lower row is implied by security against a higher one.
| Model | Eve's power | Example |
|---|---|---|
| Ciphertext-only (COA) | Sees one ciphertext | Intercept a single encrypted message, want the plaintext |
| Known-plaintext (KPA) | Sees ciphertext + its plaintext | Predictable header gives a plaintext/ciphertext pair |
| Replay | Resends a captured ciphertext | Replay 'pay Eve $100' to get paid repeatedly (no decryption) |
| Chosen-plaintext (CPA) | Tricks Alice into encrypting chosen messages | Submit plaintexts, watch ciphertexts, attack a new one |
| Chosen-ciphertext (CCA) | Tricks Bob into decrypting chosen ciphertexts | Feed Bob crafted ciphertexts, study the responses |
| Chosen-plaintext/ciphertext (CCA2) | Both of the above at once | Most serious model; can't decrypt the target itself |
Mark where THIS class lives
Why: Modern schemes aim for security against chosen-plaintext/ciphertext, but CS 161 focuses primarily on chosen-plaintext (CPA) — so CPA is the bar we'll hold ciphers to.
Comparison
Comparison matrix
From §5.9 The hierarchy as one table: refill the Eve's power column from what you know. The rest of the table is as it appeared.
| Model | Eve's power | Example |
|---|---|---|
| Ciphertext-only (COA) | Sees one ciphertext | Intercept a single encrypted message, want the plaintext |
| Known-plaintext (KPA) | Sees ciphertext + its plaintext | Predictable header gives a plaintext/ciphertext pair |
| Replay | Resends a captured ciphertext | Replay 'pay Eve $100' to get paid repeatedly (no decryption) |
| Chosen-plaintext (CPA) | Tricks Alice into encrypting chosen messages | Submit plaintexts, watch ciphertexts, attack a new one |
| Chosen-ciphertext (CCA) | Tricks Bob into decrypting chosen ciphertexts | Feed Bob crafted ciphertexts, study the responses |
| Chosen-plaintext/ciphertext (CCA2) | Both of the above at once | Most serious model; can't decrypt the target itself |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Chosen-plaintext means Eve picks ciphertexts and has Bob decrypt them.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Wrong direction. That description is the chosen-CIPHERTEXT attack — and it points at Bob, not Alice.
A student: which way does each attack point?
Why: Wrong direction. That description is the chosen-CIPHERTEXT attack — and it points at Bob, not Alice.
Trap
A student: 'Chosen-plaintext means Eve picks ciphertexts and has Bob decrypt them.'
Mix up which party Eve manipulates
Why: Wrong direction. That description is the chosen-CIPHERTEXT attack — and it points at Bob, not Alice.
A student: which way does each attack point?
Chosen-PLAINTEXT: trick ALICE into ENCRYPTING chosen plaintexts. Chosen-CIPHERTEXT: trick BOB into DECRYPTING chosen ciphertexts
Why: §5.9: 'plaintext' = the encryption oracle (Alice's side); 'ciphertext' = the decryption oracle (Bob's side). Match the word to the operation.
Section
Part 3 · §6.1 IND-CPA
Concept
Our first instinct is to say a scheme is confidential if 'Eve can't read M.' But that bar is hopelessly fuzzy.
Intuition
The honest standard isn't 'Eve learns nothing about M in the universe.' It's that the ciphertext should give her no information she didn't already have.
Better definition: the ciphertext C should give the attacker no additional information about M beyond what she knew before seeing C.
Ask yourself: how do you test 'C added nothing'? You compare a world where Eve sees C against a world where she only guesses — and demand they're the same.
Concept
We formalize 'no additional information' as a game between a challenger (Alice) and an adversary (Eve).
Eve names two messages she's curious about. Alice secretly encrypts one of them. Eve must figure out which one — using only the ciphertext.
\[ M_0, M_1 \;\longrightarrow\; \text{Alice encrypts } M_b \;\longrightarrow\; \text{Eve guesses } b \]
Sorting
Sort into buckets
These are the pieces of L18 · Kerckhoff's Principle, Attacker Models & IND-CPA, out of order. Put each one back under the part of the lesson it belongs to.
Step zero
Discussion prompt
§6.1 Walk the indistinguishability game — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Eve picks two messages M_0 and M_1 and sends both to Alice
Answer:
Worked example
Eve picks two messages M_0 and M_1 and sends both to Alice
Why: Crucially, Eve chooses them and knows both — the messages are not secret. Only which one gets encrypted is secret.
\[ b \xleftarrow{\$} \{0, 1\} \]
Alice flips a fair coin to pick a bit b, then returns the ciphertext of M_b
Why: Alice encrypts exactly one of the two messages; b records her choice and stays hidden from Eve.
\[ C = \mathrm{Enc}(K, M_b) \]
Eve examines C and outputs a guess b' for which message was encrypted
Why: This is the whole attack: from the ciphertext alone, decide whether it hid M_0 or M_1.
Verify the success criterion: a confidential scheme forces Pr[b' = b] = 1/2
Why: If C leaks nothing about M_b, Eve can do no better than guessing — exactly 1/2, the same odds she had before seeing C. Any edge above 1/2 is leaked information.
Notation
Annotate
From §6.1 Walk the indistinguishability game — read this one piece at a time. What is each part doing?
On: \( b \xleftarrow{\$} \{0, 1\} \)
Intuition
Picture two parallel worlds. In World 0, Alice always encrypts M_0; in World 1, she always encrypts M_1. Eve is dropped into one of them and must say which.
If the ciphertexts in the two worlds look indistinguishable to Eve, she's stuck guessing — that's where the word IND (indistinguishability) comes from.
Ask yourself: if Eve could reliably tell the worlds apart, what did the ciphertext have to leak about which message it hid? (At least one usable bit.)
Concept
We measure how far above pure guessing Eve can get. That gap is her advantage.
\[ \mathrm{Adv}(\text{Eve}) = \left| \Pr[b' = b] - \tfrac{1}{2} \right| \]
Secure means this advantage is negligibly small: seeing the ciphertext barely helps Eve beat a coin flip.
Step zero
Discussion prompt
§6.1 The BUY-or-SELL case made concrete — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Eve already knows Alice's order is exactly one of two messages: 'BUY'…
Answer:
Worked example
Eve already knows Alice's order is exactly one of two messages: 'BUY' or 'SELL'
Why: This is the prior partial information the vague definition couldn't handle — and it's realistic for a market order.
Set M_0 = 'BUY' and M_1 = 'SELL' and run the game
Why: The game is built precisely for this situation: Eve's two candidate messages become the two challenge messages.
Alice returns C = Enc(M_b); Eve must guess whether it's BUY or SELL
Why: Reading 'BUY vs SELL' off the ciphertext is the only thing Eve cares about — the dollar figures don't matter if she knows the direction.
Verify the standard: a secure scheme keeps her at Pr = 1/2 here
Why: §6.1: even though Eve knew the message was one of two specific values, the ciphertext must not tip her past a coin flip. That is exactly 'no additional information.'
Blank canvas
Draw it
Draw what §6.1 The BUY-or-SELL case made concrete 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
One honest limitation: the ciphertext generally reveals the length of the plaintext. IND-CPA is stated for messages of equal length so this leak doesn't trivially win the game.
So Eve picking M_0 and M_1 of different lengths isn't a fair break — it's a known, accepted leak. Hiding length needs separate padding measures, not the cipher alone.
Explain it
Discussion prompt
Explain §6.1 What IND-CPA does NOT hide: length 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:
One honest limitation: the ciphertext generally reveals the length of the plaintext. IND-CPA is stated for messages of equal length so this leak doesn't trivially win the game.
Concept
Now give Eve the chosen-plaintext power from Part 2: alongside the game, she may trick Alice into encrypting any messages she likes and study the results.
IND-CPA — Indistinguishability under chosen-plaintext attack: even with an encryption oracle, Eve cannot guess b in the M_0/M_1 game with probability better than 1/2 by more than a negligible amount.
Intuition
Eve already knows M_0 and M_1 — she chose them. The only thing she's missing is the bit b. So '1/2' literally means: the ciphertext told her nothing she could use to recover that one bit.
If Eve could ever get to, say, 60%, then the ciphertext leaked roughly a fifth of a bit of information about which message it hid. IND-CPA says: not even that.
Ask yourself: why frame it as distinguishing two messages instead of 'recover M'? Because if Eve can't even tell two known messages apart, she certainly can't read an unknown one.
Analogy
Discussion prompt
Explain §6.1 Why 1/2 is exactly the right target 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:
Eve already knows M_0 and M_1 — she chose them. The only thing she's missing is the bit b. So '1/2' literally means: the ciphertext told her nothing she could use to recover that one bit.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'IND-CPA guarantees Eve learns literally nothing about any message in any situation.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Too strong. Eve might already know things (M is BUY or SELL); IND-CPA can't erase prior knowledge or hide the message length.
A student: state the IND-CPA guarantee precisely.
Why: Too strong. Eve might already know things (M is BUY or SELL); IND-CPA can't erase prior knowledge or hide the message length.
Trap
A student: 'IND-CPA guarantees Eve learns literally nothing about any message in any situation.'
Overstate the guarantee
Why: Too strong. Eve might already know things (M is BUY or SELL); IND-CPA can't erase prior knowledge or hide the message length.
A student: state the IND-CPA guarantee precisely.
Frame it as: Eve can't do better than 1/2 at distinguishing two messages SHE chose, even with an encryption oracle
Why: §6.1: IND-CPA is about the ciphertext adding no usable information beyond what Eve had before — not about omniscience being revoked.
Break the constraint
Discussion prompt
The rule this trap just fixed:
A student: state the IND-CPA guarantee precisely.
Now break it on purpose. Build a case that violates it and follow the consequences until something visibly fails. Where does the failure first show up — and would you have noticed it if you had not been looking?
Hint: The dangerous rules are the ones whose violation still produces an answer. If yours fails loudly, try to find one that fails quietly.
Answer:
Too strong. Eve might already know things (M is BUY or SELL); IND-CPA can't erase prior knowledge or hide the message length.
Section
Part 4 · the determinism trap
Concept
IND-CPA is a strict bar by design. A scheme that leaks even one bit of M, or that reveals when two plaintexts are equal, already gives Eve an edge above 1/2 — so it fails.
The most common way to fail: determinism. If the same plaintext always produces the same ciphertext, Eve can tell repeats apart.
Counterexample
Discussion prompt
The most common way to fail: determinism. If the same plaintext always produces the same ciphertext, Eve can tell repeats apart.
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.
Ranking
Put in order
Put the moves of Break a deterministic cipher in the game 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. No randomness means the mapping from message to ciphertext is a fixed function — identical inputs give identical outputs.
Worked example
Suppose Enc is deterministic: same plaintext → same ciphertext, every time
Why: No randomness means the mapping from message to ciphertext is a fixed function — identical inputs give identical outputs.
Eve uses her chosen-plaintext oracle to encrypt M_0 once, recording c_0
Why: CPA power lets her get the exact ciphertext that M_0 produces under the key.
Eve submits M_0 and M_1 to the challenge and receives C = Enc(M_b)
Why: Now she just compares the challenge ciphertext to the one she already computed.
\[ b' = \begin{cases} 0 & \text{if } C = c_0 \\ 1 & \text{otherwise} \end{cases} \]
Verify Eve wins with probability 1, far above 1/2
Why: If C equals c_0 the message was M_0; if not, it was M_1. Determinism turned the 'is it a repeat?' question into a perfect distinguisher — so the scheme is not IND-CPA.
Notation
Annotate
From Break a deterministic cipher in the game — read this one piece at a time. What is each part doing?
On: \( b' = \begin{cases} 0 & \text{if } C = c_0 \\ 1 & \text{otherwise} \end{cases} \)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'My cipher is unbreakable AND deterministic — same input always gives the same output, which is cleaner.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: It can't. Eve submits M_0, then sees a repeat in the challenge and wins with certainty — no matter how strong the underlying primitive is.
A student: how do we keep equal plaintexts from producing equal ciphertexts?
Why: It can't. Eve submits M_0, then sees a repeat in the challenge and wins with certainty — no matter how strong the underlying primitive is.
Trap
A student: 'My cipher is unbreakable AND deterministic — same input always gives the same output, which is cleaner.'
Assume strength of the cipher rescues determinism
Why: It can't. Eve submits M_0, then sees a repeat in the challenge and wins with certainty — no matter how strong the underlying primitive is.
A student: how do we keep equal plaintexts from producing equal ciphertexts?
Make encryption randomized / probabilistic, so the same M can encrypt to many different C
Why: §6.1: a fresh random choice (an IV/nonce, or OTP-style randomness) breaks the repeat signal, which is the only way to reach IND-CPA.
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.
Concept
This is exactly why ECB mode (L20) and textbook RSA (L28) are insecure: both are deterministic, so identical blocks or messages leak as identical ciphertexts.
And it's why every real confidentiality scheme is randomized: CTR/CBC use a random IV, OAEP randomizes RSA. Keep IND-CPA in mind as the test each one must pass.
Concept
These models aren't academic. In HTTPS, an on-path attacker can observe ciphertext and inject traffic — effectively a chosen setting, where the attacker influences what gets encrypted and decrypted.
So we design for the strongest realistic attacker, not the politest one. That's the same defense-in-depth instinct from Lesson 2: assume more attacker power than you hope to face.
Ranking
Put in order
These are the steps of The rules of the crypto game, scrambled. Put them back in order before the next slide shows you.
Why: This is the order the recipe itself gives. Recalling the sequence without the slide in front of you is the difference between recognising the method and being able to run it — most of what goes wrong in practice is a step done out of turn.
Pattern
Edge cases
Discussion prompt
The rules of the crypto game 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
In the IND-CPA game, why does a deterministic cipher necessarily fail?
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: §6.1: with chosen-plaintext power, Eve precomputes Enc(M_0). Because the cipher is deterministic, the challenge ciphertext for M_b equals that precomputed value exactly when b = 0. Comparing them distinguishes the two messages with certainty, giving advantage 1/2 above guessing — so the scheme is not IND-CPA.
Check
A team proposes a deterministic cipher: encrypting the same message always yields the same ciphertext. They claim it can still be IND-CPA because the math is strong.
Check your understanding
In the IND-CPA game, why does a deterministic cipher necessarily fail?
Answer: A
Why: §6.1: with chosen-plaintext power, Eve precomputes Enc(M_0). Because the cipher is deterministic, the challenge ciphertext for M_b equals that precomputed value exactly when b = 0. Comparing them distinguishes the two messages with certainty, giving advantage 1/2 above guessing — so the scheme is not IND-CPA.
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — The Key Is the Only Secret · What Can Eve Do? · What Does Secure Mean? · Why Randomness Is Mandatory. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now state Kerckhoff's Principle, rank the attacker models, distinguish chosen-plaintext from chosen-ciphertext, play the IND-CPA distinguishing game, and explain why a deterministic cipher can never pass it.
| Idea | § | The one-line version |
|---|---|---|
| Kerckhoff's Principle | 5.8 | Assume Eve knows everything but the key |
| Shannon's Maxim link | 5.8 | No security through obscurity |
| COA / KPA | 5.9 | See a ciphertext; maybe its plaintext too |
| Replay | 5.9 | Resend captured bits — no decryption needed |
| Chosen-plaintext (CPA) | 5.9 | Trick ALICE into encrypting (this class's bar) |
| Chosen-ciphertext (CCA/CCA2) | 5.9 | Trick BOB into decrypting; CCA2 = both |
| The IND-CPA game | 6.1 | Guess b for Enc(M_b); secure ⇒ Pr = 1/2 |
| Determinism loses | 6.1 | Repeats leak ⇒ encryption must be randomized |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.