Threshold weak-BB signature and threshold issuance in SyRA

Signed-off-by: lovesh <lovesh.bond@gmail.com>

Author: lovesh

README.md

@@ -30,7 +30,7 @@ Library providing privacy enhancing cryptographic primitives.
 11. [Short group signatures](./short_group_sig/). BB signature and weak-BB signature and their proofs of knowledge based on the papers [Short Signatures Without Random Oracles](https://eprint.iacr.org/2004/171) and [Scalable Revocation Scheme for Anonymous Credentials Based on n-times Unlinkable Proofs](http://library.usc.edu.ph/ACM/SIGSAC%202017/wpes/p123.pdf).
 12. [Keyed-Verification Anonymous Credentials (KVAC)](./kvac). Implements Keyed-Verification Anonymous Credentials (KVAC) schemes.
 13. [SyRA](./syra). Implements sybil resilient signatures to be used for generating pseudonyms for low-entropy credential attributes.
-14. [Verifiable encryption](./verifiable_encryption) using [this paper Verifiable Encryption from MPC-in-the-Head](https://eprint.iacr.org/2021/1704.pdf).
+14. [Verifiable encryption](./verifiable_encryption) using the paper [Verifiable Encryption from MPC-in-the-Head](https://eprint.iacr.org/2021/1704.pdf).
 
 ## Composite proof system
 

bbs_plus/src/threshold/utils.rs

@@ -46,14 +46,7 @@ pub fn compute_R_and_u<G: AffineRepr>(
     phase2: &Phase2Output<G::ScalarField>,
 ) -> (G, G::ScalarField) {
     let R = base.mul(r).into_affine();
-    let mut u = *masked_r * (*e + masked_signing_key_share);
-    for (_, (a, b)) in &phase2.0.z_A {
-        u += a[index_in_output as usize];
-        u += b[index_in_output as usize];
-    }
-    for (_, (a, b)) in &phase2.0.z_B {
-        u += a[index_in_output as usize];
-        u += b[index_in_output as usize];
-    }
+    let u =
+        *masked_r * (*e + masked_signing_key_share) + phase2.0.compute_u(index_in_output as usize);
     (R, u)
 }

oblivious_transfer/src/cointoss.rs

@@ -25,6 +25,7 @@ pub struct Commitments(pub Vec<Vec<u8>>);
 pub struct Party<F: PrimeField, const SALT_SIZE: usize> {
     pub id: ParticipantId,
     pub protocol_id: Vec<u8>,
+    /// Stores shares and salts created by itself to be sent to other parties
     pub own_shares_and_salts: Vec<(F, [u8; SALT_SIZE])>,
     // Following isn't allowed in stable Rust
     // pub own_shares_and_salts: Vec<(F, [u8; 2*SECURITY_PARAM])>,

oblivious_transfer/src/ot_based_multiplication/batch_mul_multi_party.rs

@@ -66,6 +66,8 @@ pub struct ParticipantOutput<F: PrimeField> {
 impl<F: PrimeField, const KAPPA: u16, const STATISTICAL_SECURITY_PARAMETER: u16>
     Participant<F, KAPPA, STATISTICAL_SECURITY_PARAMETER>
 {
+    /// The returned map contains the messages that need to be sent to the parties with corresponding
+    /// key in the map
     pub fn init<R: RngCore>(
         rng: &mut R,
         id: ParticipantId,
@@ -214,6 +216,21 @@ impl<F: PrimeField, const KAPPA: u16, const STATISTICAL_SECURITY_PARAMETER: u16>
     }
 }
 
+impl<F: PrimeField> ParticipantOutput<F> {
+    pub fn compute_u(&self, idx: usize) -> F {
+        let mut u = F::zero();
+        for (_, (a, b)) in &self.z_A {
+            u += a[idx];
+            u += b[idx];
+        }
+        for (_, (a, b)) in &self.z_B {
+            u += a[idx];
+            u += b[idx];
+        }
+        u
+    }
+}
+
 #[cfg(test)]
 pub mod tests {
     use super::*;

oblivious_transfer/src/zero_sharing.rs

@@ -33,6 +33,8 @@ impl<F: PrimeField, const SALT_SIZE: usize> Party<F, SALT_SIZE> {
     /// of 0s whose shares are generated, eg, if `batch_size` is 3, then `a_1, a_2, ..., a_n`,
     /// `b_1, b_2, ..., b_n` and `c_1, c_2, ..., c_n` are generated such that `\sum_{i}(a_{i}) = 0`,
     /// `\sum_{i}(b_{i}) = 0` and `\sum_{i}(c_{i}) = 0`.
+    /// The returned map contains the commitments to be sent to the party with id as the corresponding
+    /// key of the map.
     pub fn init<R: RngCore>(
         rng: &mut R,
         id: ParticipantId,

proof_system/README.md

@@ -26,12 +26,13 @@ and used by the prover and verifier during proof creation and verification respe
 
 A common requirement is to prove equality of certain [`Witness`]s of certain [`Statement`]s. This
 is done by using the [`EqualWitnesses`] meta-statement. For each set of [`Witness`]s (from the same or different [`Statement`]s)
-that need to proven equal, a [`EqualWitnesses`] is created which is a set of witness references [`WitnessRef`].
+that need to proved equal, a [`EqualWitnesses`] is created which is a set of witness references [`WitnessRef`].
 Each [`WitnessRef`] contains the [`Statement`] index and the [`Witness`] index in that [`Statement`] and
 thus uniquely identifies any [`Witness`] across [`Statement`]s. The [`EqualWitnesses`] meta-statement is also
 used to prove predicates over signed messages in zero knowledge, when doing a range-proof over a
 signed message (using BBS+), the [`EqualWitnesses`] will refer [`Witness`]s from `Statement::PoKBBSSignatureG1`
-statement and `Statement::BoundCheckLegoGroth16` statement. Following are some illustrations of [`EqualWitnesses`]
+statement and `Statement::BoundCheckLegoGroth16` statement. Following are some illustrations of [`EqualWitnesses`].
+Technically, this is achieved through Chaum-Pedersen discrete log equality protocol.
 
 ```text
  ┌────────────────────────────┐    ┌──────────────────────────────┐     ┌────────────────────────────┐
@@ -53,7 +54,7 @@ statement and `Statement::BoundCheckLegoGroth16` statement. Following are some i
                         └─────────────────────────────┘                          └────────────────────────────┘
 ```
 
-```
+```rust
    For proving certain messages from 3 BBS+ signatures are equal. Here there 2 sets of equalities,
    1. message A3 from 1st signature, B2 from 2nd signature and C1 from 3rd signature
    2. message B4 from 2nd signature and C5 from 3rd signature
@@ -80,8 +81,7 @@ statement and `Statement::BoundCheckLegoGroth16` statement. Following are some i
                         │ A3 and  B1 are equal        │                          │  A5 and C1 are equal       │
                         └─────────────────────────────┘                          └────────────────────────────┘
 ```
-
-```
+```rust
    For proving certain messages from a BBS+ signature satisfy 2 predicates,
     1) message A3 satisfies bounds specified in statement 2
     2) message A5 has been verifiably encrypted as per statement 3.
@@ -102,12 +102,14 @@ protocols. Each of these protocols are variants of the enum [`SubProtocol`]. [`S
 call other [`SubProtocol`]s, eg [`SaverProtocol`] invokes several [`SchnorrProtocol`]s
 
 Currently supports
-- proof of knowledge of a BBS or BBS+ signature and signed messages
-- proof of knowledge of multiple BBS or BBS+ signature and equality of certain messages
+- proof of knowledge of a BBS or BBS+ or PS signature and signed messages
+- proof of knowledge of multiple BBS or BBS+ or PS signature and equality of certain messages
+- proof of knowledge of multiple BBS or BBS+ or PS signature and inequality of certain messages with public values
 - proof of knowledge of accumulator membership and non-membership
 - proof of knowledge of Pedersen commitment opening.
-- proof of knowledge of BBS or BBS+ signature(s) and that certain message(s) satisfy given bounds (range proof)
-- verifiable encryption of messages in a BBS or BBS+ signature
+- proof of knowledge of BBS or BBS+ or PS signature(s) and that certain message(s) satisfy given bounds (range proof)
+- verifiable encryption of messages in a BBS or BBS+ or PS signature using zk-SNARK based protocol SAVER or
+  MPCitH based TZ-21
 - proof of knowledge of BBS or BBS+ signature(s) and that certain message(s) satisfy given R1CS. The R1CS is generated
   from [Circom](https://github.com/iden3/circom) and the proof system used is [LegoGroth16](https://github.com/lovesh/legogro16).
   LegoGroth16 is similar to Groth16 but in addition to the zero knowledge proof, it provides a Pedersen
@@ -118,6 +120,8 @@ See following tests for examples:
 
 - test `pok_of_3_bbs_plus_sig_and_message_equality` proves knowledge of 3 BBS+ signatures and also that certain
   messages are equal among them without revealing them.
+- test `pok_of_bbs_plus_sig_and_inequality_with_public_value` proves knowledge of a BBS+ signature and also that
+  certain message is not equal to a public value without revealing the message
 - test `pok_of_bbs_plus_sig_and_accumulator` proves knowledge of a BBS+ signature and also that certain messages
   are present and absent in the 2 accumulators respectively.
 - test `pok_of_knowledge_in_pedersen_commitment_and_bbs_plus_sig` proves knowledge of a BBS+ signature and opening
@@ -126,26 +130,29 @@ See following tests for examples:
   a Pedersen commitment.
 - test `verifier_local_linkability` shows how a verifier can link separate proofs from a prover (with prover's
   permission) and assign a unique identifier to the prover without learning any message from the BBS+ signature.
-  Also this identifier cannot be linked across different verifiers (intentional by the prover).
+  Also, this identifier cannot be linked across different verifiers (intentional by the prover).
 - test `pok_of_bbs_plus_sig_and_bounded_message` shows proving knowledge of a BBS+ signature and that a specific
   message satisfies some upper and lower bounds i.e. min <= signed message <= max. This is a range proof.
-- test `pok_of_bbs_plus_sig_and_verifiable_encryption` shows how to verifiably encrypt a message signed with BBS+ such
-  that the verifier cannot decrypt it but still ensure that it is encrypted correctly for the specified decryptor.
+- test `pok_of_bbs_plus_sig_and_verifiable_encryption_using_saver` shows how to verifiably encrypt a message signed with BBS+ and
+  using SAVER protocol such that the verifier cannot decrypt it but still ensure that it is encrypted correctly for the specified decryptor.
+- test `pok_of_bbs_plus_sig_and_verifiable_encryption_using_tz21` shows how to verifiably encrypt a message signed with BBS+ and
+  using TZ21 protocol such that the verifier cannot decrypt it but still ensure that it is encrypted correctly for the specified decryptor.
 - test `pok_of_bbs_plus_sig_with_reusing_setup_params` shows proving knowledge of several BBS+ signatures
   using [`SetupParams`]s. Here the same signers are used in multiple signatures thus their public params
   can be put as a variant of enum [`SetupParams`]. Similarly test
   `pok_of_knowledge_in_pedersen_commitment_and_equality_with_commitment_key_reuse` shows use of [`SetupParams`]
-  when the same commitment key is reused in several commitments and test `pok_of_bbs_plus_sig_and_verifiable_encryption_of_many_messages`
+  when the same commitment key is reused in several commitments and test `pok_of_bbs_plus_sig_and_verifiable_encryption_of_many_messages_using_saver`
   shows use of [`SetupParams`] when several messages are used in verifiable encryption for the same decryptor.
 - For R1CS/Circom, see various tests like using less than, not-equals comparison operators on messages signed with BBS+, proving
   that the preimage of an MiMC hash is the message signed with BBS+, sum of certain signed messages (from same or different signatures)
   is bounded by a given value, etc [here](tests/r1cs). The Circom compiler output and circuits are [here](tests/r1cs/circom).
   The circuits were compiled and tested for BLS12-381 curve.
 
-*Note*: This design is largely inspired from my work at Hyperledger Ursa.
+*Note*: This design is inspired from my work at Hyperledger Ursa.
 
 *Note*: The design is tentative and will likely change as more protocols are integrated.
 
+
 [`Statement`]: https://docs.rs/proof_system/latest/proof_system/statement/enum.Statement.html
 [`MetaStatement`]: https://docs.rs/proof_system/latest/proof_system/meta_statement/enum.MetaStatement.html
 [`EqualWitnesses`]: https://docs.rs/proof_system/latest/proof_system/meta_statement/struct.EqualWitnesses.html

proof_system/src/lib.rs

@@ -24,12 +24,13 @@
 //!
 //! A common requirement is to prove equality of certain [`Witness`]s of certain [`Statement`]s. This
 //! is done by using the [`EqualWitnesses`] meta-statement. For each set of [`Witness`]s (from the same or different [`Statement`]s)
-//! that need to proven equal, a [`EqualWitnesses`] is created which is a set of witness references [`WitnessRef`].
+//! that need to proved equal, a [`EqualWitnesses`] is created which is a set of witness references [`WitnessRef`].
 //! Each [`WitnessRef`] contains the [`Statement`] index and the [`Witness`] index in that [`Statement`] and
 //! thus uniquely identifies any [`Witness`] across [`Statement`]s. The [`EqualWitnesses`] meta-statement is also
 //! used to prove predicates over signed messages in zero knowledge, when doing a range-proof over a
 //! signed message (using BBS+), the [`EqualWitnesses`] will refer [`Witness`]s from `Statement::PoKBBSSignatureG1`
-//! statement and `Statement::BoundCheckLegoGroth16` statement. Following are some illustrations of [`EqualWitnesses`]
+//! statement and `Statement::BoundCheckLegoGroth16` statement. Following are some illustrations of [`EqualWitnesses`].
+//! Technically, this is achieved through Chaum-Pedersen discrete log equality protocol.
 //!
 //! ```text
 //!  ┌────────────────────────────┐    ┌──────────────────────────────┐     ┌────────────────────────────┐
@@ -101,7 +102,8 @@
 //! - proof of knowledge of accumulator membership and non-membership
 //! - proof of knowledge of Pedersen commitment opening.
 //! - proof of knowledge of BBS or BBS+ or PS signature(s) and that certain message(s) satisfy given bounds (range proof)
-//! - verifiable encryption of messages in a BBS or BBS+ or PS signature
+//! - verifiable encryption of messages in a BBS or BBS+ or PS signature using zk-SNARK based protocol SAVER or
+//!   MPCitH based TZ-21
 //! - proof of knowledge of BBS or BBS+ signature(s) and that certain message(s) satisfy given R1CS. The R1CS is generated
 //!   from [Circom](https://github.com/iden3/circom) and the proof system used is [LegoGroth16](https://github.com/lovesh/legogro16).
 //!   LegoGroth16 is similar to Groth16 but in addition to the zero knowledge proof, it provides a Pedersen
@@ -122,16 +124,18 @@
 //!   a Pedersen commitment.
 //! - test `verifier_local_linkability` shows how a verifier can link separate proofs from a prover (with prover's
 //!   permission) and assign a unique identifier to the prover without learning any message from the BBS+ signature.
-//!   Also this identifier cannot be linked across different verifiers (intentional by the prover).
+//!   Also, this identifier cannot be linked across different verifiers (intentional by the prover).
 //! - test `pok_of_bbs_plus_sig_and_bounded_message` shows proving knowledge of a BBS+ signature and that a specific
 //!   message satisfies some upper and lower bounds i.e. min <= signed message <= max. This is a range proof.
-//! - test `pok_of_bbs_plus_sig_and_verifiable_encryption` shows how to verifiably encrypt a message signed with BBS+ such
-//!   that the verifier cannot decrypt it but still ensure that it is encrypted correctly for the specified decryptor.
+//! - test `pok_of_bbs_plus_sig_and_verifiable_encryption_using_saver` shows how to verifiably encrypt a message signed with BBS+ and
+//!   using SAVER protocol such that the verifier cannot decrypt it but still ensure that it is encrypted correctly for the specified decryptor.
+//! - test `pok_of_bbs_plus_sig_and_verifiable_encryption_using_tz21` shows how to verifiably encrypt a message signed with BBS+ and
+//!   using TZ21 protocol such that the verifier cannot decrypt it but still ensure that it is encrypted correctly for the specified decryptor.
 //! - test `pok_of_bbs_plus_sig_with_reusing_setup_params` shows proving knowledge of several BBS+ signatures
 //!   using [`SetupParams`]s. Here the same signers are used in multiple signatures thus their public params
 //!   can be put as a variant of enum [`SetupParams`]. Similarly test
 //!   `pok_of_knowledge_in_pedersen_commitment_and_equality_with_commitment_key_reuse` shows use of [`SetupParams`]
-//!   when the same commitment key is reused in several commitments and test `pok_of_bbs_plus_sig_and_verifiable_encryption_of_many_messages`
+//!   when the same commitment key is reused in several commitments and test `pok_of_bbs_plus_sig_and_verifiable_encryption_of_many_messages_using_saver`
 //!   shows use of [`SetupParams`] when several messages are used in verifiable encryption for the same decryptor.
 //! - For R1CS/Circom, see various tests like using less than, not-equals comparison operators on messages signed with BBS+, proving
 //!   that the preimage of an MiMC hash is the message signed with BBS+, sum of certain signed messages (from same or different signatures)

proof_system/tests/saver.rs proof_system/tests/verifiable_encryption_saver.rs

@@ -17,7 +17,7 @@ use dock_crypto_utils::{expect_equality, serde_utils::ArkObjectBytes};
 use serde::{Deserialize, Serialize};
 use serde_with::{serde_as, Same};
 
-/// Response during step 3 of the Schnorr protocol to prove knowledge of 1 or more discrete logs
+/// Response during step 3 of the Schnorr protocol to prove knowledge of 1 or more discrete logs.
 /// This is called partial because it does not contain the responses for all the witnesses. This is
 /// used when more than one Schnorr protocol is used and some witnesses are to be proved equal among them.
 /// Also useful in case of a single Schnorr protocol if some witnesses are to be proved equal.

proof_system/tests/verifiable_encrytion_tz21.rs proof_system/tests/verifiable_encryption_tz21.rs

@@ -21,15 +21,18 @@ serde_with.workspace = true
 zeroize.workspace = true
 dock_crypto_utils = { version = "0.20.0", default-features = false, path = "../utils" }
 schnorr_pok = { version = "0.20.0", default-features = false, path = "../schnorr_pok" }
+oblivious_transfer_protocols = { version = "0.9.0", default-features = false, path = "../oblivious_transfer" }
+secret_sharing_and_dkg = { version = "0.13.0", default-features = false, path = "../secret_sharing_and_dkg" }
 
 [dev-dependencies]
 blake2.workspace = true
 ark-bls12-381.workspace = true
 serde_json = "1.0"
 rmp-serde = "1.0"
+test_utils = { path = "../test_utils" }
 
 [features]
 default = [ "parallel" ]
-std = [ "ark-ff/std", "ark-ec/std", "ark-poly/std", "ark-std/std", "ark-serialize/std", "dock_crypto_utils/std", "schnorr_pok/std", "serde/std"]
+std = [ "ark-ff/std", "ark-ec/std", "ark-poly/std", "ark-std/std", "ark-serialize/std", "dock_crypto_utils/std", "schnorr_pok/std", "serde/std", "oblivious_transfer_protocols/std", "secret_sharing_and_dkg/std"]
 print-trace = [ "ark-std/print-trace", "dock_crypto_utils/print-trace" ]
-parallel = [ "std", "ark-ff/parallel", "ark-ec/parallel", "ark-poly/parallel", "ark-std/parallel", "rayon", "dock_crypto_utils/parallel", "schnorr_pok/parallel" ]
+parallel = [ "std", "ark-ff/parallel", "ark-ec/parallel", "ark-poly/parallel", "ark-std/parallel", "rayon", "dock_crypto_utils/parallel", "schnorr_pok/parallel", "oblivious_transfer_protocols/parallel", "secret_sharing_and_dkg/parallel" ]

schnorr_pok/src/partial.rs

@@ -7,5 +7,6 @@
 3. An optimized implementation of proof of knowledge of weak-BB signature taken from the paper [Scalable Revocation Scheme for Anonymous Credentials Based on n-times Unlinkable Proofs](http://library.usc.edu.ph/ACM/SIGSAC%202017/wpes/p123.pdf). This does not require the prover to do pairings
 4. Similar to weak-BB, proof of knowledge of BB signature that does not require the prover to do pairings.
 5. A keyed-verification protocol for proving knowledge of weak-BB signature. Here the verifier is assumed to have the secret key and the protocol does not require pairings.
+6. Threshold issuance protocol for weak-BB signatures
 
 <!-- cargo-rdme end -->