Zero-Knowledge Proofs
Authentication and deniability seem fundamentally opposed. Authentication means becoming convinced of someone's identity. Deniability, in the context of authentication, means having no proof of interacting with someone. How can you become convinced of someone's identity without also having proof of their identity?
Amazingly, it is possible to reconcile authentication with deniability, to authenticate without a trace. I can prove my identity to you in such a way that leaves you with no evidence you could use to convince someone else. This concept of leaving no trace is called zero knowledge, and it is not limited only to authentication. A zero-knowledge proof lets me convince you that something is true—like the fact that I know a private key corresponding to some public key—while leaving no useful information behind.
19.1. The Schnorr identification protocol
Cryptographic authentication happens with respect to a public key. Let's consider key pairs where an integer is the private key and is the corresponding public key, where is the generator of a suitable cyclic group. “Authenticating the owner of public key ” means becoming convinced that you are talking to someone who knows the discrete logarithm of . The following interactive protocol, named after its creator Claus Schnorr, is a method for doing just that:
Let be a cyclic group with generator and prime order . Suppose a verifier knows a group element . The following protocol, called the Schnorr identification protocol, allows a prover to convince the verifier that it knows the discrete logarithm of .
The modulus must be prime because our analysis of this protocol requires multiplicative inverses mod .
When the protocol is executed as shown above, the verifier will always accept, because
It's more interesting to consider what happens when one of the participants is adversarial.
Lying prover: The verifier wants to be sure that only someone who knows the private key can succeed in the protocol. The analysis of Schnorr's protocol uses a clever way to characterize whether a cheating prover “knows” a certain value.
The transcript of a Schnorr protocol execution consists of values . It is an accepting transcript if —in other words, if the verifier would accept.
There is an efficient algorithm that computes the discrete logarithm of , given any two accepting transcripts and with the same and but different .
If and are accepting transcripts, they satisfy:
“Divide” the two equations by each other (i.e., multiply the first equation by the inverse of the second). The values cancel, resulting in:
Exponents in this cyclic group operate modulo , which is a prime. Since , there exists an inverse mod . Raise both sides of the equation to this power to get:
Thus, is the discrete logarithm of , and we can compute it easily from the two transcripts.
What does this have to do with determining whether the prover knows , you might be asking? Consider the moment in Schnorr's protocol immediately after the prover has sent their first message . The verifier is about to sample . For any possible , we can imagine whether the prover would be able to produce the correct response, causing the verifier to accept. There are two cases to consider:
-
The prover could respond correctly to two different values of . If the prover is able to do this, then from claim 19.1.3 the prover surely has enough information to compute . Thus, it is safe to say that the prover knows , and it is fine that the verifier accepts.
-
Otherwise, the prover can respond correctly to at most one value of . It doesn't matter what this value is, just that there is at most one such value. Since the verifier samples uniformly in , the chance of choosing this special value is , which is negligible ( is exponentially large, as the order of a cryptographically strong cyclic group). Barring this negligibly likely bad event, the verifier must choose a for which the prover cannot produce the correct response, so the verifier will reject.
Nosy verifier: What does the verifier learn about the prover in this protocol? This answer is (arguably) best understood with a story:
King Richard decides to hold an archery competition to identify the best archer in the land. He constructs a long wooden wall, with many targets painted on it. During the competition, he is stunned as Robin Hood stands 100 meters away from the wall and fires one arrow into the center of each of the targets. Of course, Robin Hood is declared the winner.
Later that day, the Sheriff of Nottingham arrives at the King's castle. The King describes Robin Hood's exceptional performance, pointing to the arrows still in the targets. The Sheriff is not impressed. “Robin Hood is a fraud and a liar. Those arrows prove nothing,” he says. He takes his own bow and fires a series of arrows into blank parts of the wall. He finds a bucket of paint and paints a target around each of his arrows. “See,” he says again, “arrows in targets prove nothing!”
Why does the King think that an arrow in the middle of a target is convincing evidence of Robin Hood's skill, but the Sheriff does not? The Sheriff is correct that it requires no skill to produce an arrow in the center of a target. On the other hand, it requires great skill to produce an arrow in the center of a target if the target is painted before the arrow is fired! The King saw that the target was painted before Robin Hood fired his arrow, but the Sheriff did not.
In the world of zero-knowledge, the artifacts of the interaction are not convincing in themselves; what is convincing is the manner in which those artifacts were produced. We can say something similar about Schnorr's protocol:
Alice, whose public key is , contacts Bob and uses Schnorr's protocol to prove that she knows the secret key . Bob is convinced that he is talking to Alice, and he writes down everything he sees: .
Later that day, Charlie arrives at Bob's house. Bob mentions that he talked to Alice earlier in the day, and he shows Charlie the accepting transcript . “That proves nothing,” says Charlie, and he proceeds to generate his own accepting transcript , even though he doesn't know .
In the Schnorr protocol, and are like the target, and is like the arrow. If is chosen first and second, then only someone who knows Alice's private key can produce the correct (except with negligibly small probability). Like King Richard at his archery competition, a verifier who participates in Schnorr's protocol becomes convinced that the prover knows . However, after the interaction is finished, its transcript is meaningless. Anyone can create an accepting transcript by choosing and first, and then solving for ; this is like painting a target where the arrow struck. And since these “fake” transcripts can be generated without knowing the secret value , the “real” Schnorr transcripts, generated using , cannot leak any information about .
Let's see how to generate Schnorr protocol transcripts without knowing the private key:
The following two libraries are indistinguishable:
In other words, transcripts generated by running the protocol (where the prover uses its secret exponent ) are indistinguishable from transcripts generated using only , which the verifier already knows.
An authentication session using Schnorr's protocol leaves behind no valuable information. Everything the verifier sees during the protocol, he could have generated himself using the process in , even without knowing the private key .
Compare this aspect of Schnorr's protocol with signature-based authentication. Only someone who knows the signing key can generate a valid signature. If Alice authenticates by sending Bob a signature, she gives him something that he could not have computed himself. He could have obtained this signature only by interacting with Alice.
19.2. Sigma protocols
Schnorr's protocol is an example of a special kind of interactive proof called a sigma protocol.
Unfortunately, two very fundamental things in cryptography are named “sigma protocols”: the interactive proofs in this section, and the authenticated key exchange protocol from section 18.2.4. The key exchange protocol is usually written in all-caps.
An interactive proof is simply an interactive protocol in which the prover tries to convince the verifier that some condition is true.
In Schnorr's protocol, there is a public value , known to both the prover and verifier; the prover wants to convince the verifier that it knows a private value that satisfies . In a generic sigma protocol, there is a public value called an instance; the prover wants to convince the verifier that it knows a private witness such that and together satisfy some condition (or predicate).
-
In the Schnorr protocol, is the instance; the private key is the witness; the condition is .
-
Alice may wish to convince Bob that a triple of group elements have the form , as in the DDH problem, without revealing their discrete logarithms. In this case, are the instance; the exponents and are the witness; and the condition is .
-
Alice may wish to convince Bob that is an El Gamal encryption under some public key , of either or , without revealing which one. In this case, is the instance; and the encryption randomness are the witness; and the condition is [ and ].
-
Alice may wish to convince Bob that a string is the output of a PRG , without revealing the corresponding seed. In this case, is the instance; the seed is the witness; and the condition is .
A sigma protocol consists of the following parameters:
-
: a randomized algorithm that takes an instance and witness as input, and outputs a protocol message and state . (The prover sends two messages in a sigma protocol, and represents the information that the prover must remember in the meantime.)
-
: a set of verifier challenges.
-
: a deterministic algorithm that takes state and challenge as input, and outputs a response .
-
: a deterministic algorithm that takes a transcript as input, and outputs a boolean.
These algorithms are intended to be executed in the following interactive protocol:
In the language of mathematical proofs, completeness means that every true thing should have a valid proof, and soundness means that only true things have valid proofs. Interactive proofs like sigma protocols must be both complete and sound in order to be useful:
The sigma protocol is complete (with respect to a condition ) if, for any satisfying , the verifier always accepts when the protocol is run according to the definition above.
We define soundness for sigma protocols in the style of Schnorr's protocol. Namely, if there are two accepting transcripts that share a common prefix, then we must be able to extract a witness that satisfies . This way of defining soundness is highly specialized to the strict structure of a sigma protocol, and is not meaningful for all flavors of interactive proofs that cryptographers study. Thus, it is traditionally called special soundness.
A sigma protocol has special soundness (with respect to a condition ) if there is an efficient algorithm with the following property: For any two accepting transcripts and with the same and but different , outputs a witness such that is true.
We call an interactive proof zero-knowledge if, informally, the interaction reveals nothing about the witness to the verifier. This property can be formalized by saying that there is a way to generate convincing protocol transcripts without using the witness at all. By definition, these “fake” transcripts contain no information about the witness. So if they are indistinguishable from real transcripts, then real transcripts must not leak information about the witness.
The zero-knowledge security definition for sigma protocols considers only transcripts that are generated with a verifier who follows the protocol. Thus, the definition can be interpreted as: Verifiers who follow the protocol learn nothing about the witness. Other forms of zero-knowledge proofs, which we do not study in this book, also consider the more challenging case where a verifier cheats in (deviates from) the protocol.
A sigma protocol is honest-verifier zero-knowledge (HVZK) if there is an efficient algorithm , called a simulator, such that the following two libraries are indistinguishable:
Importantly, does not use at all.
19.3. More examples of sigma protocols
This section introduces several more sigma protocols for proving more complex conditions.
19.3.1. Proof of discrete log equality
Let be cyclic group elements, and suppose the prover would like to convince the verifier that it knows a value such that and —in other words, that two discrete logarithms are equal.
Running Schnorr's identification protocol twice, first on and then on , would establish that the prover knows both discrete logs, but it would do nothing to establish that those discrete logs are equal. The idea instead is to run these two instances of Schnorr's protocol, but restrict the prover to use the same challenge and response in both instances. It turns out that this idea is enough to ensure that the two discrete logs must be equal.
Let be a cyclic group with generator and prime order . The following sigma protocol allows the prover to convince the verifier that it knows a witness such that and , for a public instance :
Shown visually, the protocol is as follows:
Construction 19.3.1 has special soundness.
Suppose we are given two accepting transcripts for construction 19.3.1:
with . Since they are both accepting, we have:
Divide matching equations to cancel and , resulting in:
Then since is prime and , there is a multiplicative inverse mod . Exponentiate both sides of the equations to this power to get:
Setting , we now have and . In other words, we have computed a witness for the desired condition.
Construction 19.3.1 has honest-verifier zero-knowledge.
To simulate an accepting transcript for this sigma protocol, first sample and . Then compute and . The proof that these simulated transcripts are indistinguishable from real ones is almost identical to that of claim 19.1.4, and is omitted here.
19.3.2. Proving ANDs and ORs
In this section we show how to construct sigma protocols for more complicated conditions, involving ands and ors. For example:
-
Alice wants to prove that she knows the discrete log of either or . Imagine that these are public keys of two people who are authorized to use a system, and Alice wants to authenticate without revealing who she is.
-
Given a public ciphertext , Alice wants to prove that . In other words, either the ciphertext decrypts to , or it decrypts to . The ciphertext may represent a vote in an election, and Alice wants to prove that she cast an unambiguous vote, without revealing it.
-
Alice wants to prove that satisfy . In other words, the discrete logs of and are equal, and the discrete logs of and are equal.
Proving an OR: We start with the case of an or of two conditions. Suppose we have a sigma protocol for condition and a sigma protocol for condition . A prover wants to prove knowledge of such that [ or ], or in other words, prove knowledge of and such that .
To understand the clever idea behind this sigma protocol, we return to the metaphor involving arrows and targets. Robin Hood has two bows and wants to convince the King that he can fire one of them accurately. The King could draw two targets and ask Robin to fire an arrow from each bow and hit the two targets. But Robin might not be able to hit both targets, because one of his bows might be erratic. Additionally, the final positions of the arrows might reveal to the King which bow is the good one.
Instead, the King should draw only one target, and ask Robin to fire an arrow from each bow, so that the target is precisely between the two arrows. As long as Robin can fire just one bow accurately, he can succeed. He should first fire the erratic bow; its arrow will land unpredictably, likely nowhere near the target. But then Robin knows exactly where he should fire the second arrow, now from the accurate bow, so that the target is precisely between the arrows.
Okay, this physical metaphor is convoluted and strained, but it captures the spirit of the sigma protocol, which works as follows:
-
The prover sends the first messages () in parallel instances of and .
-
The verifier uniformly samples and challenges the prover to complete two accepting transcripts and , such that . Here, and are like the two arrows, which can be fired anywhere but whose average (or sum, in this case) must hit a particular target .
-
Suppose the prover knows a witness for but not . Then it should have generated by simulating a transcript . Now the prover is bound to use this and has no control over , so it must use its witness to construct the correct response in the instance.
The formal details are given below. The verifier thinks of the two sigma protocol instances using subscripts 0 and 1, but the prover, who has a witness for , thinks of them using subscripts and .
Let and be sigma protocols for conditions and , respectively, with identical challenge sets , and where has an addition operation. Define the new sigma protocol as follows:
Shown pictorially:
Construction 19.3.4 has special soundness (with respect to ) if and do.
A transcript has the form . The definition of special soundness considers the case where two accepting transcripts are known:
with . In this case a witness can be computed efficiently as follows:
The main idea is that since the two transcripts are accepting, they satisfy and . There must be some such that , because if this were not the case then it would imply , a contradiction. Focusing on this choice of , then and are two accepting transcripts for , with . Hence, we can use them to extract a witness for the condition . Altogether, we can extract such that , as desired.
Construction 19.3.4 is honest-verifier zero-knowledge if and are.
The simulator for is simple: Generate simulated transcripts for and , then solve for :
Exercise 19.9 asks you to prove that the resulting simulator produces indistinguishable transcripts.
Proving an AND: Now suppose we have sigma protocols and , for conditions and , respectively, and the prover would like to convince the verifier that it knows and such that and . A natural idea is to simply run an instance of each of and , in parallel. It is true that if the verifier accepts both proofs, then he can be convinced that the prover knows a witness to both conditions. However, the resulting protocol does not technically satisfy the formal security properties of a sigma protocol; exercise 19.12 explores this issue further.
To combine and into a single protocol that satisfies all of the usual sigma protocol security definitions, we must make one small modification:
Let and be sigma protocols, for conditions and , respectively, with , where has an addition operation. Define the new sigma protocol as follows:
In short, the prover generates and as usual, but also samples a value . The verifier samples a single challenge , and the prover responds to in but responds to in .
You are asked to prove the following in an exercise:
Suppose and have special soundness and are honest-verifier zero-knowledge. Then construction 19.3.7 has also has special soundness (with respect to ) and is honest-verifier zero-knowledge.
19.4. Noninteractive proofs and signatures
19.4.1. The Fiat-Shamir transformation
Interaction in a sigma protocol is crucial: It is how the protocol enforces that the verifier's challenge is chosen after the prover has committed to a value of . Without this strict order of operations, a sigma protocol proves nothing. Indeed, we have seen that it is easy to generate an accepting transcript in a different order; this is an important feature of a sigma protocol.
But interaction is not the only way to enforce that is chosen after . Suppose we compute , where is a random oracle. Then there is indeed no way to predict before calling . Furthermore, will be distributed uniformly, just as in the sigma protocol.
The idea of replacing the verifier with a random oracle is called the Fiat-Shamir method. It converts an interactive sigma protocol into a noninteractive proof. The prover can generate the entire transcript locally:
Let be a sigma protocol. The Fiat-Shamir transformation of is defined as follows:
The intuitive idea is that only someone who knows a valid witness can generate a proof that causes to output , and yet the proof reveals nothing about the witness . We will not formally define security properties of abstract noninteractive proof systems, but rather state some useful properties of the Fiat-Shamir construction. In particular, we reason about soundness in a similar way to sigma protocols. If a prover is able to produce valid proofs, then we can efficiently extract a valid witness from that prover.
Let be a sigma protocol, let be an instance for , and let be a hash function, modeled as a random oracle, whose output range is :
Suppose there is a polynomial-time algorithm that can produce valid Fiat-Shamir proofs for instance , with nonnegligible probability. In other words,
is nonnegligible.
Then we can construct another polynomial-time algorithm that has nonnegligible probability of outputting a valid witness for .
(Sketch) As a warm-up, imagine that is a very simple algorithm that knows a witness and simply runs as instructed. In other words, computes , then , then , then outputs . Given such a program , we might hope to find in its source code. But what if were written in an obfuscated manner? Is there a way to extract the witness without needing to analyze 's source code?
One approach would be the following:
-
First, run in a simulation, where we play the role of the random oracle . We know this particular will call the random oracle as . When this happens, we:
-
record 's entire internal state at this moment (think of running in a virtual machine, and we take a snapshot of memory);
-
play the role of , uniformly choosing a response and giving it to .
-
-
Continue running , until it eventually outputs a valid proof . Thus, is an accepting transcript in the sigma protocol.
-
Next, “rewind” to its previously saved state. It has just called and is waiting for the response. This time, choose a different as the random oracle's response.
-
Continue running , until it outputs a valid proof . Now we have two accepting sigma protocol transcripts: and with . The special soundness of the sigma protocol means we can now compute a witness .
This approach does not require understanding the source code of , but it does assume that “behaves nicely.” In the more general case, could be a completely arbitrary program and the only thing we know about it is that it has a nonnegligible probability of outputting a valid proof. If we try to adapt the method above to this general case, we encounter several difficulties:
-
may call the random oracle many times, and we don't know at the time of each call whether it will be the target of our “rewinding” strategy. So we must store 's internal state every time it calls the random oracle. Only after finally outputs can we realize that we should rewind to the specific call .
-
Suppose outputs , so we rewind to the moment it calls , give a different response this time, and continue running . We have changed an input to , so it might not even output a valid proof this time; even if it does, there is no guarantee that the new proof will have the same as before! But we can only use the sigma protocol extraction algorithm if the two proofs share the same .
In order to deal with completely arbitrary programs , as in the statement of the lemma, we must address this tricky second challenge. The basic idea of the witness extraction algorithm is the following:
-
Run as above, until it outputs a valid proof .
-
Rewind to the moment it called and restart the execution with fresh random choices.
-
If outputs another valid proof using the same , use the sigma protocol extraction algorithm to compute a witness .
-
Otherwise, repeat this rewind/replay process a maximum of times ( depends on 's success probability) before giving up.
The difficulty is now arguing that if has nonnegligible probability of generating a valid proof, then successfully extracts a valid witness with nonnegligible probability. The analysis is technical and tedious, and omitted here. See the chapter notes for references to the details.
Lemma 19.4.2 is often called the forking lemma, because of how “forks” the execution of into many different branches.
Deniability: Be careful! The Fiat-Shamir technique destroys a sigma protocol's deniability property! Plain (interactive) sigma protocol transcripts are deniable, because anyone can easily generate an accepting transcript. In the real protocol execution, is chosen first, then , and then ; but anyone can generate an accepting transcript by choosing and first and then solving for .
In a Fiat-Shamir proof, we have . Anyone with access to the random oracle—which is to say, anyone at all, since a random oracle is public—can conclude that must have been chosen before . And only someone who knows a valid witness can complete an accepting transcript when is chosen before .
19.4.2. Schnorr signatures
Imagine applying the Fiat-Shamir method to Schnorr's protocol, in which the prover convinces the verifier that it knows the discrete log for a public value :
As we discussed above, such Fiat-Shamir proofs are not deniable. In some situations the lack of deniability is a bad thing, but on the other hand we have achieved almost exactly the goal of a digital signature: Only someone who knows the witness can generate a valid Fiat-Shamir proof, but anyone can verify it.
However, we have not yet constructed a digital signature scheme, because each signature needs to be associated with a particular message. We can incorporate a message by computing the sigma protocol's challenge, not as , but as . The result of this change is the Schnorr signature scheme:
Let be a cyclic group of prime order , with generator . The Schnorr signature scheme is defined as follows:
You can interpret Schnorr signatures in the following way: A valid signature is essentially an accepting sigma protocol transcript . The fact that , implies that was chosen before , and thus only someone who knows the private key could have generated the transcript. Furthermore, since is included in , the person who knows clearly generated the transcript with specifically in mind! The sigma protocol transcript is bound to .
The Schnorr signature scheme (construction 19.4.3) is secure in the random oracle model, if the discrete logarithm problem is hard in . More formally, it is secure if the following two libraries are indistinguishable:
The proof of this claim is somewhat technical, and beyond the scope of this book, but uses several important ideas introduced above:
-
We introduce a hybrid library where generates signatures in a different way: It simulates an accepting transcript , then programs the random oracle so that . Thus, is a valid signature of , but it was generated without knowledge of the signing key .
-
Next, we use the forking lemma (lemma 19.4.2) to argue that if an adversary can successfully produce signature forgeries, then there would be a way to efficiently extract the Schnorr witness . But such an algorithm would contradict the discrete logarithm assumption. So we must conclude that it is hard for an adversary to produce a forgery.
Schnorr signatures in the wild: Schnorr signatures are elegant and have a security analysis that is easy to understand in light of Schnorr's identification protocol. Schnorr signatures can be implemented using a cyclic group based on elliptic curves, leading to signatures that can be as short as 512 bits. In comparison, RSA signatures are generally 2048–4096 bits in practice, because that is the range of safe sizes for an RSA modulus.
Despite its unmistakable advantages, the Schnorr signature scheme is not used in practice as much as it deserves to be. The main reason is that for a long time the construction was subject to a patent. Governmental organizations that standardize cryptographic algorithms, like NIST, are reluctant to standardize algorithms that are encumbered by patents. As a result, the standardized options for elliptic-curve-based signatures are algorithms like ECDSA and EdDSA, two algorithms that were clearly inspired by Schnorr signatures, but that lack its simplicity and charm since an important design constraint was avoiding the reach of Schnorr's patent. Unfortunately, it is exactly these differences from Schnorr signatures that make ECDSA and EdDSA difficult for provable security. Neither has a proof that bases their security on such a simple problem as discrete logarithm. Although Schnorr's patent expired in 2010, by that time ECDSA and EdDSA had become entrenched as standards.
Exercises
-
Definition 19.2.5 asks for a simulator that generates the entire transcript together. There are some situations where we require to be chosen first, and the rest of the transcript computed as a function of . Let's say that a sigma protocol has special HVZK if there is a simulator such that the following libraries are indistinguishable:
:return:returnIn this exercise, you will show how to convert a standard sigma protocol into one with special HVZK.
Suppose is a sigma protocol and has an addition operation. Define the new protocol as follows:
-
Prove that has special soundness, if does.
-
Prove that has special HVZK, if has (plain) HVZK. Clearly describe the simulator for , in terms of the simulator for .
-
-
Let be cyclic group elements. Describe a sigma protocol that lets a prover convince a verifier that it knows such that and . Prove that your protocol satisfies honest-verifier zero-knowledge and special soundness.
-
Suppose are two public values. Describe a sigma protocol that lets a prover convince a verifier that it knows such that . Prove that your protocol satisfies honest-verifier zero-knowledge and special soundness. Assume that the group generator is public.
-
h Describe a sigma protocol for proving that a public instance has the form , and prove that your protocol satisfies honest-verifier zero-knowledge and special soundness. Assume that is public, and that the prover knows and .
Rename to and to .
-
h Let be an El Gamal ciphertext encrypted under key pair , and let be a publicly known value. Propose a sigma protocol whereby a prover can convince a verifier that .
-
Describe such a protocol that is suitable for a prover who knows , but not the randomness used to generate the ciphertext.
-
Describe such a protocol that is suitable for a prover who knows the randomness used to generate the ciphertext, but does not know .
In both cases, prove that the protocol satisfies special soundness and honest-verifier zero knowledge.
Manipulate the El Gamal decryption equation into an expression that can be proven with a single instance of the Schnorr proof. For part (b), prove knowledge of that satisfies .
-
-
h Let and be El Gamal ciphertexts, encrypted under a common public key . Describe a sigma protocol whereby a prover can convince a verifier that:
The protocol should be suitable for a prover who knows the randomness used to generate the ciphertexts but not . Prove that the protocol satisfies special soundness and honest-verifier zero knowledge.
-
Let be public group elements, in a cyclic group of prime order . Describe a sigma protocol whereby a prover can convince a verifier that it knows exponents such that . Prove that the protocol satisfies special soundness and honest-verifier zero knowledge.
-
h Let be a public instance, and suppose Alice knows a value such that but . She would like to prove in zero knowledge that and have different discrete logs. In other words, nothing should be revealed about the relationship between those discrete logs besides the fact that they are different. Describe a sigma protocol for this problem and prove that it satisfies special soundness and honest-verifier zero knowledge.
and , for any nonzero . Additionally, when is uniform, is distributed uniformly. Have the prover send to the verifier and then prove knowledge of exponents such that and . The verifier should also check that .
-
Complete the proof of claim 19.3.6: Prove that the simulated transcripts are indistinguishable from real ones.
-
Suppose the verifier forgets to check the condition in construction 19.3.4. Show how the prover can prove a false statement.
-
The prover in construction 19.3.4 convinces the verifier that one of two conditions is true.
-
Suppose there are three conditions. Describe a sigma protocol that allows the prover to prove that at least one of the conditions is true (without revealing which one). Prove that your protocol is secure.
-
Describe a sigma protocol that allows the prover to prove that at least two of the three conditions are true (without revealing which ones). Prove that your protocol is secure.
-
Generalize this construction to out of conditions and prove that your construction is secure.
-
-
Let and be sigma protocols for conditions and , respectively. Consider the naïve method of composing them in parallel to obtain a sigma protocol to prove and :
Version 1 of the protocol is as described above; version 2 is the same except both instances use the same challenge (i.e., ). One of these versions has special soundness but not necessarily HVZK; the other has HVZK but not necessarily special soundness. Which is which, and why?
-
Prove claim 19.3.8: Construction 19.3.7 has special soundness and is HVZK.
-
Describe a sigma protocol for the following problem, and prove that it satisfies the usual properties: Alice has generated an El Gamal encryption under a public key ; she wants to convince a verifier that the ciphertext decrypts to either or . Assume that Alice knows the randomness used to encrypt the ciphertexts but not the El Gamal private key.
-
h Suppose is an RSA modulus, and is a prime exponent such that . Consider the following sigma protocol, in which the prover wants to convince the verifier that it knows an -th root of a public value .
Note that neither the prover nor verifier need to know the factorization of . Prove that the protocol satisfies special soundness and honest-verifier zero knowledge.
Given two accepting transcripts and with , use Bezout's theorem to compute integers and such that , and take .
-
In the Schnorr signature scheme, the signer samples a value uniformly. Show that if an adversary obtains signatures of two different messages signed using the same , they can compute the private signing key.
-
Digital Signature Algorithm (DSA) is a standard signature scheme defined using modular arithmetic. In the following, and are distinct primes and is a fixed integer. All three values are publicly known parameters. is a hash function with output in .
The verification algorithm is not relevant for this exercise.
-
Suppose an adversary observes a signature on message and another signature on message , where the same value was chosen for both signatures. Show how the adversary can efficiently calculate .
-
Given the same circumstances as part (a), show how the adversary can efficiently calculate .
-
-
The Schnorr signing algorithm computes .
-
Show that the scheme is no longer a secure signature scheme if is computed as .
-
Show that the scheme is no longer a secure signature scheme if is computed as .
-
Suppose we restrict the scheme to sign messages from the cyclic group , and compute as . Multiplication here refers to the group operation in . Show that the resulting scheme is not a secure signature scheme.
-
Chapter Notes
Schnorr's identification protocol and signature scheme were proposed by Claus Schnorr in 1989 [198]. The abstraction of sigma protocols is due to Cramer [74]; Damgård [80] provides an accessible overview. Maurer [156] shows a unified way to derive many sigma protocols from the literature. The security of Schnorr signatures in the random oracle model was analyzed by Pointcheval and Stern [183].
The transformation in exercise 19.1 was described by Barthe, Hedin, Zanella-Béguelin, Grégoire, and Heraud [10].
Construction 19.3.4 is due to Cramer, Damgård, and Schoenmakers [75]. The sigma protocol for equality of discrete logarithms is due to Chaum and Pederson [64]. Exercise 19.7 is due to Okamoto [174], while exercise 19.8 is due to Camenisch and Shoup [57]. The protocol to prove knowledge of -th roots under an RSA modulus in exercise 19.15 is due to Guillou and Quisquater [118].
The Fiat-Shamir construction of noninteractive proofs is from [101]. The forking lemma (lemma 19.4.2) is due to Feige, Fiat, and Shamir [99], with later and more detailed analyses by Pointcheval and Stern [183] and Bellare and Neven [25].