w3f / apk-proofs

Apache License 2.0
56 stars 19 forks source link

Verifier uses FS randomness #10

Closed swasilyev closed 3 years ago

swasilyev commented 3 years ago

I had to seed merlin rng with a noop rng.

  1. I guess this is what we want?
  2. Asking again, are there environments where verifier could benefit of provided randomness?
  3. Is there some usable randomness in Substrate/runtime/whatever

∞ isaacs/github#750 is a fucking shame

swasilyev commented 3 years ago

Is it secure at all? Prover knows the randomizer before it computes the proofs! At least should hash the proofs in

swasilyev commented 3 years ago

Is it fixed now? See also https://github.com/w3f/apk-proofs/commit/66e0f3ae43497ff9a52070644367106509e1898b

burdges commented 3 years ago

I know I pointed you towards this dummy rng approach originally, but..

A priori, we want a transcript to evolve when we pull data from it, but merlin designed built_rng specifically to avoid doing so, because it's meant to provide challenges for schnorr-like proofs.

If you want a Rng built from the transcript then maybe put these into the extension trait:

    pub fn fiat_shamir_rng<R: ::rand_core::SeedableRng>(&self, label: &'static [u8]) -> R {
        let mut buf = R::Seed;
        self.challenge_bytes(label, buf.as_mut());
        R::from_seed(buf)
    }

    pub fn fiat_shamir_chacharng(&self, label: &[u8]) -> ::rand_chacha::ChaChaRng {
        self.fiat_shamir_rng::<::rand_chacha::ChaChaRng>(label)
    }

The other alternative is to write more specialized routines for sampling from the transcript. If one wants to be crazy then one can plug into https://rust-random.github.io/rand/rand_core/block/trait.BlockRngCore.html directly