Fixes build failures with the benches. Did not look when did the benches go stale, but issues were:

• xorshift rng is no longer allowed
• aggregate now returns a result, which should always be ok in the benchmark (or require retry)

Added a ci run to make sure the benches do not go stale in the future. I'm not really so familiar with circleci so please review carefully. In the last commit I removed the whitespace errors git is nagging about (and my $EDITOR removes automatically).

I can't see xorshift => thread_rng() change being that important since none of the benched blocks includes rng use.

I forget where we previously discussed matters and issues are not enabled on https://github.com/filecoin-project/pairing so I'll raise the issue here.

It's maybe worth basing the hashing-to-the-curve code off the code that gets discussed on the IRTF forum, which I believe to be https://github.com/algorand/bls_sigs_ref/blob/master/rust-impl/ https://github.com/algorand/pairing-plus/tree/master/src

There are some questionable decisions being made there for IRTF process, like using HKDF-SHA2 possibly without the layers of hashing in the best places, but at least the arithmetic gets better discussed. Also, their ff version is outdated and their trait layout is obsoleted by the group crate, but the hashing functionality appears slightly more orthogonal, so maybe we could glue it onto a the more recent zkcrypto paring crate?

I've been getting the following error:

error[E0277]: the trait bound `ChaCha8Rng: rand_core::RngCore` is not satisfied
  --> crypto/src/signature.rs:86:55
   |
86 |         let pk = bls_signatures::PrivateKey::generate(&mut rng);
   |                                                       ^^^^^^^^ the trait `rand_core::RngCore` is not implemented for `ChaCha8Rng`
   |
  ::: /home/hunter/.cargo/registry/src/github.com-1ecc6299db9ec823/bls-signatures-0.10.0/src/key.rs:88:24
   |
88 |     pub fn generate<R: RngCore + CryptoRng>(rng: &mut R) -> Self {
   |                        ------- required by this bound in `bls_signatures::PrivateKey::generate`

error[E0277]: the trait bound `ChaCha8Rng: rand_core::CryptoRng` is not satisfied
  --> crypto/src/signature.rs:86:55
   |
86 |         let pk = bls_signatures::PrivateKey::generate(&mut rng);
   |                                                       ^^^^^^^^ the trait `rand_core::CryptoRng` is not implemented for `ChaCha8Rng`
   |
  ::: /home/hunter/.cargo/registry/src/github.com-1ecc6299db9ec823/bls-signatures-0.10.0/src/key.rs:88:34
   |
88 |     pub fn generate<R: RngCore + CryptoRng>(rng: &mut R) -> Self {
   |                                  --------- required by this bound in `bls_signatures::PrivateKey::generate`

It took me a little while to realize the code I was reading in the repo wasn't the code I was using.

This is fixed when using this line in Cargo.toml:

bls-signatures = { git = "https://github.com/filecoin-project/bls-signatures.git", rev = "807e4326a2a847a059b4202b47340a69c7a4858e" }

Using rand 0.8.4, rand_core 0.6.3, and rand_chacha 0.3.1.

Which variant does this crate use by default? Is there a way to change it?

Variant reference: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-00#section-2.1

Very optional, I don't care if this comes in, but the features in the crate are not additive. This causes issues when a crate that depends on this needs to support each feature.

Also just fixes

cargo c --all-features

or any combination of features, which would fail to compile before. It doesn't indicate that it's using unnecessary dependencies, so I can add a compiler warning if that helps.

Might be worth waiting until this is more stable

• https://github.com/algorand/pairing-plus/pull/13
• https://github.com/algorand/pairing-plus/pull/14
• https://github.com/algorand/bls_sigs_ref/pull/5
• https://github.com/algorand/bls_sigs_ref/pull/4

Update the dependencies to their latest versions. This makes this library requiring at least Rust 1.56.0.

Due to dependencies having updated the version of bitvec they are using, the calls to it changed. In the previous version 0.22 as_buffer returned a reference to the underlying data. This method was removed in version 1.0.0 in favour of making of making the data field public.

A newer version of nightly on CI is needed, due to the minimum supported Rust version 1.56.0.

So far only pairing is migrated.

Blocked currently by

• [x] https://github.com/zkcrypto/bls12_381/issues/67
• [x] migrating blstrs to the new traits, to be able to match

Hello,

I want to merge two multi-signatures whose sets of signatories intersect.

For instance, we have two sets of signatories $A = \{s_1, s_2\}$ and $B = \{s_2, s_3\}$, which respectively produced multi-signatures $\sigma_A$ and $\sigma_B$.

According to this Crypto Stack Exchange post, these two multi-signatures can be merged if we use the aggregated public key $pk = pk_1 + 2 pk_2 + pk_3$.

But how would this translate into code?

• Would the let agg_multisig = bls_signatures::aggregate(&vec![multisig_A, multisig_B]).unwrap(); instruction work as is?
• When calling bls_signatures::verify_messages(&agg_multisig, &messages, &pub_keys), do we have to add several times the public key of signatory 2 in pub_keys? Do we also have to put several times the message of signatory 2 in messages? Would the following work?

let pub_keys = vec![pub_key_1, pub_key_2, pub_key_2, pub_key_3];
let messages = vec![message_1, message_2, message_3];
let valid = bls_signatures::verify(&agg_multisig, &messages, &pub_keys);

Hello,

The rogue public-key attack is a known problem for the BLS signature scheme. In this attack, an adversary can produce a valid aggregate signature for a given message that appears to be made by them and other honest participants. However, I can't seem to find anywhere in the documentation of this project if securities were implemented to preclude this attack.

The following post lists 3 defenses against this kind of attack: https://crypto.stanford.edu/~dabo/pubs/papers/BLSmultisig.html

1. Prove knowledge of the private key. I don't understand fully how this would work, but I assume that it could be achieved by doing a challenge every time a participant signs a message, in order to prove that they indeed own the private key. However, the overhead that must be added to each message because of this solution defeats the purpose of aggregate signatures, which is to have short and fixed-size signatures.
2. Force messages to be distinct, that is, reject all aggregate signatures that contain several individual signatures for the same message. However, this restriction prevents several applications of aggregate signatures (such as the one I'm interested in).
3. Use the modified BLS construction, which is presented in the post above, and which, from my perspective, seems to be the best solution against rogue public-key attacks, because it allows aggregate signatures for the same message without adding any overhead.

Was any of these solutions implemented in this project? It seems that we can aggregate signatures for the same message with this crate, so I don't think that solution 2 was implemented.

Besides, if signatures for the same message can be aggregated, would it be possible to implement in this crate the fast verification technique that is given in the post above?

When all the messages are the same (m_1 = … = m_n) the verification relation reduces to a simpler test that requires only two pairings: e(g_1, sig) = e(pk_1...pk_n, H(m_1))

Say you have a single message, eg a block hash, M as well as a vector of signers S and their BLS signatures SIGS (where each signature in SIGS is a BLS signature on M) if you call aggregate on sigs it will produce an aggregate signature A however calling:

verify_messages(&A, &[M], &S)

will yield false. The only way to use aggregation is to make each signer S sign an individual message (Eg. SIGS[S] = S.sign(M + S)) which rusts in linear validation time. Is there no way to aggregate a set of non-heteromorphic signatures (eg all signatures are on the same message)? Thanks