Path: blob/main/frontier/09-commitments-sigma-protocols/sage/09d-schnorr-protocol.ipynb
483 views
The Schnorr Protocol
Module 09d | 09-commitments-sigma-protocols
The most important sigma protocol: completeness, special soundness, honest-verifier zero-knowledge
From Framework to Concrete Protocol
In 09c, we studied the abstract structure of sigma protocols: three moves (commit, challenge, response), and three properties every sigma protocol must satisfy (completeness, special soundness, HVZK). That was the framework, the blueprint.
Now we instantiate it. The Schnorr protocol (1989) is the single most important sigma protocol in cryptography. It is:
The foundation of Schnorr signatures (standardized in EdDSA / Ed25519)
The core of Bitcoin's Taproot upgrade (BIP 340)
The building block for zero-knowledge proofs in SNARKs and bulletproofs
The textbook example every cryptographer learns first
If you understand Schnorr deeply, you understand the DNA of modern zero-knowledge cryptography.
The Motivating Question
Alice knows such that . She wants to PROVE she knows to Bob WITHOUT revealing . Not even a single bit. Can she?
Think about how strange this is. Alice must convince Bob she knows a secret, yet Bob must learn absolutely nothing about what that secret is. It sounds impossible, like proving you know the combination to a safe without ever touching the dial.
Schnorr showed it is not only possible, but elegant. Three messages. Three properties. One beautiful protocol.
Setup: The Schnorr Group
We work in a prime-order subgroup of :
Choose a large prime and a prime such that
Pick a generator of the unique order- subgroup of
The secret key is
The public key is
We use a prime-order subgroup (not all of ) because we need every non-identity element to be a generator, and we need clean modular arithmetic in the exponent (mod ).
The Schnorr Protocol: Three Moves
Recall the sigma protocol skeleton from 09c: Commit Challenge Response. Here is Schnorr's instantiation:
| Step | Who | What | Detail |
|---|---|---|---|
| 1. Commit | Prover Verifier | Send | Pick random , compute |
| 2. Challenge | Verifier Prover | Send | Pick random |
| 3. Response | Prover Verifier | Send | Compute |
Verification: The verifier accepts if and only if .
That is the entire protocol. Three messages. One equation to check.
Why Does Verification Work?
Let's trace the algebra step by step. The verifier checks whether .
Substituting and , :
Each step uses a basic exponent rule. The key insight is that the response encodes both the nonce and the secret , but the verification equation lets the verifier check consistency without separating them.
Misconception alert: "The prover sends , which contains , so the verifier learns ." No! The value alone reveals nothing about because the nonce is unknown to the verifier. Think of it as a one-time pad for the secret: perfectly masks , just as a one-time pad key masks a message. Without , the verifier cannot disentangle from .
Checkpoint: Verify by Hand
Before running the next cell, take the values of , , , , , from the protocol run above and verify the equation by hand (or with a calculator). Does it check out?
Property 1: Completeness
Completeness says: if the prover is honest (really knows ), the verifier always accepts.
We proved this algebraically above. Let's also verify it experimentally, run the protocol 1000 times and confirm every execution succeeds.
Property 2: Special Soundness
Special soundness says: given two accepting transcripts and with the same commitment but different challenges , we can extract the secret .
Here's the extraction. From the two transcripts:
Subtract:
Since is prime and , the value is invertible mod :
This means: a cheating prover who doesn't know cannot answer two different challenges for the same . If they could, we could extract , contradicting the assumption that they don't know it.
What Special Soundness Really Means
Special soundness is the security guarantee for the verifier. It tells Bob:
"If Alice can answer my challenge for a given , she must know , because if she could answer two different challenges, I could extract myself."
A cheating prover who doesn't know can guess the challenge in advance and construct a single valid response (with probability ), but she cannot answer two challenges for the same . This is why the challenge must be truly random and unpredictable.
Property 3: Honest-Verifier Zero-Knowledge (HVZK)
HVZK says: the verifier learns nothing from the protocol beyond the fact that Alice knows . Formally, there exists a simulator that can produce transcripts that are indistinguishable from real transcripts, without knowing .
The Simulator
The simulator works backwards:
Pick random and random
Compute
Output the transcript
Why this works: By construction, and . So the verification equation holds!
The simulator never touches . It only uses the public key . Yet it produces perfectly valid transcripts. This means the transcript itself carries zero information about , because someone without can produce equally valid ones.
Checkpoint: Simulated vs. Real
Look at the simulated transcripts above. Can you tell them apart from the real transcript we generated earlier? You should not be able to, that is the whole point. If you could distinguish them, the protocol would leak information about .
The distributions are identical:
In a real transcript, and are both uniformly random (since is random, is uniform mod ), and is determined by them.
In a simulated transcript, and are chosen uniformly at random, and is determined by them.
Same distribution.
Statistical Comparison: Real vs. Simulated
Let's go further and compare the distributions of values in real vs. simulated transcripts. Both should be uniform over .
Critical Security Requirement: Fresh Nonces
The nonce MUST be chosen uniformly at random and MUST be fresh for every protocol execution. If the same is ever used twice, the secret is immediately recoverable.
Suppose Alice uses the same (and hence the same ) in two different proofs with challenges :
Then . This is exactly the special soundness extractor, but now an eavesdropper can run it!
Crypto Foreshadowing: This is EXACTLY what happened in the 2010 PlayStation 3 hack. Sony used ECDSA (which has the same nonce structure as Schnorr) but used a fixed nonce for every signature. The hacker group fail0verflow extracted Sony's private signing key from two signatures, broke PS3 code signing entirely, and enabled homebrew software on every PS3. The same vulnerability has leaked Bitcoin private keys when wallet software reused nonces.
Exercises
Three exercises following the worked guided independent pattern.
Exercise 1: Verify a Schnorr Proof by Hand (Fully Worked)
Problem: Given the following small Schnorr group and transcript, verify the proof step by step.
, , (which has order 11 mod 23)
Public key:
Transcript: , ,
Task: Check whether .
Exercise 2: Build a Simulator (Guided)
Problem: Using the same small group (, , , ), write a simulator that produces a valid Schnorr transcript without knowing the secret .
Hints:
Pick any and any
Compute . Remember that is the modular inverse:
power_mod(y, -c, p)Verify that passes the verification equation
Fill in the code below.
Exercise 3: Extract the Secret from Nonce Reuse (Independent)
Problem: An eavesdropper observes two Schnorr proof transcripts that share the same commitment . The parameters are , , (order 23 mod 47).
| Transcript | |||
|---|---|---|---|
| 1 | 17 | 5 | 19 |
| 2 | 17 | 14 | 8 |
Extract the secret key . Then verify your answer by checking that matches the public key implied by the transcripts.
Hint: the extraction formula is .
The Big Picture: Three Properties Working Together
Let's step back and see how the three properties combine to make the Schnorr protocol useful:
| Property | What it guarantees | Who benefits |
|---|---|---|
| Completeness | An honest prover always convinces the verifier | Prover (Alice) |
| Special Soundness | A cheating prover cannot fool the verifier | Verifier (Bob) |
| HVZK | The verifier learns nothing about | Prover (Alice) |
Together, these three properties achieve the seemingly impossible: Alice proves she knows (soundness), Bob is convinced (completeness), and yet Bob learns nothing about (zero-knowledge).
Bonus: What Happens if a Cheating Prover Tries?
Suppose Eve does NOT know , but she tries to pass the Schnorr protocol anyway. She has two strategies:
Guess the challenge in advance: Pick , compute a valid response for that specific . This works with probability , negligible for cryptographic .
Try to compute after receiving : She knows (she chose it) and (from the verifier), but computing requires knowing . Without , she's stuck.
Let's see strategy 1 in action.
Looking Ahead
The Schnorr protocol as presented here is interactive: Alice and Bob must exchange messages in real time. This is fine for identification ("prove you're Alice"), but it limits applications.
In the next notebook (09e), we will see the Fiat-Shamir transform: replace the verifier's random challenge with a hash . This converts the interactive Schnorr protocol into:
Schnorr signatures (non-interactive proofs of knowledge, attached to a message )
NIZKs (non-interactive zero-knowledge proofs)
This is the bridge from identification to digital signatures, and from interactive proofs to the proof systems used in blockchains.
Summary
| Concept | Key idea |
|---|---|
| The protocol | Prover sends , receives challenge , responds with . Verifier checks |
| Completeness | The algebra guarantees honest provers always pass: |
| Special soundness | Two transcripts with the same let anyone extract . A cheating prover cannot answer two challenges |
| HVZK | A simulator picks at random, computes , and produces valid transcripts without knowing . Real and simulated transcripts have identical distributions |
| Nonce discipline | Reusing is catastrophic, allowing immediate extraction of by any eavesdropper. This is the same vulnerability that broke PS3 code signing |
Next: The Fiat-Shamir Transform, turning interactive proofs into signatures.