[❄] s/compute_randomness_beacon/vrf_security_check

compute_randomness_beacon was too abstract.

Author: LLFourn

schnorr_fun/src/frost/chilldkg/certpedpop.rs

@@ -168,7 +168,7 @@ impl SecretShareReceiver {
             .encryption_keys()
             .map(|(_, encryption_key)| encryption_key)
             .chain(contributor_keys.iter().cloned())
-            .collect::<BTreeSet<_>>(); // dedupe as some contributers may have also be receivers
+            .collect::<BTreeSet<_>>(); // dedupe as some contributors may also be receivers
 
         for cert_key in cert_keys {
             match certificate.get(&cert_key) {
@@ -436,10 +436,10 @@ mod test {
                 .expect("CertifiedKeygen should be valid");
 
             // Compute randomness beacon from the VRF outputs
-            let randomness = output.certified_keygen.compute_randomness_beacon(sha2::Sha256::default());
+            let randomness = output.certified_keygen.vrf_security_check(sha2::Sha256::default());
 
             // Verify the randomness is deterministic
-            let randomness2 = output.certified_keygen.compute_randomness_beacon(sha2::Sha256::default());
+            let randomness2 = output.certified_keygen.vrf_security_check(sha2::Sha256::default());
             assert_eq!(randomness, randomness2);
 
             // Verify we have the expected number of VRF certificates

schnorr_fun/src/frost/chilldkg/certpedpop/certificate.rs

@@ -254,18 +254,23 @@ pub mod vrf_cert {
         ///
         /// ## Security
         ///
-        /// This is secure because from the view of the honest party the
-        /// certpedpop acts as a secure coin tossing protocol, where if no
-        /// parties controlled my the adversary **do not** abort the output will
-        /// be uniformly distributed. Observe that:
+        /// If no parties controlled by the adversary abort, the output will
+        /// be uniformly distributed. The VRF outputs effectively act as a "randomness beacon" -
+        /// a source of verifiable randomness that all parties can compute deterministically
+        /// from the certificates. Observe that:
         ///
         /// 1. The malicious party must commit to all the VRF public keys up front.
-        /// 2. The honest party verifies its contribution to the keygen is included (which are always rampled randomly)
-        /// 3. The VRF is over the transcript and every transcript with the honest party can never happen twice (because of #2).
+        /// 2. The honest party verifies its contribution to the keygen is included (which are always sampled randomly)
+        /// 3. The VRF is over the transcript and every transcript with an honest party will always be unique (because of #2).
         /// 4. The honest party's VRF output will be both hidden and uniformly distributed.
-        pub fn compute_randomness_beacon(&self, hasher: impl Hash32) -> [u8; 32] {
-            // BTreeMap already maintains sorted order by key
-            let mut hasher = hasher;
+        /// 5. All honest parties with the same `AggKeygenInput::cert_bytes` will output the same check
+        /// 6. All honest parties with a different `AggKeygenInput::cert_bytes` are statistically likely to output different bytes.
+        ///
+        /// This check is *statistically* secure -- per keygen the attacker only
+        /// has 1/2ⁿ chance of succeeding to collide the checks where `n` is the
+        /// number of bits the honest parties check among each other. **It is up
+        /// to the application to limit the number of attempts the adversary can make.**
+        pub fn vrf_security_check(&self, mut hasher: impl Hash32) -> [u8; 32] {
             for vrf_proof in self.certificate.values() {
                 let gamma = vrf_proof.dangerously_access_gamma_without_verifying();
                 hasher.update(gamma.to_bytes().as_ref());

schnorr_fun/src/frost/chilldkg/encpedpop.rs

@@ -42,7 +42,7 @@ impl Contributor {
     /// has nothing to do with the "receiver" index (the `ShareIndex` of share receivers). If
     /// there are `n` `KeyGenInputParty`s then each party must be assigned an index from `0` to `n-1`.
     ///
-    /// This method return `Self` to retain the state of the protocol which is needded to verify
+    /// This method returns `Self` to retain the state of the protocol which is needed to verify
     /// the aggregated input later on.
     pub fn gen_keygen_input<H, NG>(
         schnorr: &Schnorr<H, NG>,

schnorr_fun/src/frost/chilldkg/simplepedpop.rs

@@ -35,7 +35,7 @@ impl Contributor {
     /// has nothing to do with the "receiver" index (the `ShareIndex` of share receivers). If
     /// there are `n` `KeyGenInputParty`s then each party must be assigned an index from `0` to `n-1`.
     ///
-    /// This method return `Self` to retain the state of the protocol which is needded to verify
+    /// This method returns `Self` to retain the state of the protocol which is needed to verify
     /// the aggregated input later on.
     pub fn gen_keygen_input<H, NG>(
         schnorr: &Schnorr<H, NG>,
@@ -50,7 +50,7 @@ impl Contributor {
     {
         let secret_poly = poly::scalar::generate(threshold as usize, rng);
         let pop_keypair = KeyPair::new_xonly(secret_poly[0]);
-        // XXX The thing that's singed differs from the spec
+        // XXX The thing that's signed differs from the spec
         let pop = schnorr.sign(&pop_keypair, Message::empty());
         let com = poly::scalar::to_point_poly(&secret_poly);