docknetwork / crypto Goto Github PK

I am compiling some code I added to a custom crate (here called xxxx).
It has been compiling fine until I rebased to f5b61cd.
Now I am getting several errors like:

error[E0308]: arguments to this function are incorrect
   --> xxxx/src/proofsystem_algo.rs:102:20
    |
102 |     statements.add(PoKSignatureBBSG1Stmt::new_statement_from_params(
    |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    |
note: expected struct `bbs_plus::setup::SignatureParamsG1`, found struct `SignatureParamsG1`
   --> xxxx/src/proofsystem_algo.rs:103:9
    |
103 |         sig_params.clone(),
    |         ^^^^^^^^^^^^^^^^^^
    = note: struct `SignatureParamsG1` and struct `bbs_plus::setup::SignatureParamsG1` have similar names, but are actually distinct types
note: struct `SignatureParamsG1` is defined in crate `bbs_plus`
   --> /Users/me/ws/OLABS/github-docknetwork-crypto-NEW-f5b61cd/bbs_plus/src/setup.rs:343:1
    |
343 | impl_sig_params!(SignatureParamsG1, G1Affine, G1, G2Affine, G2);
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
note: struct `bbs_plus::setup::SignatureParamsG1` is defined in crate `bbs_plus`
   --> /Users/me/.cargo/registry/src/github.com-1ecc6299db9ec823/bbs_plus-0.11.0/src/setup.rs:343:1
    |
343 | impl_sig_params!(SignatureParamsG1, G1Affine, G1, G2Affine, G2);
    | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    = note: perhaps two different versions of crate `bbs_plus` are being used?

This might be related to a cargo issue: rust-lang/cargo#11490

Note, the top-level Cargo.lock file does have two versions of bbs_plus in it:

name = "bbs_plus"
version = "0.11.0"
dependencies = [
 "ark-bls12-381",
 "ark-ec 0.4.1",
 "ark-ff 0.4.1",
 "ark-serialize 0.4.1",
 "ark-std 0.4.0",
 "blake2",
 "digest 0.10.6",
 "dock_crypto_utils 0.9.0",
 "rayon",
 "rmp-serde",
 "schnorr_pok 0.9.0",
 "serde",
 "serde_json",
 "serde_with",
 "zeroize",
]

[[package]]
name = "bbs_plus"
version = "0.11.0"
source = "registry+https://github.com/rust-lang/crates.io-index"
checksum = "f9007b7a0f5ce3fe4b22e3acbbd05d7fbb13e722cb6380254ed0ae3684764602"
dependencies = [
 "ark-ec 0.4.1",
 "ark-ff 0.4.1",
 "ark-serialize 0.4.1",
 "ark-std 0.4.0",
 "digest 0.10.6",
 "dock_crypto_utils 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "rayon",
 "schnorr_pok 0.9.0 (registry+https://github.com/rust-lang/crates.io-index)",
 "serde",
 "serde_with",
 "zeroize",
]

I also note that some of the docknetwork/crypto crate's Cargo.toml include a path to other crates in the repo while others do not.
For example: see proof_system compared to bbs_plus below.

The following output is editted and formatted for readability:

find . -type f -exec grep --color=auto -nH --null -e "version =" \{\} +

./compressed_sigma/Cargo.toml�17:dock_crypto_utils = { version = "0.9.0", default-features = false }

./test_utils/Cargo.toml�9:bbs_plus = { version = "0.11.0", default-features = false }
./test_utils/Cargo.toml�10:schnorr_pok = { version = "0.9.0", default-features = false }
./test_utils/Cargo.toml�11:vb_accumulator = { version = "0.12.0", default-features = false }
./test_utils/Cargo.toml�18:proof_system = { version = "0.18.0", default-features = false, path = "../proof_system" }

./saver/Cargo.toml�20:dock_crypto_utils = { version = "0.9.0", default-features = false }

./proof_system/Cargo.toml�21:bbs_plus = { version = "0.11.0", default-features = false }
./proof_system/Cargo.toml�22:schnorr_pok = { version = "0.9.0", default-features = false }
./proof_system/Cargo.toml�23:vb_accumulator = { version = "0.12.0", default-features = false }
./proof_system/Cargo.toml�24:dock_crypto_utils = { version = "0.9.0", default-features = false }
./proof_system/Cargo.toml�25:saver = { version = "0.9.0", default-features = false }

./delegatable_credentials/Cargo.toml�20:dock_crypto_utils = { version = "0.9.0", default-features = false }
./delegatable_credentials/Cargo.toml�23:schnorr_pok = { version = "0.9.0", default-features = false }

./schnorr_pok/Cargo.toml�21:dock_crypto_utils = { version = "0.9.0", default-features = false, path = "../utils" }

./vb_accumulator/Cargo.toml�25:schnorr_pok = { version = "0.9.0", default-features = false, path = "../schnorr_pok" }
./vb_accumulator/Cargo.toml�26:dock_crypto_utils = { version = "0.9.0", default-features = false, path = "../utils" }

./benches/Cargo.toml�9:bbs_plus = { version = "0.11.0", default-features = false, path = "../bbs_plus" }
./benches/Cargo.toml�10:schnorr_pok = { version = "0.9.0", default-features = false, path = "../schnorr_pok" }
./benches/Cargo.toml�11:vb_accumulator = { version = "0.12.0", default-features = false, path = "../vb_accumulator" }
./benches/Cargo.toml�12:test_utils = { version = "0.1.0", default-features = false, path = "../test_utils" }

./secret_sharing_and_dkg/Cargo.toml�21:dock_crypto_utils = { version = "0.9.0", default-features = false }
./secret_sharing_and_dkg/Cargo.toml�22:schnorr_pok = { version = "0.9.0", default-features = false }

./bbs_plus/Cargo.toml�21:schnorr_pok = { version = "0.9.0", default-features = false, path = "../schnorr_pok" }
./bbs_plus/Cargo.toml�22:dock_crypto_utils = { version = "0.9.0", default-features = false, path = "../utils" }

One last thing. `saver/Cargo.toml' seems to indicate the need for paths:

./saver/Cargo.toml�33:#proof_system = { path = "../proof_system" }
./saver/Cargo.toml�34:#bbs_plus = { path = "../bbs_plus" }

Bottom line: the rust compiler can't tell the difference between what is in the local registry and what is available via path.

I am assuming that is my problem, but maybe not.

Thank you,
H

> cargo --version
cargo 1.67.1 (8ecd4f20a 2023-01-10)
> rustc --version
rustc 1.67.1 (d5a82bbd2 2023-02-07)

Hi I'm 0xvon. I'd like to compare some algorithms for blind signatures and its SPKs.
That library especially seems to be so helpful for the performance analysis. However, I failed running ps_proof benchmark due to an error.

Issue Description

When I run the benchmark of ps signature's SPK whis that command:

cargo bench --bench=ps_proof

The error causes with that message.

...
Creating proof for Proof-of-knowledge of signature and corresponding multi-message of size 4/Reveali... #4
                        time:   [6.5353 ms 6.6979 ms 6.8960 ms]
                        change: [-3.8391% +0.2687% +4.7065%] (p = 0.89 > 0.05)
                        No change in performance detected.
Found 12 outliers among 100 measurements (12.00%)
  1 (1.00%) high mild
  11 (11.00%) high severe
thread 'main' panicked at benches/benches/ps_proof.rs:150:14:
called `Result::unwrap()` on an `Err` value: MessageInputError(NoMessagesProvided)
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: ps_proof::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: bench failed, to rerun pass `-p benches --bench ps_proof`

cause

I guess the function UnpackedBlindedMessages::new() doesn't allow empty messages.

solution

I propose two directions to fix this issue. Can you please give me some comments for it?
If you don't take time to fix that quickly, I can help.

1. Fix benches to skip for empty messages
2. Fix impl to allow empty messages

Could a C interface be provide (like is done for Hyperledger Ursa)?
That would make it possible to use the crypto library from other languages.

Hi

There is a bug in disjoint_witness_equalities, which results in not ensuring disjoint lists. The problem is that, when merging current with an overlapping list here, this may introduce a transitive equality with a list that we've already skipped and not merged.

The result is that verify fails, even though the given witnesses do meet all requirements.

A simple solution is to run the algorithm repeatedly until the number of lists does not change.

I'm not in a position to make a pull request, I'm afraid, but I can offer the following to aid with reproducing and testing a fix.

        let input_eqs =
              vec![
                  vec![(0, 1), (2, 0)],
                  vec![(0, 5), (1, 2)],
                  vec![(0, 5), (3, 0)],
                  vec![(1, 3), (5, 0)],
                  vec![(1, 2), (4, 0)],
              ];

        let current_result =
              vec![
                  vec![(0, 1), (2, 0)],
                  vec![(1, 3), (5, 0)],
                  vec![(0, 5), (1, 2), (4, 0)],  // NOTE: (0,5) is in both of the last
                  vec![(0, 5), (3, 0)]           // two, so these are not disjoint
              ];

        let one_correct_result =
              vec![
                vec![(0, 1), (2, 0)],
                vec![(0, 5), (1, 2), (3, 0), (4, 0)],
                vec![(1, 3), (5, 0)]
            ];

        // This passes
        check!(input_eqs.clone(), current_result);

        // This fails
        check!(input_eqs, one_correct_result);

Hi 👋 I am still admiring your work!

I am wondering about the terminology of the witness and its "implementation".

From the docs:

Witness - Private data that needs to be kept hidden from the verifier. This can be the messages/attributes that are not being disclosed, the signature itself, the accumulator member, accumulator witness. Every witness corresponds to some Statement.

So:

• Is the witness the actual secret value, or is it some wrapper around it, e.g., a commitment (or rather, the value commited to and opening of said commitment)?

And, for two statements (e.g. for POKS and set membership), the witnesses are distinct objects in code, but "reference" the same value. This equality of the witnesses is what we prove with witnessEquality in the metaStatements.

• This equality proof is done via Schnorr, as far as I understand, where we prove knowledge of the commited value (the witness?) and the opening for the commitment (also part of the witness then?) that is used in the particular other proofs (POKS, set membership, etc). What is part of the witness here?

I feel that the term witness is used quite heterogeneously on the Web - and, FWIW, Rannenberg, Camenisch and Sabouri don't even mention that term in their work on Attribute-based Credentials for Trust.
I'd appreciate if you could clarify your understanding of the term witness and how it relates to the composite proofs.

Cheers
Christoph

Hi @lovesh , thank you for reviewing my previous PR.

1. Abstract

In this issue, let me report the benchmark result for BBS+ and PS signature.
After this, I'd like to discuss:

• if the result makes sense or not (compared to math theory)
• which algorithm is better (for each cases)
• where we can improve the implementation
• where we can improve the benchmark (to measure more other metrics)

2. Machine Spec (Local)

• Macbook Pro 13-inch
• M1 2020
• 16GB Memory
• macOS Ventura 13.5.2
• 512GB Storage

3. Benchmark Steps

git clone [email protected]:docknetwork/crypto.git && cd crypto
cargo bench --bench=bbs_plus_signature
cargo bench --bench=bbs_plus_proof
cargo bench --bench=ps_signature
cargo bench --bench=ps_proof

4. Metrics

As the benchmark, I plotted these 4 metrics with changing the number of messages(attributes) for the statement.

• GenSig Time
• VerSig Time
• GenProof Time
• VerProof Time
• (GenKey Time)
• (SigSize)
• (ProofSize)

5. Benchmark Results

I'll show 2 table and 4 graphs to compare the performance.
*the first row's label means num of messages(attributes)
*the unit is ms

• $2~ $5 changes the number of revealed messages

Table 5-1: Metrics Result for BBS+

Table 5-2: Metrics Result for PS

And these graphs reflects the table.

Graph 5-1: Performance for GenSig/VerSig

Graph 5-2: Performance for GenProof/VerProof

6. Discussion

The result tells them:

• PS is better for GenSig, but BBS+ is better for VerSig, GenProof and VerProof.
• GenSig time takes less than 1ms and looks almost constant (on PS).
• VerSig time on PS takes almost twice than on BBS+.
• GenProof time is positive for number of blinding messages (on both BBS+/PS).
• VerProof time is constant for any number of blinding messages (on both BBS+/PS).

I'll also provide a theoretical computation cost for each algorithm.
*L: message length, d: open length, d’: hidden length, R: generate random, E: exponation, P: pairing
*(XX) means time for message which has 30 attributes

Table 6-1. Computation Cost Theory for BBS+/PS

In my opinion:

• The result matches the theory.
  • PS signature looks less computation than BBS+ one, but PS mainly executes the multiplications on G2, which takes more time than G1.
• PS signature needs much less computation on GenSig, but needs much more computation on GenKey instead.
• BBS+ seems better because we mainly have less computation power in VerSig/GenProof/VerProof, which processes on the holder/verifier's mobile devices.

If you read SoftSpokenOT: Communication--Computation Tradeoffs in OT Extension, we learn the KOS is deprecated. Softspoken OT is considered more secure and requires one less back and forth.

Hi! 👋
Thank you for your great work! (Especially all the comments in the code!)

I was looking at how the composite proof system works, especially focusing on BBS+ with LegoGroth16.
From [1] I gather that everything is kinda glued together via Schnorr. Is there a formal description on how this works? I am really curious about this...

I recently looked into combining BBS+ and Bulletproofs (with Hyperledger Ursa) but got stuck at exactly that point...
Could not think of how to prove the usage of the witness from the BBS+ in the range proof (...still learning...).
As a side question: Would there be anything blocking the combination of the two from the get-go or could one "plug in" Bulletproofs (to avoid the trusted setup) using the same approach to composite proofs (i.e. adding to this repo)?

Cheers
Christoph

[1] https://github.com/docknetwork/crypto/blob/main/proof_system/src/sub_protocols/bound_check_legogroth16.rs

We check if witnesses.len() > j, but j < witnesses.len() by definition so this is trivially true.

The shamir methods fail running the following tests

• Threshold can be specified as 1, which doesn't matter in a threshold setting
• Duplicate share id's
• Share id of zero.

#[test]
    #[should_panic]
    fn invalid_case() {
        let mut rng = StdRng::seed_from_u64(0u64);
        // Shouldn't allow sharing threshold of 1 but succeeds
        let (secret, shares, poly) = deal_random_secret::<_, Fr>(&mut rng, 1, 1).unwrap();
        assert_eq!(shares.0.len(), 1);
        assert_eq!(secret, shares.0[0].share);
        assert_eq!(poly.degree(), 0);
    }

    #[test]
    fn invalid_recombine_dup_id() {
        let mut rng = StdRng::seed_from_u64(0u64);
        let (secret, mut shares, poly) = deal_random_secret::<_, Fr>(&mut rng, 3, 3).unwrap();
        shares.0[1].id = 1;
        // Should fail because of duplicate share id. Duplicate share id's result in lagrange divide by zero
        assert!(shares.reconstruct_secret().is_err());
        let secret1 = shares.reconstruct_secret().unwrap();
        assert_eq!(secret, secret1);
    }


    #[test]
    fn invalid_recombine_zero_id() {
        let mut rng = StdRng::seed_from_u64(0u64);
        let (secret, mut shares, poly) = deal_random_secret::<_, Fr>(&mut rng, 2, 3).unwrap();
        shares.0[0].id = 0;
        // Should fail because of zero share id. Zero id results in lagrange multiply by zero
        // which nullifies the share
        // assert!(shares.reconstruct_secret().is_err());
        let secret1 = shares.reconstruct_secret().unwrap();
        // shouldn't happen
        assert_eq!(secret1, shares.0[0].share * lagrange_basis_at_0::<Fr>(&[0, 2], 0));
    }

I am new to zero-knowledge proofs and would like to ask how the contents of the delegatable_credentials/ directory can be combined with BBS+signatures. Can a BBS+ signature be a delegatable credential？