Chapter 13 of Trappe & Washington: RSA signatures and the existential forgery they permit; blind signatures built on RSA's multiplicativity; the ElGamal signature scheme with its verification proof; why hashing before signing is a security requirement rather than an optimisation; the birthday attack that forces a digest twice the security level; and the Digital Signature Algorithm, whose prime-order subgroup shrinks signatures eightfold — together with the demonstration that reusing the random nonce hands over the private key outright.
Subject: Cryptography · 60 slides · diagram-first lesson
Open the interactive version of this deck
Title
Cryptography · Chapter 13
The one objective symmetric cryptography cannot provide, and the four schemes that provide it
Objectives
Chapter 1 listed four security objectives and said non-repudiation was impossible with a shared key. Section 9.6 built one by accident, calling it treaty verification. This chapter does it properly.
Figure (svg): Signing with the private key and verifying with the public key — the reverse of encryption's direction.
Warm-up
A handwritten signature ties an identity to a document. An electronic message is trivially copyable.
Discussion prompt
List the properties a digital signature must have, and say which of them a MAC already provides.
Hint: Chapter 12 compared the two directly.
Answer:
Unforgeable: only the holder of the private key can produce it. A MAC gives this to the two key-holders.
Verifiable by anyone: with only public information. A MAC does not — verification requires the shared key.
Bound to the document: the signature must not transfer to a different message. Both provide this.
Non-repudiable: the signer cannot later deny it, and a third party can adjudicate. This is the property only a signature has, because with a MAC the verifier could have produced the tag himself.
So the whole chapter is about the second and fourth properties, and both come from the same source: the signer holds something nobody else does, and everyone else holds enough to check.
Figure (svg): Signing with the private key and verifying with the public key — the reverse of encryption's direction.
Section
Section 13.1 · pp. 270-271
Concept
Alice generates primes p and q, forms n = pq, chooses e_A coprime to φ(n) and computes d_A. She publishes (e_A, n) and keeps d_A, p and q private — the same setup as Chapter 9.
\[ \text{sign: } s \equiv m^{d_A} \pmod n \qquad \text{verify: } z \equiv s^{e_A} \pmod n, \text{ accept if } z = m \]
The pair (m, s) is made public. Anyone downloads (e_A, n), raises s to the public exponent, and checks the result equals m.
It works for exactly the reason encryption works: (m^d)^e = m^(de) ≡ m by Euler's theorem. RSA's two exponents are symmetric — apply the private one first and the public one undoes it, which is what turns an encryption scheme into a signature scheme with no new mathematics.
Figure (svg): The RSA signature: raise the message to the private exponent to sign, and to the public exponent to verify.
Worked example
Eve has (m, s) and wants Alice's signature on a different message m₁. Two routes, and both fail — but the second fails for an interesting reason.
Route one: reuse s directly. But s^{e_A} ≡ m, not m₁, so verification fails
Why: The signature is bound to the message by the verification equation.
Route two: find s₁ with s₁^{e_A} ≡ m₁
Why: This is taking an e-th root mod n — exactly the problem of decrypting an RSA ciphertext m₁, which is believed hard.
Route three, and this one succeeds: Eve chooses s₁ first and defines m₁ ≡ s₁^{e_A}
Why: Now (m₁, s₁) verifies perfectly, and Alice apparently cannot deny signing it.
Verify: but m₁ will be a random sequence of characters
Why: Eve controls the signature and not the message, so m₁ is whatever the exponentiation produces — not a document committing Alice to pay millions. Alice's claim of forgery is believable. This is an existential forgery: a valid pair Eve did not choose the meaning of, and the next section shows how hashing removes even this.
Figure (svg): The RSA signature: raise the message to the private exponent to sign, and to the public exponent to verify.
Concept
Bob has made an important discovery. He wants a public, dated record that he did it — for priority — without revealing the details. Alice must sign a document she does not see.
\[ \frac{t^{d}}{k} \equiv \frac{k^{ed} m^{d}}{k} \equiv \frac{k \, m^{d}}{k} \equiv m^{d} \pmod n \]
Alice has signed m without ever seeing it, and cannot recognise it later, because t was m multiplied by a random element. The construction works because RSA is multiplicative — and that same property is the reason raw RSA signing is unsafe, which the next section takes up.
Blind signatures are the foundation of the untraceable digital cash of Chapter 16: a bank signs a coin without learning which coin it signed.
Figure (svg): A blind signature: Bob multiplies his message by a random blinding factor, Alice signs, and Bob divides it out.
Socratic
Alice signs whatever number she is handed, without seeing what it means.
Discussion prompt
What could go wrong, and how do real systems restrain it?
Hint: Ask what else Bob could put in the blinded value.
Answer:
She could be signing anything. Bob hands her a blinded value; she signs it; and it might unblind to a cheque, a certificate, or an authorisation she would never have granted. She has no way to inspect it.
And blind signing composes with the multiplicative forgery. Bob can blind a value chosen so that the resulting signature is useful in combination with signatures Alice has given before — a chosen-message attack she cannot even detect.
The standard restraint is cut-and-choose. Bob prepares many blinded values; Alice picks all but one at random and requires Bob to unblind those, checking they are well-formed; she signs the remaining one. Cheating is then caught with probability 1 − 1/n.
The other restraint is structure. Require the unblinded value to have a specific format — a hash with a fixed prefix, say — so that a random or malicious value is overwhelmingly unlikely to be valid when unblinded.
Chapter 16's digital cash uses both, because there the bank is signing something worth money and the customer is exactly the adversary.
Section
Section 13.2 · pp. 271-273
Concept
Alice chooses a large prime p, a primitive root α, and a secret a with 1 ≤ a ≤ p−2, then computes β ≡ α^a. The triple (p, α, β) is public, and the security is that recovering a is a discrete logarithm problem.
The signed message is the triple (m, r, s). To verify, Bob computes v₁ ≡ β^r r^s and v₂ ≡ α^m, both mod p, and accepts exactly when they agree.
A feature that differs from RSA: many different signatures are valid for a given message, because each choice of k gives a different (r, s). The scheme is randomised, which is a strength — and it makes the requirement on k absolute.
Figure (svg): The ElGamal signature: a per-message random k gives r, and s solves a linear congruence involving the private key.
Worked example
Four lines, and the only subtlety is which modulus each congruence lives in.
From the definition, s ≡ k⁻¹(m − a r) (mod p−1)
Why: Note the modulus is p−1, because s will be used as an exponent.
Multiply by k: sk ≡ m − ar (mod p−1), so m ≡ sk + ar (mod p−1)
Why: Ordinary rearrangement.
A congruence mod p−1 in the exponent yields an overall congruence mod p
Why: Because α^(p−1) ≡ 1 by Fermat — this is the step that connects the two moduli, and it is Chapter 3's 'bases mod p, exponents mod p−1' rule doing real work.
\[ v_2 \equiv \alpha^{m} \equiv \alpha^{sk + ar} \equiv (\alpha^{a})^{r} (\alpha^{k})^{s} \equiv \beta^{r} r^{s} \equiv v_1 \pmod p \]
Verify: both sides reduce to the same thing whenever the signature was produced correctly
Why: And the verifier needs only public values: β, r, s, m, α and p. Note that a appears nowhere in the verification equation — it enters only through β and through the construction of s.
Figure (svg): The ElGamal signature: a per-message random k gives r, and s solves a linear congruence involving the private key.
Socratic
Eve wants a signature on a message m of her choosing. She knows the verification equation β^r r^s ≡ α^m.
Discussion prompt
Why can she not simply pick r and solve for s, or pick s and solve for r?
Hint: Look at where each unknown appears in the equation.
Answer:
Fix r and solve for s: she needs r^s ≡ α^m β^(−r), which is a discrete logarithm problem to the base r. Believed hard.
Fix s and solve for r: now r appears both as an exponent and as a base — β^r r^s. There is no known way to solve for it at all; this is not merely a discrete log, it is an equation nobody has a method for.
Choose both together? Then she needs a pair satisfying one equation with two unknowns, and there are solutions — but no known way to find one for a chosen m.
What she can do is an existential forgery: pick arbitrary exponents, construct a valid (r, s) pair, and see what message it happens to sign. As with RSA, the resulting m is not one she chose — and hashing before signing removes this route entirely, because she would then need a message hashing to that value.
The general shape is worth noticing: a verification equation is safe when every route to solving it for the attacker's chosen input is a hard problem. Checking each unknown in turn, as here, is the standard way to argue it.
Section
Section 13.3 · pp. 273-274
Concept
In practice nobody signs a message. They sign its hash. There are three reasons and the first is the least important.
\[ \text{sign } h(m) \text{, not } m \]
So hashing before signing is a security requirement, and describing it as an optimisation — which is common — gets the reason backwards.
Figure (svg): Hashing before signing: the signature covers a fixed-size digest rather than the message itself.
Anomaly
Alice signs m₁ and m₂ with raw RSA, producing s₁ ≡ m₁^d and s₂ ≡ m₂^d.
Predict first
What can Eve produce?
Correct: A valid signature on m₁m₂ mod n, by computing s₁s₂
Hashing fixes it because the forged signature is on h(m₁)·h(m₂), and Eve would need a message m₃ with h(m₃) equal to that product — a preimage problem for a value she cannot control.
In practice a padding scheme does more: PSS for signatures, as OAEP does for encryption, adds randomness and structure so that the signed value has a form a product would almost never take.
The general lesson, and it is a recurring one: algebraic structure in a primitive is simultaneously a feature and an attack surface. RSA's multiplicativity gives blind signatures and gives this forgery.
Why: s₁s₂ ≡ m₁^d m₂^d ≡ (m₁m₂)^d, which is exactly a valid signature on the product. Eve did one multiplication and never touched the private key. This is the multiplicative property of RSA, and it is the same property that makes blind signatures possible — a construction and an attack from one algebraic fact.
Section
Section 13.4 · pp. 274-275
Concept
Hashing before signing solves the multiplicative forgery, and introduces a dependence on the hash's collision resistance. Chapter 12 showed exactly what that costs.
Alice read and approved what she signed. The signature is valid on a document she never saw, because it covers the digest and the two share one.
So the digest length must be twice the security level. A 128-bit hash gives 64-bit collision resistance and is inadequate for signing — which is why MD5-signed certificates were forgeable, and why SHA-256 is the modern floor.
Figure (svg): The birthday attack on a signature: two sets of document variants, matched until a pair shares a digest.
Section
Section 13.5 · pp. 275-276
Concept
Proposed by NIST in 1991 and adopted as a standard in 1994. Like ElGamal it is a signature scheme with appendix, and like every scheme here it signs a message digest — assume a 256-bit hash has already been applied.
Setup: Alice finds a 256-bit prime q and a prime p with q | p−1, chosen so the discrete log problem is hard. The original standard used a 512-bit p; later versions require 2048 bits. She takes a primitive root g and sets α ≡ g^((p−1)/q), so that α^q ≡ 1. She picks a secret a and publishes (p, q, α, β) with β ≡ α^a.
Verification: compute u₁ ≡ s⁻¹m and u₂ ≡ s⁻¹r, both mod q, then v = (α^{u₁} β^{u₂} mod p) mod q, and accept exactly when v = r.
Figure (svg): DSA works in a prime-order subgroup, so the exponents live mod q while the arithmetic happens mod p.
Worked example
DSA's distinctive feature is α having order q rather than p−1, and every advantage follows from it.
Signature size: r and s are both reduced mod q, so each is 256 bits
Why: The signature is 512 bits. ElGamal's r and s live mod p and mod p−1, so at 2048-bit p a signature would be 4096 bits — eight times larger for the same security.
Exponent arithmetic is mod q, so k and a are 256-bit numbers
Why: Faster signing, and a smaller secret to protect.
Pohlig-Hellman is defeated by construction
Why: q is prime, so the subgroup's order has no small factors to decompose over. Section 10.2's requirement is satisfied structurally rather than by checking.
And Section 10.2's other observation applies: β is a power of α, so the discrete log is automatically 0 modulo (p−1)/q
Why: So an attacker learns nothing partial from the small-factor part — there is nothing hidden there. The book flags this as the reason DSA is built this way.
Verify: verification still works because α^q ≡ 1, so exponents may be reduced mod q throughout
Why: The two moduli — p for the arithmetic, q for the exponents — are the whole design, and it is Chapter 3's exponent rule exploited deliberately rather than merely respected.
Figure (svg): DSA works in a prime-order subgroup, so the exponents live mod q while the arithmetic happens mod p.
Worked example
The same style of argument as ElGamal's, with q in place of p−1.
By definition s ≡ k⁻¹(m + a r) (mod q), so ks ≡ m + ar
Why: Multiply through by k.
Rearrange: m ≡ −ar + ks (mod q), so s⁻¹m ≡ −ar s⁻¹ + k (mod q)
Why: Multiplying by s⁻¹, which exists because gcd(s, q) = 1.
So u₁ ≡ s⁻¹m ≡ k − a r s⁻¹ ≡ k − a u₂ (mod q)
Why: Using u₂ ≡ s⁻¹r.
Then α^{u₁} β^{u₂} ≡ α^{k − a u₂} (α^a)^{u₂} ≡ α^k (mod p)
Why: The a terms cancel exactly, which is the point of the construction.
Verify: so v = (α^k mod p) mod q = r
Why: The verification recovers r without ever knowing k or a. Note how the double reduction — mod p then mod q — appears identically in the signing and the verification, which is what makes the equality hold.
Figure (svg): DSA works in a prime-order subgroup, so the exponents live mod q while the arithmetic happens mod p.
Concept
Both ElGamal and DSA need a k that is fresh, secret and unpredictable. Chapter 10 showed that reusing k in ElGamal encryption leaks the ratio of two messages. Here the consequence is far worse.
Suppose Alice signs m₁ and m₂ with the same k. Both signatures share the same r, which is visible immediately. And:
\[ s_1 - s_2 \equiv k^{-1}(m_1 - m_2) \pmod q \;\Longrightarrow\; k \equiv (m_1 - m_2)(s_1 - s_2)^{-1} \]
Having k, the attacker recovers the private key from either signature: a ≡ r⁻¹(s₁k − m₁) mod q.
Two signatures with a repeated k give the private key outright. Not a message, not a forgery on one document — the key, and with it every future signature.
This is exactly how the PlayStation 3's ECDSA signing key was recovered in 2010: the implementation used a constant k. The curve, the hash and the scheme were all sound.
Figure (svg): Reusing k in an ElGamal or DSA signature lets an attacker solve two linear equations for the private key.
Counterexample
An implementation generates k from a weak source — a timestamp, or a counter with few bits of entropy.
Discussion prompt
Show that this is as damaging as reuse, and describe the standard fix.
Hint: The attacker does not need k to repeat; she needs to be able to guess it.
Answer:
One signature with a guessable k gives the private key. From s ≡ k⁻¹(m + ar) mod q, rearrange to a ≡ r⁻¹(sk − m). If the attacker can guess k she computes a directly, and she can test each guess against the public key.
A few bits of bias suffice, even without a full guess. Lattice attacks recover the private key from a few hundred signatures where only the top few bits of each k are biased — which a naive 'random mod q' implementation produces if it reduces a uniform 256-bit value modulo q.
So the requirement is stronger than 'do not repeat'. k must be uniform on 1…q−1, from a cryptographic source, and it must never be logged, cached or derived from anything an attacker sees.
The standard fix is deterministic nonce generation — RFC 6979 — where k is computed as HMAC of the message and the private key. It is reproducible, so it cannot be a weak random source; it is unpredictable, because it depends on the private key; and it never repeats for different messages.
And the general lesson: a requirement stated as 'choose a random value' is a requirement on a random number generator, which Chapter 5 showed is the component most often got wrong.
Figure (svg): Reusing k in an ElGamal or DSA signature lets an attacker solve two linear equations for the private key.
Comparison
Fill the blanks. The differences are practical rather than mathematical.
Comparison matrix
| RSA signature | DSA | |
|---|---|---|
| Rests on | factoring | discrete logs in a prime-order subgroup |
| Signature size at 128-bit security | 3072 bits | 512 bits |
| Randomised? | no — deterministic, so the same message always signs identically | yes — a fresh k per signature |
| Verification cost | very cheap with e = 65537 | two exponentiations |
| Consequence of a bad nonce | none — there is no nonce | the private key is recovered outright |
The last row is the trade: RSA has no nonce to get wrong, and DSA's signatures are six times smaller. Neither is uniformly better, and both are still deployed for exactly these reasons.
Notation
Every scheme in this chapter is a verification equation, and reading one tells you what the attacker must solve.
Annotate
On: \( \beta^{r} r^{s} \equiv \alpha^{m} \pmod p \)
When you meet a new signature scheme, write its verification equation and ask what happens when the attacker fixes each unknown. That is the whole analysis in outline.
Definition probe
Signature schemes consume several assumptions at once, and it pays to know which.
Sort into buckets
Sort each requirement by what fails if it is violated.
Two truths and a lie
Two of these claim more than a signature delivers.
Eliminate the wrong options
Which statement is correct?
Survives elimination: a
Why: A signature binds a document to a key, and nothing more. Everything people want from it — that a person agreed, that they understood, that they were not coerced or compromised — is an inference from key custody, not from the equation. Being precise about this is what separates a cryptographic guarantee from a legal one, and the gap is where most disputes about electronic signatures actually live.
Real world
Signatures are less visible than encryption and at least as load-bearing.
Discussion prompt
Name four places a signature is verified on your behalf, and what would happen without it.
Hint: The web, your operating system, your package manager, and your phone.
Answer:
TLS certificates. A certificate authority signs the binding between a domain and a public key, and your browser verifies the chain. Without it, Chapter 10's intruder-in-the-middle attack works against every HTTPS connection — Diffie-Hellman would give you a key with somebody unspecified.
Operating system updates. Every patch is signed by the vendor. Without it, anyone who controls a mirror or a network path ships you code with full privileges.
Package managers. apt, npm and their kin verify signatures over repository metadata, which in turn commits to package hashes. Without it, dependency confusion becomes trivial rather than merely common.
Secure boot. The firmware verifies a signature over the bootloader, which verifies the kernel. Without it, persistence below the operating system is straightforward.
And the common shape: in every case the verifier has no shared secret with the signer and no way to obtain one. That is precisely the gap a MAC cannot fill, and it is why signatures exist as a separate primitive.
Explain it to yourself
For RSA, signing looks exactly like decrypting: apply the private exponent. The description 'encrypt with your private key' is common.
Discussion prompt
Explain why that description is misleading, and where it breaks down entirely.
Hint: It happens to work for textbook RSA and for nothing else.
Answer:
For textbook RSA the operations coincide, because the two exponents are symmetric and either can be applied first. That coincidence is what makes the description sound right.
It fails immediately for real RSA. Encryption uses OAEP padding and signing uses PSS — different padding, different security proofs, different structure. A signature is not a ciphertext of anything.
And it fails completely for every other scheme. ElGamal and DSA signatures are a pair (r, s) produced by solving a congruence; there is no encryption operation in sight, and no sense in which the message is being decrypted. The same is true of ECDSA and of every lattice-based signature.
The two are different services with different definitions. Encryption's goal is indistinguishability; a signature's is existential unforgeability under chosen-message attack. Those are different games with different winning conditions.
The practical harm: the description encourages using one key pair for both, which is a real vulnerability — an attacker who can get arbitrary values 'signed' can use that as a decryption oracle. Standards mandate separate keys for signing and encryption for exactly this reason.
Error analysis
From the design of an internal document-signing API.
Annotate
Every one of the five is a documented attack, and the first is the one that makes the others easy.
Ranking
Five things that can go wrong with a deployed signature scheme.
Put in order
Why: A single forgery affects one document. A hash break lets an attacker forge documents she prepared in advance, which is worse but bounded by what she anticipated. A repeated nonce gives the private key — so it is equivalent to theft, arriving through a coding error rather than a breach. Key theft compromises everything signed with that key, past and future. And a compromised CA is worse still: it forges keys for other parties, so revoking one key does not contain it. The ordering is really by how far the blast radius extends beyond the immediate victim.
Commit first
A system uses RSA-3072 with PSS padding, SHA-256 hashing, keys in an HSM, and certificates from a public CA.
Predict first
What is the realistic failure?
Correct: The verifier does not check the whole chain, or accepts an expired or revoked certificate
The classic instance is accepting a certificate whose signature is valid but whose subject does not match the host being contacted — a check that lives entirely outside the signature verification and has been omitted in libraries repeatedly.
The recurring theme of the whole course, one more time: the primitive is the part that has been analysed for decades, and the surrounding logic is the part written under deadline.
Why: Every cryptographic component here is sound and unbroken. What fails in practice is verification logic: chains not walked to a trusted root, hostnames not matched against the certificate, revocation not checked because the check is slow and fails open, expiry ignored because it caused an outage once. These are the bugs that appear in CVE lists year after year, and none of them involves the mathematics.
Faded example
Four blanks, and they are the four things an implementation must get right.
Fill in the blanks
Sign the hash of the message, not the message. Use a fresh random k for every signature, from a cryptographic source. Keep the private key in hardware. And ensure the digest length is twice the security level wanted, because of the birthday bound.
Why: Four requirements, and three of them have destroyed real systems: unhashed signing enables multiplicative forgery, a reused nonce gave up the PlayStation 3's signing key, and a 128-bit digest gave forgeable MD5 certificates. Only the third — key storage — is an operational rather than a cryptographic requirement, and it is the one most often specified and least often audited.
Trade off
The decision comes up constantly, and it is settled by one question. Fill the blanks.
Comparison matrix
| MAC | Signature | |
|---|---|---|
| Key | shared | private, with a public counterpart |
| Who can verify | only the key-holders | anyone with the public key |
| Non-repudiation | impossible | yes |
| Cost per message | one or two hash computations | a public key operation — orders of magnitude more |
| Typical use | every record on an established channel | once per handshake, and for certificates |
The deciding question is whether a third party ever has to be convinced. If not, use a MAC and pay a thousandth of the cost.
Edge cases
A signature is a mathematical fact: the equation either holds or it does not, forever.
Discussion prompt
So why do signatures expire, and what infrastructure does that require?
Hint: The equation holds forever; the inference from it does not.
Answer:
The equation is timeless and the inference is not. The signature proves the private key was used. What it cannot prove is when, or that the key was still under the signer's control at the time.
So certificates carry validity periods, and a signature is trusted only if the certificate was valid when the signature was made — which requires knowing when that was.
That needs a trusted timestamp, from a timestamping authority that signs a statement binding a document's hash to a time. Otherwise a compromised key can be used to backdate.
And revocation, so that a key known to be compromised stops being trusted before its expiry — CRLs, OCSP, or short-lived certificates that expire faster than a revocation could propagate.
Plus algorithm ageing. A signature made with SHA-1 in 2005 was sound then and is forgeable now, so long-lived archives must re-sign under stronger algorithms while the old ones are still trustworthy.
The general point: cryptography gives a fact about a key, and a system is what turns that into a fact about a person at a time. Almost all the complexity of PKI is in that translation, which is Chapter 15's subject.
Matching
Four constructions from this chapter, each with one thing the others do not have.
Match the pairs
Why: RSA's determinism is a mixed blessing: no nonce to get wrong, but the signature leaks that two documents are identical. ElGamal's randomisation removes that leak and introduces the nonce requirement. DSA keeps the randomisation and adds the subgroup, which shrinks the signature eightfold and defeats Pohlig-Hellman structurally. And blind signing exists only for RSA in this chapter because it depends on multiplicativity — the very property that makes unhashed RSA signing unsafe.
Constraint
A smart meter signs a 32-byte reading every fifteen minutes, over a low-bandwidth radio link, for a twenty-year deployment. It has 32 KB of RAM and no hardware crypto.
Discussion prompt
Choose a scheme and justify each decision against a specific constraint.
Hint: Signature size and RAM point the same way; the twenty-year life points somewhere else.
Answer:
Not RSA-3072. A 384-byte signature on a 32-byte reading is twelve times overhead on a bandwidth-constrained link, and the modular arithmetic needs more RAM than the device has to spare.
Use an elliptic curve scheme — Ed25519. 64-byte signatures, 32-byte keys, and it runs comfortably in the available RAM. That is a sixfold bandwidth saving on every message.
Ed25519 specifically, rather than ECDSA, because it uses deterministic nonces derived from the message and the private key. On a device with no good entropy source, the nonce requirement is the most likely thing to be got wrong, and Ed25519 removes it as a decision.
Hash with SHA-512, which Ed25519 specifies internally — giving 256-bit collision resistance, comfortable over twenty years.
Provision a per-device key at manufacture, so one extracted device does not compromise the fleet. Smart meters are physically accessible by definition.
And a re-keying path with an algorithm identifier in every message, because twenty years is long enough that the curve will need replacing. Chapter 7's DES lesson, applied for the last time.
Missing information
The phrase appears in compliance documentation constantly.
Discussion prompt
List what a reviewer still cannot determine, ordered by risk.
Hint: Almost none of the questions are about the signature algorithm.
Answer:
Is the message hashed, and with what? Unhashed signing enables multiplicative forgery; a 128-bit hash enables the birthday attack. Neither is visible from the sentence.
Where does the private key live? A key in a file next to the application is not a key. An HSM or a secure element is what makes 'only Alice could have signed it' true.
Is the nonce generated correctly? For any DSA-family scheme this is the single most likely failure, and it hands over the private key rather than one signature.
What does the verifier actually check? The chain to a trusted root, the hostname or identity, the validity period, revocation status — every one of which has been omitted in shipping code.
Is there a trusted timestamp? Without one, a signature cannot be distinguished from a backdated one made after a key compromise.
And what does the signature cover? A signature over a document body that omits its metadata, or over a hash computed before a transformation, protects less than it appears to.
Six questions, none about the algorithm — which is the same conclusion this course has reached about AES, RSA, Diffie-Hellman and hashing in turn.
Elimination
Every DSA-family signature needs a k, and the choice of source has destroyed real systems.
Eliminate the wrong options
Which source is safe?
Survives elimination: c
Why: Deterministic nonce generation solves the problem by removing the random source entirely: k depends on the message and the private key, so it is unpredictable to anyone without the key, never repeats across different messages, and cannot be degraded by a weak generator. It is what Ed25519 does by construction and what RFC 6979 specifies for ECDSA. Note that option (d) is the naive-correct implementation and is still wrong — the bias must be removed by rejection sampling.
Missing information
A library function returns true. The signature is mathematically valid.
Discussion prompt
List what the caller must still check before acting on the document.
Hint: The equation holding is the first of five conditions, not the only one.
Answer:
Whose key was it? A valid signature under an attacker's key is still valid. The public key must be tied to an identity — through a certificate chain that has itself been verified to a trusted root.
Does the identity match what was expected? A certificate valid for evil.example verifies perfectly and says nothing about bank.example. Hostname matching lives outside signature verification and has been omitted in shipping libraries repeatedly.
Was the certificate valid at the signing time? Which requires knowing the signing time, which requires a trusted timestamp — otherwise a compromised key can backdate.
Has it been revoked? And does the check fail open or closed? Failing open is common, because failing closed causes outages.
Is the algorithm still adequate? A SHA-1 signature verifies exactly as well as a SHA-256 one, and is forgeable. Verification returning true says nothing about whether the algorithm still means anything.
Five checks, and the mathematics covers none of them. This is why 'the signature verified' is the beginning of an authorisation decision rather than the end of one.
Picture it
The differences that decide which one a system uses are all in this table, and none of them is about which is more secure.
Figure (svg): The three signature schemes compared on signature size, randomisation and the problem each rests on.
RSA has no nonce to get wrong; DSA's signatures are six times smaller. Both are still deployed, and both choices are defensible.
Estimation
At 128-bit security, DSA uses a 2048-bit p with a 256-bit q; RSA uses a 3072-bit modulus.
Predict first
How do the signature sizes compare?
Correct: DSA is about six times smaller
Elliptic curve DSA improves further: a 256-bit curve gives 512-bit signatures with 256-bit keys and much faster arithmetic, because Chapter 10's index calculus does not apply.
The reason RSA survives despite this is verification cost — with e = 65537, verifying an RSA signature is far cheaper than verifying a DSA one, and certificates are verified far more often than they are issued.
Why: A DSA signature is two values reduced mod q — 512 bits in total. An RSA signature is one value mod n — 3072 bits. That is a factor of six, and it comes entirely from the subgroup: the exponents live mod q while the arithmetic happens mod p. On a constrained radio link or in a certificate chain repeated millions of times, six times is a large practical difference.
Figure (svg): DSA works in a prime-order subgroup, so the exponents live mod q while the arithmetic happens mod p.
Explain it
A colleague asks why a shared password is not good enough to prove who sent a message.
Discussion prompt
Explain it with an everyday comparison, and name the exact moment the shared secret fails.
Hint: Think about two people who both know a safe's combination.
Answer:
The comparison: two people share a safe's combination. Something is taken from the safe. Each knows whether they took it, so each is convinced about the other — but neither can prove it to a third party, because either could have done it.
The exact moment it fails is when a third party has to decide. Bob is genuinely convinced Alice sent the message, because he knows he did not write it. A judge has no such private knowledge and cannot rule Bob out.
A signature changes the shape. Only Alice holds the private key, and Bob does not — so the evidence is no longer consistent with Bob having produced it. Anyone can check, and nobody but Alice could have made it.
The practical translation: use a MAC when both parties trust each other and only need to detect tampering by outsiders. Use a signature when a dispute between the two parties is possible, or when someone outside the conversation must be convinced.
And a caveat to add: the signature proves the key was used, not that Alice was at the keyboard. Which is why the legal frameworks are mostly about key custody and very little about mathematics.
Discrimination
Several constructions in this course look alike and answer different questions.
Sort into buckets
Sort each one.
Cost model
Chapter 1 said public key operations cost orders of magnitude more. Here is where that lands in a protocol.
Annotate
On: \( \text{sign} \approx 1.5\log_2(d) \text{ modular multiplications} \qquad \text{MAC} \approx 2 \text{ hash calls} \)
The hybrid pattern from Chapter 1, appearing for the third time: use the expensive primitive once on something small, and a cheap one for the volume.
Socratic
DSA computes r = (α^k mod p) mod q — two reductions, with different moduli.
Discussion prompt
What is each one doing, and why can they not be collapsed?
Hint: One is the group operation and one is a projection into the exponent space.
Answer:
The first reduction, mod p, is the arithmetic itself. α^k is computed in the multiplicative group mod p, and that group is where the discrete log problem is hard. It cannot be done anywhere else.
The second, mod q, projects the result into the exponent space. s is computed mod q, and the verification recombines r with s — so r has to be a number that arithmetic mod q can use. Without it, r would be a 2048-bit number appearing in a 256-bit computation.
They cannot be collapsed because they are not the same operation: the first is a group element, the second is a bare integer reduction of that element's representative. It is a deliberate type mismatch, and it is what shrinks the signature.
The price is that r loses information. Different α^k values can reduce to the same r, which is why the verification recomputes the same double reduction rather than comparing group elements — v = (α^{u₁}β^{u₂} mod p) mod q is checked against r, and the two reductions must match exactly.
And it is why q must be prime and divide p−1: the subgroup of order q must exist, and α = g^((p−1)/q) is what constructs a generator of it.
Anomaly
Eve picks a random s₁, computes m₁ ≡ s₁^e mod n, and publishes the pair (m₁, s₁) as Alice's signature.
Predict first
Does it verify, and is this a break?
Correct: It verifies, but m₁ is uncontrolled gibberish — an existential forgery, which hashing eliminates
The distinction between existential and selective forgery is worth keeping: existential means the attacker produces some valid pair, selective means she produces one for a message she chose. Modern definitions require security against the stronger notion.
It also explains why the security definition for signatures is 'existential unforgeability under chosen-message attack' — the strongest reasonable goal, chosen precisely so that curiosities like this one count as failures.
Why: The pair verifies perfectly: s₁^e ≡ m₁ by construction. But Eve chose the signature and the message came out of the exponentiation, so m₁ is a random-looking number rather than a contract. The book notes Alice's claim of forgery would be believable. It is a real weakness with a name — existential forgery — and hashing removes it, because Eve would then need a message m with h(m) = m₁, which is a preimage problem.
Fill the middle
Three blanks, and the verification is on the page.
Fill in the blanks
u_1 \equiv s^mr, \quad u_2 \equiv s^r___ \pmod q, \quad v = \bigl(\alpha^___\beta^___ \bmod p\bigr) \bmod q, \quad \text___ v = ___
Why: The verification never uses the private key a — it enters only through β = α^a, which is public. And note the double reduction in v: mod p for the arithmetic, then mod q to match r's form. The equality holds because α^{u₁}β^{u₂} reduces to α^k, and r was defined as exactly that value doubly reduced.
Sorting
Retrieval across Chapters 9 to 13. Every one of these has broken a real deployment.
Sort into buckets
Sort each failure by what it immediately gives the attacker.
Three columns, three incident responses: re-sign, revoke, or rotate and assume everything encrypted was read.
Scale up
The same 128-bit security level, in four schemes. This table is why elliptic curves took over.
Step through it
Why does DSA's key stay at 3072 bits when its signature is only 512?
Because the arithmetic still happens in the group mod p, where index calculus applies — the subgroup only shrinks the exponents. Moving to an elliptic curve removes index calculus entirely, which is what finally shrinks the key as well.
Real world
A browser trusts a website's key because of a chain of signatures ending at a root it already has.
Discussion prompt
Walk the chain, and say what each signature actually asserts.
Hint: There are usually three links, and each one is a signature over a different thing.
Answer:
The root certificate is self-signed and shipped with the browser. It asserts nothing cryptographically — it is trusted because it was installed, which is the anchor the whole system hangs from.
The root signs an intermediate certificate, asserting: this intermediate public key is authorised to issue certificates. The root's private key is then kept offline, which is why intermediates exist at all.
The intermediate signs the server certificate, asserting: this public key belongs to this domain name, until this expiry date.
The server signs the key exchange, asserting: I hold the private key matching that certificate, and these are my Diffie-Hellman values. This is the link that defeats Chapter 10's intruder-in-the-middle attack.
Each signature covers a hash, so the birthday attack applies at every link — which is why MD5-signed intermediates were catastrophic in 2008 and why SHA-1 was removed from the ecosystem.
And the verification is the part that fails. Not walking to a root, not matching the hostname, ignoring expiry, failing open on revocation — every one has shipped in a real library.
Edge cases
A code-signing key signs thousands of releases over many years.
Discussion prompt
What bounds its useful life, and what happens at each bound?
Hint: Three separate clocks are running.
Answer:
The algorithm's clock. RSA-2048 is adequate now and will not be indefinitely; SHA-256 likewise. When the algorithm ages, everything signed under it becomes forgeable — and old signatures do not become invalid, they become untrustworthy, which is worse because they still verify.
The key's exposure clock. Every use is an opportunity for a side channel, a fault, or an operational mistake. Keys in an HSM age slowly; keys in a build pipeline age fast.
The certificate's clock. The certificate binding the key to an identity expires, and after that a verifier cannot tell whether the signature predates the expiry — unless a trusted timestamp says so.
What happens at each: algorithm ageing requires re-signing the archive while the old algorithm is still sound. Exposure requires rotation and, if compromise is suspected, revocation. Certificate expiry requires timestamping, or every old signature silently stops being verifiable.
The practical design: short-lived signing certificates, a long-lived offline root, timestamps on every signature, and a re-signing plan. That is exactly what code-signing infrastructures look like, and the complexity is all in the clocks rather than the mathematics.
Pattern
Four schemes in this chapter, and the same five parts in each.
And the recurring warning, now for the last time in the symmetric-and-public-key half of the book: each of these five has broken a real system, and none of the breaks required attacking the underlying hard problem.
Figure (svg): The three signature schemes compared on signature size, randomisation and the problem each rests on.
Trap
The trap. RSA's two exponents are symmetric, so applying d and then e recovers the message just as applying e then d does. Signing is therefore encryption with the private key, and verification is decryption with the public one. One key pair serves both, and the two operations are the same code.
The description is common, it works for textbook RSA, and every part of the conclusion is wrong.
It is false for every other scheme. An ElGamal or DSA signature is a pair (r, s) produced by solving a congruence involving a nonce. There is no encryption anywhere in it, nothing is being decrypted, and no amount of squinting makes the operations coincide.
It is false for real RSA too. Signing uses PSS padding and encryption uses OAEP — different structures, different security proofs. The raw operation they share is the one nobody should use.
And acting on it is a genuine vulnerability. Using one key pair for both makes the signing service a decryption oracle: an attacker submits a ciphertext as a 'document to be signed' and gets its plaintext back with a signature attached. Standards mandate separate keys for signing and encryption specifically to close this.
The two are different services with different definitions. Encryption aims at indistinguishability — Chapter 4's game. A signature aims at existential unforgeability under chosen-message attack, which is a different game with different rules. That they share arithmetic in one special case is a coincidence of RSA.
The habit to build: name the security goal before reasoning about the mechanism. Two operations that compute the same thing can still be answering different questions.
Check
Work it out before you click.
Check your understanding
Alice signs two different messages with DSA using the same k. What does an attacker obtain?
Answer: B
Why: The repeated k gives the same r in both signatures, which is visible immediately. Then s₁ − s₂ ≡ k⁻¹(m₁ − m₂) mod q solves for k, and a ≡ r⁻¹(s₁k − m₁) mod q gives the private key. Two signatures, two linear congruences, and every future signature is forgeable. This is how the PlayStation 3's signing key was recovered.
Check
Consider what an attacker can do without the hash.
Check your understanding
Alice signs messages with raw RSA. Eve has valid signatures on m₁ and m₂. What can she produce?
Answer: C
Why: RSA is multiplicative: s₁s₂ ≡ m₁^d m₂^d ≡ (m₁m₂)^d, a valid signature on the product. One multiplication, no key. Hashing prevents it because the forgery would be on h(m₁)h(m₂), and Eve would need a message hashing to that value — a preimage problem she cannot solve.
Check
Apply Chapter 12's bound.
Check your understanding
A signature scheme aims at 128-bit security. What digest length does the birthday attack force?
Answer: C
Why: The birthday attack finds a collision in 2^(n/2), so the digest must be twice the security level: 256 bits. An attacker prepares 2¹²⁸ variants of each of two documents and matches them, then has the innocuous one signed. This is why SHA-256 is the modern minimum for signing, and why MD5's 128 bits gave only 64-bit resistance.
Connect it up
Four schemes and five requirements, and they compress well.
Draw it
Write the RSA sign and verify equations, then ElGamal's three signing steps and its verification equation, then DSA's, marking where q rather than p−1 appears and what that buys. Beside them write the five requirements from the pattern slide, and against each the specific attack it prevents. Finish with the two derivations that matter: why a repeated k gives the private key, and why the digest must be twice the security level.
The two derivations at the end are the ones worth being able to reproduce — one has destroyed a real system and the other decides every hash choice you will ever make.
Exit ticket
One question, about the property this chapter exists to deliver.
Predict first
Why can a MAC never provide non-repudiation, however strong it is?
Correct: The verifier holds the same key, so anything the signer could produce the verifier could too — no third party can attribute the tag
Why: Non-repudiation means a third party can be convinced. With a shared key, the recipient could have produced the tag himself, so a judge cannot rule him out — the evidence is consistent with two authors. A signature breaks the symmetry: only the private key produces it, and the public key verifies it, so the verifier is not a candidate author. This is a structural property of key ownership, and no strengthening of a MAC algorithm affects it.
Recap
The fourth of Chapter 1's objectives, finally delivered.
Chapter 14 next. A chapter of failures — an Enigma 'feature', badly chosen RSA primes, and WEP. Every one has sound primitives and a broken assembly, which is the point the last six chapters have been building towards.
Figure (svg): The three signature schemes compared on signature size, randomisation and the problem each rests on.
Want this taught 1-on-1? Alexander tutors Cryptography — $55/session, free consultation.