CS 161, Lesson 30, in 56 slides. It presents digital signatures as public-key MACs with the roles reversed, in section 12.1, then the hash-then-sign RSA idea in section 12.2, the number theory that builds the trapdoor in section 12.3, the RSA signature scheme in section 12.4, and EUF-CMA security and its dependence on the hash in section 12.5. It is anchored to textbook sections 12.1 to 12.5.
Subject: Computer Security · 84 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 30 of 45
digital signatures as public-key MACs · hash-then-sign RSA · the cube-root trapdoor · and the EUF-CMA forgery game
Objectives
Warm-up
Discussion prompt
Before we open L30 · Digital Signatures: RSA Signatures, Number Theory & EUF-CMA: without looking back, what was the main idea of L29 · Public-Key Distribution, Hybrid Encryption & Session Keys, 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 29, in 51 slides. It covers the public-key distribution problem and the Attila key-substitution attack, in section 11.5, then why public-key cryptography is too slow to encrypt data directly and how hybrid encryption with session keys and its four-key setup solves that, in section 11.6. Supplemental material covers KEM and DEM, post-quantum cryptography, and Shor's and Grover's algorithms. It is anchored to textbook sections 11.5 to 11.6.
Concept
Diffie-Hellman (L27) needed a way to authenticate the values on the wire so Mallory can't substitute her own. Signatures are that tool — and much more: they're the asymmetric integrity primitive.
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 is a signature?, How is one built?, When is it 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 · §12.1 reversed roles
Concept
With public-key encryption (L28), the roles are: anyone can encrypt a message to Bob using his public key, but only Bob can decrypt it with his private key. Public = lock, private = unlock.
Signatures take this exact machinery and reverse the roles. That single swap turns a confidentiality tool into an integrity/authenticity tool.
Counterexample
Discussion prompt
Signatures take this exact machinery and reverse the roles. That single swap turns a confidentiality tool into an integrity/authenticity tool.
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.
Concept
Only Bob can sign a message, using his private signing key. But everyone can verify Bob's signature, using his public verification key.
Digital signature — A public-key primitive in which the holder of a private key produces a signature on a message, and anyone with the matching public key can verify that the message came from that holder and was not altered. It is the asymmetric analogue of a MAC.
Why this way round? If just anyone could sign with a public value, an attacker could forge Bob's signature on any message. Signing MUST require the private key.
Analogy
Discussion prompt
Explain §12.1 A signature reverses who holds which key 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:
Only Bob can sign a message, using his private signing key. But everyone can verify Bob's signature, using his public verification key.
Intuition
A MAC (L23) uses ONE shared key: whoever can verify can also produce tags, because verifying and tagging use the same secret. Symmetric — both parties are equal.
A signature splits that one key into two. Producing (signing) needs the private key; checking (verifying) needs only the public key. The two abilities are no longer the same — and that asymmetry is the whole point.
Ask yourself: with a MAC, could Bob deny he made a tag? (No proof either way — Alice shares the key and could have made it too. With a signature, only Bob's private key could have — see non-repudiation, Part 5.)
Explain it
Discussion prompt
Explain §12.1 Signature vs MAC: the symmetry breaks 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:
A MAC (L23) uses ONE shared key: whoever can verify can also produce tags, because verifying and tagging use the same secret. Symmetric — both parties are equal.
Concept
Every signature scheme is three algorithms. KeyGen makes the keypair; Sign uses the private key; Verify uses the public key.
\[ \mathrm{KeyGen}() \rightarrow (\mathit{PK},\ \mathit{SK}) \]
\[ \mathrm{Sign}(\mathit{SK},\ M) \rightarrow S \]
\[ \mathrm{Verify}(\mathit{PK},\ M,\ S) \rightarrow \{\,\mathrm{true},\ \mathrm{false}\,\} \]
Socratic
Discussion prompt
Every signature scheme is three algorithms. KeyGen makes the keypair; Sign uses the private key; Verify uses the public key.
Suppose that were not true. What is the first thing in L30 · Digital Signatures: RSA Signatures, Number Theory & EUF-CMA that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Concept
A scheme is correct if an honestly produced signature always verifies. Run Sign with the private key, then Verify with the public key, and you must get true:
\[ \mathrm{Verify}\big(\mathit{PK},\ M,\ \mathrm{Sign}(\mathit{SK},\ M)\big) = \mathrm{true} \]
Correctness is the easy half. The hard half is security: nobody WITHOUT the private key should be able to make a new (M, S) that verifies (Part 5).
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'The public key is public, so anyone can use it to sign a message as Bob.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The public key only VERIFIES. If it could also sign, anyone could forge Bob's signature on any document.
A student: which key does each operation need?
Why: The public key only VERIFIES. If it could also sign, anyone could forge Bob's signature on any document. Signing requires the PRIVATE key, which only Bob holds.
Trap
A student: 'The public key is public, so anyone can use it to sign a message as Bob.'
Use the public verification key to produce a signature
Why: Wrong. The public key only VERIFIES. If it could also sign, anyone could forge Bob's signature on any document. Signing requires the PRIVATE key, which only Bob holds.
A student: which key does each operation need?
Sign with the PRIVATE key; verify with the PUBLIC key
Why: §12.1: Sign(SK, M) needs the private signing key — only Bob has it. Verify(PK, M, S) needs only the public key — everyone can check. That split is what makes forgery hard.
Trap
A student: 'Signing is like encryption with the private key, so the signature keeps M secret.'
Treat the signature as providing confidentiality
Why: Wrong. A signature provides INTEGRITY and AUTHENTICITY, not confidentiality. The message M typically travels alongside S in the clear; the signature proves who sent it and that it wasn't altered — it does not hide it.
A student: what security property does a signature actually give?
Recognize signatures give integrity + authenticity, not secrecy
Why: §12.1: a signature lets a verifier detect tampering and confirm the signer. To ALSO hide M you must separately encrypt it. Confidentiality and authenticity are different goals.
Section
Part 2 · §12.2 the high-level picture
Concept
RSA signatures combine two one-way pieces. The first has a trapdoor; the second does not.
Trapdoor one-way function F — A function with a public part U and a private part K. Computing F_U(x) forward is easy for anyone. Inverting F (computing F⁻¹) is infeasible WITHOUT the trapdoor K, but easy WITH it.
One-way hash H — A public hash with NO trapdoor: easy to compute H(M), infeasible to invert or to find collisions. Nobody can run it backward — not even the signer.
Definition probe
Sort into buckets
Every line below is part of the definition of Trapdoor one-way function F or of One-way hash H — one or the other, never both. Put each where it belongs.
Concept
A signature S on a message M is, by definition, a value that satisfies one public equation linking the hash of M and the forward (public) direction of F:
\[ H(M) = F_U(S) \]
Verify is just checking this equation: hash M, run F forward on S, and confirm they're equal. Anyone can do it — F_U and H are both public.
Concept
To sign, Bob needs an S with F_U(S) = H(M). He computes H(M) first, then runs F backward — which only the private trapdoor K can do:
\[ S = F^{-1}\big(H(M)\big) \]
This is hash-then-sign: hash the message, then invert F on the hash. Only the trapdoor-holder can produce the matching S.
Intuition
Suppose Mallory wants a valid (M, S). Route 1: start from M, compute H(M), and try to invert F to get S = F⁻¹(H(M)). She can't — F has no trapdoor for her.
Route 2: pick S first, compute y = F_U(S) (easy, it's public), then find an M with H(M) = y. She can't — that means inverting the one-way hash H, finding a preimage. Both routes are blocked.
Ask yourself: which ingredient blocks each route? (Route 1 is blocked by F's missing trapdoor; Route 2 is blocked by H being one-way. You need BOTH.)
Concept
Without H, you'd sign M directly: S = F⁻¹(M). But F has algebraic structure — e.g. F(x)=x³ is multiplicative — so an attacker can combine known signatures to forge new ones algebraically.
Hashing first destroys that structure: H(M) is an unpredictable, structureless value, so no algebraic relation between messages survives. Hash-then-sign is what makes the scheme safe to use.
Ranking
Put in order
Put the moves of §12.2 Trace verify, then trace sign 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 H and F_U are public, so any verifier can do this with only the public key — no secret needed.
Worked example
Verify (M, S): compute H(M) and F_U(S), check they're equal
Why: Both H and F_U are public, so any verifier can do this with only the public key — no secret needed.
\[ \mathrm{Verify}: \ H(M) \stackrel{?}{=} F_U(S) \]
Sign M: hash first, then invert F with the private trapdoor
Why: Bob computes H(M), then S = F⁻¹(H(M)). Only his private key K lets him run F backward.
\[ \mathrm{Sign}: \ S = F^{-1}\big(H(M)\big) \]
Verify the signature he just made: F_U(S) = F_U(F⁻¹(H(M))) = H(M)
Why: §12.2: running F forward on S undoes the inversion, recovering H(M). The verification equation holds, so correctness is satisfied — and only the trapdoor-holder could have produced S.
Notation
Annotate
From §12.2 Trace verify, then trace sign — read this one piece at a time. What is each part doing?
On: \( \mathrm{Verify}: \ H(M) \stackrel{?}{=} F_U(S) \)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Why bother hashing? Just set S = F⁻¹(M) — sign the message directly.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: F(x)=x³ is multiplicative, so signatures on M₁ and M₂ combine into a valid signature on M₁·M₂ — an existential forgery.
A student: what does hashing first buy you?
Why: F(x)=x³ is multiplicative, so signatures on M₁ and M₂ combine into a valid signature on M₁·M₂ — an existential forgery. Signing raw messages is insecure.
Trap
A student: 'Why bother hashing? Just set S = F⁻¹(M) — sign the message directly.'
\[ S = F^{-1}(M) \quad\text{with}\quad F(x) = x^3 \]
Sign the raw message, skipping the hash
Why: Wrong. F(x)=x³ is multiplicative, so signatures on M₁ and M₂ combine into a valid signature on M₁·M₂ — an existential forgery. Signing raw messages is insecure.
A student: what does hashing first buy you?
Hash first: S = F⁻¹(H(M)), then verify F(S) = H(M)
Why: §12.2: H destroys the algebraic structure attackers exploit. Because H(M₁·M₂) is unrelated to H(M₁)·H(M₂), the multiplicative forgery collapses. Always hash-then-sign.
Section
Part 3 · §12.3 cube roots mod n
Concept
To build F we need a little modular arithmetic. The key quantity is Euler's totient.
Euler's totient φ(n) — The count of integers in {1, …, n} that are coprime to n (share no factor with n). It measures the size of the multiplicative group mod n, and it controls how exponents behave modulo n.
Concept
Fact 1 (Euler's theorem): if x is coprime to n, raising it to φ(n) gives back 1.
\[ \gcd(x, n) = 1 \ \Rightarrow\ x^{\varphi(n)} \equiv 1 \pmod{n} \]
Fact 2: for distinct odd primes p, q, the totient of their product factors nicely.
\[ \varphi(pq) = (p-1)(q-1) \]
Concept
Fact 3: if p ≡ 2 (mod 3) and q ≡ 2 (mod 3), there is an exponent d that 'undoes' cubing, computable efficiently from φ(pq).
\[ 3d \equiv 1 \pmod{\varphi(pq)} \]
Why p, q ≡ 2 (mod 3)? It guarantees 3 is coprime to φ(pq) = (p−1)(q−1), so 3 has an inverse d mod φ(pq) — and cube roots are unique. If 3 divided φ(pq), no such d would exist.
Sorting
Sort into buckets
These are the pieces of L30 · Digital Signatures: RSA Signatures, Number Theory & EUF-CMA, out of order. Put each one back under the part of the lesson it belongs to.
Concept
Put the facts together. With n = pq, define a public forward map F (cubing) and a private inverse map G (the d-th power). G undoes F.
\[ F(x) = x^3 \bmod n, \qquad G(x) = x^d \bmod n \]
\[ G\big(F(x)\big) = x \quad\text{for all } x \text{ with } \gcd(x, n) = 1 \]
Socratic
Discussion prompt
Put the facts together. With n = pq, define a public forward map F (cubing) and a private inverse map G (the d-th power). G undoes F.
Suppose that were not true. What is the first thing in L30 · Digital Signatures: RSA Signatures, Number Theory & EUF-CMA that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Intuition
Cubing mod n is easy for anyone: x ↦ x³ is one multiplication chain. Taking a cube root mod n — finding x from x³ — is believed hard unless you know d.
And you can only get d if you know φ(n) = (p−1)(q−1), which means knowing the factorization p, q. So factoring n IS the trapdoor: easy to publish n = pq, hard to recover p and q.
Ask yourself: what does a forger lack that Bob has? (The factorization of n, hence φ(n), hence d. Without d there's no efficient cube root.)
Step zero
Discussion prompt
§12.3 Prove G(F(x)) = x — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Start from Fact 3: 3d ≡ 1 (mod φ(n)), so 3d = 1 + kφ(n) for some…
Answer:
Worked example
Start from Fact 3: 3d ≡ 1 (mod φ(n)), so 3d = 1 + kφ(n) for some integer k
Why: The congruence just says 3d minus 1 is a multiple of φ(n); write that multiple as kφ(n).
\[ 3d = 1 + k\,\varphi(n) \]
Compute G(F(x)) = (x³)^d = x^{3d} = x^{1 + kφ(n)}
Why: Applying G to F(x) multiplies the exponents (3 then d), and we substitute 3d = 1 + kφ(n).
\[ x^{3d} = x^{1 + k\varphi(n)} = x \cdot \big(x^{\varphi(n)}\big)^{k} \pmod{n} \]
Apply Euler's theorem (Fact 1): since gcd(x,n)=1, x^{φ(n)} ≡ 1
Why: Each factor x^{φ(n)} collapses to 1, so the whole (x^{φ(n)})^k term becomes 1^k = 1.
\[ x \cdot \big(x^{\varphi(n)}\big)^{k} \equiv x \cdot 1^{k} = x \pmod{n} \]
Verify: G(F(x)) ≡ x (mod n) for every x coprime to n
Why: §12.3: the d-th power exactly inverts cubing. d is the trapdoor — derivable only from φ(n) = (p−1)(q−1), i.e. from the factorization Bob alone knows.
Translation
\( x^{3d} = x^{1 + k\varphi(n)} = x \cdot \big(x^{\varphi(n)}\big)^{k} \pmod{n} \)
Draw it
Translate both ways. First write the expression above as a sentence with no symbols in it at all. Then cover it, and write your sentence back as notation. If the two versions disagree, the disagreement is the thing to fix.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Cubing mod n is easy, so taking a cube root mod n must be easy too — just invert it.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Cubing is easy for everyone, but the cube root needs the exponent d, and d comes only from φ(n) = (p−1)(q−1) — i.e.
A student: who can take cube roots mod n, and why?
Why: Cubing is easy for everyone, but the cube root needs the exponent d, and d comes only from φ(n) = (p−1)(q−1) — i.e. from FACTORING n. Without the factorization, no efficient cube root is known.
Trap
A student: 'Cubing mod n is easy, so taking a cube root mod n must be easy too — just invert it.'
Assume the cube root is as easy as the cube
Why: Wrong. Cubing is easy for everyone, but the cube root needs the exponent d, and d comes only from φ(n) = (p−1)(q−1) — i.e. from FACTORING n. Without the factorization, no efficient cube root is known.
A student: who can take cube roots mod n, and why?
Only the holder of d (the factorization) can take cube roots
Why: §12.3: easy forward (cube), hard backward (root) — UNLESS you know d. That asymmetry, anchored on the hardness of factoring n, is exactly the trapdoor.
Section
Part 4 · §12.4 KeyGen, Sign, Verify
Concept
Now instantiate the abstract F from Part 2 with the cube map from Part 3. The public part is the modulus n; the private trapdoor is the cube-root exponent d.
\[ F(x) = x^3 \bmod n \ \text{(public, anyone)}, \quad G(y) = y^d \bmod n \ \text{(needs private } d) \]
G is the cube root: it inverts F. Signing will use G; verifying will use F.
Concept
Pick two large random primes, both ≡ 2 (mod 3) so Fact 3 applies. Multiply for the public modulus; derive the private exponent.
\[ p, q:\ \text{random } 1024\text{-bit primes, } p \equiv q \equiv 2 \pmod 3 \]
\[ \mathit{PK} = n = pq, \qquad \mathit{SK} = d \ \text{with}\ 3d \equiv 1 \pmod{\varphi(n)} \]
d is found from φ(n) = (p−1)(q−1) by the extended Euclidean algorithm (Fact 3) — efficient once you know p, q.
Concept
Sign hashes the message and takes the cube root (using d). Verify cubes the signature and checks it equals the hash.
\[ \mathrm{Sign}_d(M) = H(M)^d \bmod n \]
\[ \mathrm{Verify}_n(M, S):\ \ \text{true} \iff H(M) = S^3 \bmod n \]
Intuition
This is exactly Part 2 with the cube map plugged in. Signing is S = F⁻¹(H(M)) = H(M)^d — the private cube root. Verifying is the public equation H(M) = F(S) = S³.
So the verifier never touches d. They only cube (public). Correctness is the §12.3 theorem: cubing undoes the d-th-power root.
Ask yourself: where does the secret enter? (Only in Sign, via the exponent d. Verify uses n alone.)
Concept
Real RSA signatures need careful padding and parameter choices (the textbook omits these technical details). The high-level structure here is correct, but the secure details are subtle.
Don't roll your own — Never implement RSA signatures yourself for production. Use a vetted library (e.g. a standardized RSA-PSS implementation). Hand-rolled crypto routinely leaks keys through padding and side-channel mistakes.
Ranking
Put in order
Put the moves of §12.4 Sign then verify, symbolically 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. Only Bob can do this — it needs the private cube-root exponent d.
Worked example
Bob signs M: he computes the hash, then S = H(M)^d mod n
Why: Only Bob can do this — it needs the private cube-root exponent d.
\[ S = H(M)^d \bmod n \]
A verifier cubes S and compares to H(M): compute S³ mod n
Why: Cubing is public; substitute S = H(M)^d and the exponents multiply to 3d.
| step | expression | equals |
|---|---|---|
| signature | S = H(M)^d | the cube root of H(M) |
| verify cubes it | S^3 = (H(M)^d)^3 = H(M)^{3d} | H(M)^{1 + kφ(n)} |
| Euler collapses | H(M) · (H(M)^{φ(n)})^k | H(M) · 1 = H(M) |
\[ S^3 = \big(H(M)^d\big)^3 = H(M)^{3d} \equiv H(M) \pmod{n} \]
Verify: S³ ≡ H(M) (mod n), so Verify returns true
Why: §12.4: the cube of the signature recovers the hash exactly (the §12.3 theorem with x = H(M)). An honest signature always passes — correctness holds.
Comparison
Comparison matrix
From §12.4 Sign then verify, symbolically: refill the expression column from what you know. The rest of the table is as it appeared.
| step | expression | equals |
|---|---|---|
| signature | S = H(M)^d | the cube root of H(M) |
| verify cubes it | S^3 = (H(M)^d)^3 = H(M)^{3d} | H(M)^{1 + kφ(n)} |
| Euler collapses | H(M) · (H(M)^{φ(n)})^k | H(M) · 1 = H(M) |
Explain it to yourself
Discussion prompt
In Trap: 'the verifier needs the private key' this move is made:
Use d during verification
Why is that legal? Name the rule or definition it rests on before you read on.
Hint: If you can only say "because that is what you do", the rule is the thing to go and find.
Answer:
Wrong. Verify does NOT invert anything — it CUBES: it checks H(M) = S³ mod n using only the public modulus n. If verifying needed d, only Bob could verify, defeating the entire purpose.
Trap
A student: 'To verify Bob's signature you must use Bob's private key d to take the cube root.'
Use d during verification
Why: Wrong. Verify does NOT invert anything — it CUBES: it checks H(M) = S³ mod n using only the public modulus n. If verifying needed d, only Bob could verify, defeating the entire purpose.
A student: which key does Verify use?
Verify uses only the public key n: check S³ ≡ H(M)
Why: §12.4: anyone can cube S mod n and compare to H(M). Verification is fully public; only signing (the cube root via d) requires the private key.
Section
Part 5 · §12.5 forgery game and caveats
Concept
We define security with a game, parallel to the L23 MAC game — but now the verification key is public. Reginald (challenger) runs KeyGen and hands Georgia (adversary) the PUBLIC key U.
\[ \text{Reginald: } (U, K) \leftarrow \mathrm{KeyGen}(); \ \text{Georgia gets } U \]
Giving Georgia the public key models reality: verification keys are public, so the attacker always has U.
Concept
Georgia makes adaptive signing queries: she picks messages M_i and gets back their signatures. Then she shouts 'Bingo!' with a forgery (M, S).
\[ \text{queries: } M_i \rightarrow S_i = \mathrm{Sign}_K(M_i) \]
\[ \text{output: } (M, S) \ \text{with}\ M \notin \{M_1, M_2, \ldots\} \]
Socratic
Discussion prompt
Georgia makes adaptive signing queries: she picks messages M_i and gets back their signatures. Then she shouts 'Bingo!' with a forgery (M, S).
Suppose that were not true. What is the first thing in L30 · Digital Signatures: RSA Signatures, Number Theory & EUF-CMA that would stop working?
Hint: Follow it one step downstream. The answer is whatever was quietly relying on it.
Concept
Georgia wins (forges) if her output verifies under U on a message she NEVER queried.
\[ \text{Georgia wins} \iff \mathrm{Verify}_U(M, S) = \text{true} \ \wedge\ M \notin \{M_i\} \]
EUF-CMA security — Existential Unforgeability under Chosen-Message Attack: no efficient adversary, even after obtaining signatures on many chosen messages, can produce a valid signature on any new message with non-negligible probability.
Explain it
Discussion prompt
Explain §12.5 Winning the game = EUF-CMA security 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:
Georgia wins (forges) if her output verifies under U on a message she NEVER queried.
Intuition
Compare L23: the MAC game also let the adversary request tags and asked for a forgery on a new message. The ONLY change here is that the adversary holds the public verification key — verifying is no longer secret.
That makes the signature's job harder: the attacker can check candidate forgeries herself, for free. EUF-CMA demands she still can't make one.
Ask yourself: why is 'M never queried' essential to the win condition? (Otherwise she'd 'forge' by replaying a signature she was handed — trivial and not a real break.)
Analogy
Discussion prompt
Explain §12.5 Same game as the MAC, public key 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: why is 'M never queried' essential to the win condition? (Otherwise she'd 'forge' by replaying a signature she was handed — trivial and not a real break.)
Concept
Critical caveat: a signature is only as strong as its hash H. Real signatures have been broken not by attacking RSA, but by finding hash collisions.
If H is weak and Mallory finds M ≠ M′ with H(M) = H(M′), then a signature on M is automatically valid on M′ — because Verify only sees H(M) = S³. One signature, two messages.
Counterexample
Discussion prompt
Critical caveat: a signature is only as strong as its hash H. Real signatures have been broken not by attacking RSA, but by finding hash collisions.
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 H is weak and Mallory finds M ≠ M′ with H(M) = H(M′), then a signature on M is automatically valid on M′ — because Verify only sees H(M) = S³. One signature, two messages.
Ranking
Put in order
Put the moves of §12.5 A collision forgery 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. A collision is two distinct messages with the same hash — the property a strong hash is supposed to make infeasible (callback to L22).
Worked example
Suppose H is broken: Mallory finds a colliding pair M (benign) and M′ (malicious) with H(M) = H(M′)
Why: A collision is two distinct messages with the same hash — the property a strong hash is supposed to make infeasible (callback to L22).
\[ M \ne M', \qquad H(M) = H(M') \]
Mallory gets Bob to legitimately sign the benign M: S = H(M)^d
Why: Bob signs what looks like an innocuous document; S is a valid signature on M.
The SAME S verifies on the malicious M′, because S³ = H(M) = H(M′)
Why: Verify checks S³ ≟ H(M′); since H(M′) = H(M) = S³, it returns true — a valid signature on a message Bob never agreed to.
\[ S^3 \equiv H(M) = H(M') \pmod n \ \Rightarrow\ \mathrm{Verify}_n(M', S) = \text{true} \]
Verify: the forgery succeeds with no attack on RSA at all — only on H
Why: §12.5: the break is entirely in the hash. This is why SHA-1 (L22), once collisions were found, was retired from signatures — the signature inherits the hash's collision-resistance.
Notation
Annotate
From §12.5 A collision forgery — read this one piece at a time. What is each part doing?
On: \( S^3 \equiv H(M) = H(M') \pmod n \ \Rightarrow\ \mathrm{Verify}_n(M', S) = \text{true} \)
Concept
⊕ Supplemental — beyond §12.1–12.5. RSA isn't the only signature. Two discrete-log-based families matter in practice (callback to the DH hardness of L27).
Concept
One property a signature has that a MAC cannot: non-repudiation. Because anyone can verify with the PUBLIC key, only the private-key holder could have signed — the signer can't later deny it.
Non-repudiation — A signature binds a message to a specific signer in a way a third party can check. A shared-key MAC gives NO non-repudiation: either party holding the key could have made the tag, so neither can prove the other did (callback to L17 deniability).
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'RSA is strong, so my signature is safe regardless of which hash I use.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: Verify only sees H(M) = S³. If H has a collision H(M)=H(M′), one valid signature works for BOTH messages — a forgery that never touches RSA.
A student: what does signature security depend on besides the trapdoor?
Why: Verify only sees H(M) = S³. If H has a collision H(M)=H(M′), one valid signature works for BOTH messages — a forgery that never touches RSA. The signature is only as strong as its hash.
Trap
A student: 'RSA is strong, so my signature is safe regardless of which hash I use.'
Assume RSA strength alone guarantees signature security
Why: Wrong. Verify only sees H(M) = S³. If H has a collision H(M)=H(M′), one valid signature works for BOTH messages — a forgery that never touches RSA. The signature is only as strong as its hash.
A student: what does signature security depend on besides the trapdoor?
Require a collision-resistant hash (and retire broken ones like SHA-1)
Why: §12.5: signatures inherit the hash's collision-resistance. Finding a collision forges a signature, so a broken hash breaks the signature — use a strong H (callback L22).
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'The nonce k in ECDSA is just randomness — reusing the same k twice is harmless.' ⊕
It is wrong. Say what breaks — and say it before you turn the page.
Correct: ⊕ Two ECDSA signatures with the same k let an attacker solve linear equations for the private key.
A student: how should the nonce be handled?
Why: ⊕ Two ECDSA signatures with the same k let an attacker solve linear equations for the private key. This is exactly how the 2010 Sony PS3 signing key was recovered.
Trap
A student: 'The nonce k in ECDSA is just randomness — reusing the same k twice is harmless.' ⊕
Reuse the same per-signature nonce k on two messages
Why: Wrong. ⊕ Two ECDSA signatures with the same k let an attacker solve linear equations for the private key. This is exactly how the 2010 Sony PS3 signing key was recovered.
A student: how should the nonce be handled?
Use a FRESH unpredictable k each time — or a deterministic scheme like Ed25519
Why: ⊕ ECDSA needs a unique, secret k per signature. EdDSA/Ed25519 derives k deterministically from the message + key, removing the reuse footgun entirely.
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 digital-signature playbook with this step confiscated:
RSA instance: n = pq with p ≡ q ≡ 2 (mod 3); Sign_d(M) = H(M)^d mod n; Verify_n checks H(M) = S³ mod n. Cube is public; cube root (d) is the trapdoor from φ(n).
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 digital-signature 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
Which statement about Bob's RSA signature scheme is TRUE?
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: C
Why: §12.1–12.5: signing computes S = H(M)^d, which needs the private cube-root exponent d — only Bob has it. Verifying checks H(M) = S³ mod n using only the public modulus n, so anyone can verify. And the signature inherits the hash's collision-resistance: if H(M) = H(M′), then S³ = H(M) = H(M′), so Bob's signature on M is automatically valid on M′ — a forgery that never attacks RSA itself. Hence a strong, collision-resistant H is essential.
Check
Bob publishes his RSA verification key n; he keeps the cube-root exponent d private. He uses hash-then-sign: Sign(M) = H(M)^d mod n. Think it through before choosing.
Check your understanding
Which statement about Bob's RSA signature scheme is TRUE?
Answer: C
Why: §12.1–12.5: signing computes S = H(M)^d, which needs the private cube-root exponent d — only Bob has it. Verifying checks H(M) = S³ mod n using only the public modulus n, so anyone can verify. And the signature inherits the hash's collision-resistance: if H(M) = H(M′), then S³ = H(M) = H(M′), so Bob's signature on M is automatically valid on M′ — a forgery that never attacks RSA itself. Hence a strong, collision-resistant H is essential.
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — Signatures = Public-Key MACs · The Hash-Then-Sign RSA Idea · Number Theory — Building the Trapdoor · The RSA Signature Scheme · EUF-CMA Security & the Hash. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now explain a signature as a public-key MAC with reversed roles, describe hash-then-sign and why the hash matters, prove the cube-root trapdoor inverts F(x)=x³, run RSA KeyGen/Sign/Verify, and play the EUF-CMA forgery game — including the collision attack that ties a signature's security to its hash.
| Idea | § | The one-line version |
|---|---|---|
| Signature = public-key MAC | 12.1 | Only the private key signs; the public key verifies |
| Three algorithms | 12.1 | KeyGen→(PK,SK); Sign(SK,M)→S; Verify(PK,M,S)→bool |
| Hash-then-sign | 12.2 | S = F⁻¹(H(M)); Verify checks H(M) = F_U(S) |
| Cube-root trapdoor | 12.3 | G(F(x))=x^{3d}=x; d from φ(n)=(p−1)(q−1) |
| RSA scheme | 12.4 | Sign_d(M)=H(M)^d mod n; Verify: H(M)=S³ mod n |
| EUF-CMA | 12.5 | No forge on a new message after chosen-message queries |
| Hash caveat | 12.5 | A collision H(M)=H(M′) forges; ⊕ non-repudiation vs MAC |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.