Minor cleanup

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

Author: lovesh

.DS_Store

@@ -7,4 +7,7 @@ Cargo.lock
 # These are backup files generated by rustfmt
 **/*.rs.bk
 
+# IDE specific
 .idea
+
+.DS_Store

.gitignore

@@ -12,7 +12,7 @@ Library providing privacy enhancing cryptographic primitives.
 2. [BBS+ signature](./bbs_plus) for anonymous credentials. Based on the paper [Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited](https://eprint.iacr.org/2016/663)
 3. [Dynamic accumulators, both positive and universal](./vb_accumulator). Based on the paper [Dynamic Universal Accumulator with Batch Update over Bilinear Groups](https://eprint.iacr.org/2020/777)
 4. [Proof system](./proof_system) that combines above primitives for use cases like prove knowledge of a BBS+ signature and the corresponding messages and the (non)membership of a certain message in the accumulator.
-5. [Verifiable encryption](./saver) using [SAVER](https://eprint.iacr.org/2019/1270) paper. This is PoC implementation.
+5. [Verifiable encryption](./saver) using [SAVER](https://eprint.iacr.org/2019/1270).
 6. [Compression and amortization of Sigma protocols](./compressed_sigma). This is PoC implementation.
 
 ## Build
@@ -43,4 +43,4 @@ Some tests also print time consumed by the operations, run `cargo test --release
 
 ## WASM wrapper
 
-A WASM wrapper has been created over this repo [here](https://github.com/docknetwork/crypto-wasm). The wrapper is then used to create [this Typescript library](https://github.com/docknetwork/crypto-wasm-ts) which is more ergonomic than using the wrapper as the wrapper contains free floating functions.
+A WASM wrapper has been created over this repo [here](https://github.com/docknetwork/crypto-wasm). The wrapper is then used to create [this Typescript library](https://github.com/docknetwork/crypto-wasm-ts) which is more ergonomic than using the wrapper as the wrapper contains free floating functions.

README.md

@@ -968,11 +968,15 @@ fn proof_spec_modification() {
 
 #[test]
 fn verifier_local_linkability() {
-    // A verifier wants to attach a unique identifier to a prover without either learning anything unintended (by prover) from the prover's signature nor can that unique identifier be used by other verifiers to identify the prover,
-    // eg. a seller (as a verifier) should be able to identify repeat customers (prover) by using a unique identifier but he should not be able to share that unique identifier with other sellers using their own identifier for that prover.
-    // This is done by making the prover go through a one-time registration process with the verifier by creating a Pedersen commitment to some value in the signature(s) which the verifier persists, lets call it registration commitment.
-    // At each subsequent proof, the prover resends the commitment with the proof that commitment contains message from the prover's signature (prover had persisted commitment and randomness) and the verifier checks that the commitment is
-    // same as the one during registration. The registration commitment serves as an identifier.
+    // A verifier wants to attach a unique identifier to a prover without either learning anything unintended (by prover)
+    // from the prover's signature nor can that unique identifier be used by other verifiers to identify the prover,
+    // eg. a seller (as a verifier) should be able to identify repeat customers (prover) by using a unique identifier
+    // but he should not be able to share that unique identifier with other sellers using their own identifier for that prover.
+    // This is done by making the prover go through a one-time registration process with the verifier by creating a
+    // Pedersen commitment to some value in the signature(s) which the verifier persists, lets call it registration commitment.
+    // At each subsequent proof, the prover resends the commitment with the proof that commitment contains message
+    // from the prover's signature (prover had persisted commitment and randomness) and the verifier checks that the
+    // commitment is same as the one during registration. The registration commitment serves as an identifier.
 
     // Following shows a prover interacting with 2 different verifiers and creating and using 2 different registration commitments, 1 at each verifier
 

proof_system/tests/bbs_plus_and_accumulator.rs

@@ -79,6 +79,7 @@ mod protocol_1 {
     }
 
     /// `r` is the randomness used during the encryption
+    #[allow(dead_code)]
     pub fn create_proof<E, C, R>(
         circuit: C,
         v: E::Fr,
@@ -106,6 +107,7 @@ mod protocol_1 {
         Ok(proof)
     }
 
+    #[allow(dead_code)]
     pub fn verify_proof<E: PairingEngine>(
         pvk: &PreparedVerifyingKey<E>,
         proof: &Proof<E>,
@@ -138,6 +140,7 @@ mod protocol_2 {
     use crate::encryption::CiphertextAlt;
 
     /// `r` is the randomness used during the encryption
+    #[allow(dead_code)]
     pub fn create_proof<E, C, R>(
         circuit: C,
         v: E::Fr,
@@ -161,6 +164,7 @@ mod protocol_2 {
         Ok(proof)
     }
 
+    #[allow(dead_code)]
     pub fn verify_proof<E: PairingEngine>(
         pvk: &PreparedVerifyingKey<E>,
         proof: &Proof<E>,