key generation proof #96
Conversation
| #[derive(Clone, Copy, Debug)] | ||
| pub struct Coordinate<F> | ||
| where | ||
| F: PrimeField<Repr = [u8; 32]>, |
There was a problem hiding this comment.
Is it possible to avoid placing restrictions on Repr? I was able to drop such restrictions in the signature example, please see examples/signature.rs.
| where | ||
| F: PrimeField<Repr = [u8; 32]>, | ||
| { | ||
| pub z_g: Coordinate<F>, |
There was a problem hiding this comment.
I was a bit confused about the use of z_g, z_pk, and z_sk. Are these needed?
| @@ -0,0 +1,425 @@ | |||
| //! Demonstrates how to use Nova to produce a recursive proof of the correct execution of | |||
| //! iterations of the key generation function. | |||
There was a problem hiding this comment.
I had a basic question about this example: What exactly is this proving? It seems like it is proving the knowledge of a set of secret keys? Does it make sense to turn this into proving knowledge of (one or more) secret keys such that their public keys are in a set of known public keys? Without such a restriction, it seems like the prover can just make up a set of secret keys and prove their knowledge, right?
There was a problem hiding this comment.
The use case for this example was taken from Proof of private key ownership. Are you describing a membership proof? Changing the example to a better one is fine with me.
There was a problem hiding this comment.
Yes, the example is fine. But is the example making the claimed public key a public output, so the verifier can check if it is the same as some designated/well-known public key? If not, the proven statement isn't very useful, right? Because proving the knowledge of some secret key that corresponds to some public key isn't hard, right?
There was a problem hiding this comment.
From the web page the example is a proof of identity. The public key is a public output that the verifier would check against a public key that could be retrieved from a DID document for example. It may be the case that the example in isolation is not useful. The referenced web page for example uses two proofs for an identity-linked proof of knowledge.
- we have one function which proves knowledge of a secret
- we have another function which checks that a given public key was derived from a given private key
* refactor r1cs::is_valid and provider::cpu_best_multiexp (microsoft#240) * refactor: r1cs is valid * refactor: msm parallel iteration * chore: fix clippy * Expose verifier key's digest with a trait (microsoft#243) * Expose verifier key's digest with a trait * run cargo fmt and clippy * use rayon to compute in parallel (microsoft#245) * Eliminate unnecessary wraps & use alloc_infallible (microsoft#246) * feat: Refactor unnecessary wraps in error handling Revised operations unnecessarily wrapping their return in a Result. * refactor: Refactor to use infallible allocation across application - Switched the allocation method to the infallible version, `AllocatedNum::alloc_infallible`, in multiple units (`poseidon.rs`, `bellpepper/mod.rs`, `utils.rs`, `circuit.rs`, `lib.rs`, `nifs.rs`). This removed the need for multiple error checks and reduced usage of `Result` return types. * release 0.27.0 (microsoft#247) * Reduce hashing costs with a power polynomial in ppsnark (microsoft#248) * use eq polynomial emulated via power polynomial, to reduce hashing costs * update version * add missing file * Optimize ppsnark (microsoft#250) * update ppsnark to be more efficient * remove * clippy * use padded * rayon * additional rayon * update version --------- Co-authored-by: ashWhiteHat <phantomofrotten@gmail.com> Co-authored-by: Jiaxing Zhao <mrls1219@mail.ustc.edu.cn> Co-authored-by: Srinath Setty <srinath@microsoft.com>
|
Closing this as Nova's interfaces have diverged substantially from what is used here. Please reopen with an updated PR. |
Algorithm taken from Proof of private key ownership. Zokrates has the notation of private input. Is the input private by default for Nova?