Decompression extremely slow

[RuralDependencies]

Hi!

Thank you for this amazing crate, It seems like it's the best one available for Rust now.
However I'm having one quite annoying issue with it, it seems that the decompression function is extremely slow, at least too slow for my use case.

I've seen online there is 2 methods of compression, one patented and another one not, which one do you use?

Do you know anyway of making this function faster?
pub fn from_bytes(bytes: [u8; 96]) -> Result<Self, GroupDecodingError>

https://docs.rs/bls-like/0.1.0/bls_like/single/struct.Signature.html#method.decompress

Have a nice day!

[burdges]

Yes, decompression currently does a full multiplication by the group order. See: https://github.com/filecoin-project/pairing/blob/master/src/bls12_381/ec.rs#L146 and https://github.com/filecoin-project/pairing/blob/master/src/bls12_381/ec.rs#L964

It's slow on G1 and really slow on G2. Assuming your orientation is public keys on G1 and signatures on G2 then yes it increases verification time significantly, although the pairings remain the worst part I think.

We're using the filecoin-project/pairing (paired) fork of zcash's pairing crate that support hashing-to-the-curve, as well as a bunch of trivial convenience tweaks that zcash never merged. I'd think everyone involved with that fork would support faster decompression and presumably the IRTF CFRG drafts for BLS signatures and hash-to-curve give good answers, but..

We should first replace the filecoin-project/pairing (paired) fork with some new fork that builds on zcash's new crate hierarchy. And send zcash PRs that they might or might not merge.

Algorand has a similar fork https://github.com/algorand/pairing-plus I'm unsure if it uses the newest zcash crates either, but it might support faster decompression and the hash-to-the-curve operation might somehow be better.

Ideally we should increase the compliance with the IRTF CFRG drafts throughout #5 although one should not do anything silly like using SHA2-HMACs everywhere.

As an aside, I'll caution you we're using zcash's crypto that does not currently provide constant time operations. I added key spiting to compensate but that's really more an orthogonal issue. See #3 There are several BLS crates based on AMCL, which does make constant-time claims. AMCL implements curves generically, which comes with upsides and downsides that I do not fully understand, but I know not everyone buys all the claims made by AMCL. ZCash will eventually provide constant-time code, at which point I'd trust their code more than AMCL.

I'd love a PR that added amcl_wrapper as an optional dependency used it only for signing, or more likely some fork of acml_wrapper that uses the AGPL's https://github.com/miracl/core see lovesh/amcl_rust_wrapper#6