filecoin-project / bls-signatures Goto Github PK

Might be worth waiting until this is more stable

• algorand/pairing-plus#13
• algorand/pairing-plus#14
• algorand/bls_sigs_ref#5
• algorand/bls_sigs_ref#4

Under srv/api.rs we don't encode responses from the hub.

https://github.com/Layer-N/nord/blob/master/srv/src/api.rs#L114-L118

Hey, what is the source of the test vectors in tests/data.json? :)

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?

Right now, the "fallback" duplicate check (when blst is disabled) is has a n^2 runtime. The blst version is using a red/black tree and has a log(n) runtime.

I'd consider:

1. At a minimum, making the fallback have a log(n) runtime (e.g., use BTreeSet).
2. Even better, use a HashSet for both. The rust HashSet is pretty damn fast and avoids hashing entirely for small sets, IIRC, so we shouldn't have any issues there.

Would it be possible to make the circle/bot update submodule reference in https://github.com/filecoin-project/go-bls-sigs on a new release made here?

Is the signature scheme implemented based on zk-snark?

As brought up by @laser we should improve the FFI api, to expose things like error messages in all cases needed.

The PrivateKeys created with bls-signatures do not implement .zeroize() (see Zeroize) to ensure dropped values do not contain information after they are out scope, and sensistive information cannot be accessed.

Is there a possibility this could be implemented for PrivateKey?

title

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

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

The fork of the pairing library we use currently is outdated, and needs porting the hashing to the curve code on the latest version of master. This will likely improve performance considerably.

Currently we just panic, not good!

I think swapping between g1 & g2 for pk & signature isn't supported. Is there any plan to support it & make it configurable?

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))

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.

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);