lovesh / signature-schemes Goto Github PK

Hi Lovesh!

Thank you so much for this crate, I can see that BLS is getting some traction on Rust.
How do you compare your crate and the BLS like crate?

Is your crate production ready? Safe enough to put up in an already existing Blockchain?

These are the expected sizes according to the BLS specification:

• private key: 32 bytes
• public key: 48 bytes
• signature: 96 bytes

When I call to_bytes on each type, I get these sizes:

• private key (SigKey): 48 bytes
• public key (VerKey): 97 bytes
• signature: 192 bytes

Edit: It looks like the sizes match the ones described here, except for the public key which is 97 instead of 96. So I guess this means they are uncompressed. Is there a way to compress them so they match the other sizes?

EntropyRng is deprecated in rand 0.7. Arguments using it should be changed to impl Rng + CryptoRng.

Hi @lovesh,
Thanks for your work on this, it has been really helpful!

I am working on lighthouse, an Ethereum 2.0 implementation. The Eth 2.0 roadmap presently relies heavily on BLS signature aggregation.

Over the last couple of days I took this repo and turned it into a Rust crate that I can use in our project for bench-marking. This process involved stripping out the functionality I didn't need and applying some of my own opinions to the API. Please excuse any changes which you think were unnecessary.

I would be interested to have a chat about this project and what you think about my modifications. I am not a cryptographer so I cannot provide assurance that the crypto is safe or sane. However, if it turns out to be a useful project for Ethereum 2.0 I would be more than happy to provide the assistance of myself and the team I work with to maintain this repository.

If you wish, please feel free to contact me on gitter/twitter: @paulhauner

Thanks again!

Hi @lovesh,

This crate is super useful. Are you opposed to creating release tags and pushing to crates.io? It may make it easier for others to find and use.

Thanks!

error: failed to select a version for the requirement `zeroize = "^0.9.3"`
candidate versions found which didn't match: 1.3.0, 1.2.0, 1.1.1, ...

because all version < 1.0 of zeroize crate was removed, this crate (bls_amcl 0.7.0) cannot be compiled, should improve the version of secret_sharing to 0.2.0, and amcl_wrapper to 0.3.0, because their depend zeroize of version "^0.9.3".

Is there a way to verify a multisignature with distinct messages (every signature was signed with a different message)? Can this feature be added?

Hi Lovesh,

I noticed that you added musig to the implementation, cool! The 2-round version you implemented (which i presume you took from https://eprint.iacr.org/2018/068/20180118:124757) is unfortunately insecure (see https://eprint.iacr.org/2018/417). A fixed 3-round version was presented independently by https://eprint.iacr.org/2018/483 and in an update to the original musig paper https://eprint.iacr.org/2018/068/20180520:191909.

There are a few functions named new, but they do not return Self. One example is AggregatedVerKey::new(). This is unidiomatic and should be changed since it will confuse people. I would recommend running cargo clippy on the crate to help with things like this.

The bls crate is named bls_acml instead of bls_amcl. See the Cargo.toml.