Setting
Definition
Definition: Proof of knowledge
A protocol is a proof of knowledge with knowledge error if there exists an extractor such that for all (malicious, ppt) provers and all , and the extractor has expected running time at most
where denotes that gets Oracle Access to the function (which returns the next message sends when run with input , randomness , and after having received messages ).
Todo
Not sure that this is the best definition we can find for this. Also, should specify what the probability for runtime and success is over. Also: non-1 success rate? (e.g., what if commitment is broken?).
Knowledge error
The knowledge error is usually the inverse of challenge space, . Intuitively, that makes sense: if the prover guesses the challenge correctly, winning the protocol is not difficult anymore. Indeed, if the protocol is ZK, the prover would just run the honest verifier simulator and hope that the actual verifier happens to choose the same challenge). So it’s trivial to set up a prover that can win the protocol with probability without any knowledge of the witness, so we can never hope to extract anything from that prover. For any prover that does better than , the above definition says we can extract (using runtime relative to how much better than the prover is).
A simplified toy definition
The following definition is not really useful in practice, but allows for simplified proofs. For this definition, we assume for simplicity that the prover has probability 1 to convince the honest verifier.
Definition: toy definition of proof of knowledge
Warning: this definition does not actually give any useful guarantees in practice, it’s just a simplification so that we can illustrate some security proofs.
Typical extractor outline
Consider a protocol of the following form (e.g., Graph Isomorphism Protocol, Quadratic Residue Protocol, 3-Colorable Protocol)
Protocol template
- Announcement: prover sends some random value
- Challenge: The verifier chooses a random challenge (from a small challenge space )
- Response: The prover sends some response
- The verifier verifies some equation.
The extractor for (malicious) prover typically works in two steps:
- Find two accepting transcripts, , with (but the same announcement ) by feeding the prover with different inputs.
- Compute a witness from the two transcripts (cf. Special Soundness).
Concretely:
Extractor
- tries to find two accepting transcripts :
- chooses randomness for
- queries to receive the prover’s announcement
- queries for random challenges to receive a responses , and hopes that in that process, it eventually finds such that are both accepting responses according to the honest verifier algorithm.
- After a while, may give up and try a different (the details are tedious).
- computes from
- This step highly depends on the concrete protocol.
If we’re in the A simplified toy definition scenario, then the extractor only ever checks two challenges and both of them will yield accepting responses. In other settings, intuitively, For a prover that may not answer all challenges correctly always (but convinces the verifier with probability ), then may have to search for accepting responses longer.
Resources
- Bellare, Goldreich: On Defining Proofs of Knowledge