Implementation of the BLS12-381 pairing-friendly elliptic curve group

Overview

bls12_381 Crates.io

This crate provides an implementation of the BLS12-381 pairing-friendly elliptic curve construction.

  • This implementation has not been reviewed or audited. Use at your own risk.
  • This implementation targets Rust 1.51 or later.
  • This implementation does not require the Rust standard library.
  • All operations are constant time unless explicitly noted.

Features

  • bits (on by default): Enables APIs for obtaining bit iterators for scalars.
  • groups (on by default): Enables APIs for performing group arithmetic with G1, G2, and GT.
  • pairings (on by default): Enables some APIs for performing pairings.
  • alloc (on by default): Enables APIs that require an allocator; these include pairing optimizations.
  • nightly: Enables subtle/nightly which tries to prevent compiler optimizations that could jeopardize constant time operations. Requires the nightly Rust compiler.
  • experimental: Enables experimental features. These features have no backwards-compatibility guarantees and may change at any time; users that depend on specific behaviour should pin an exact version of this crate. The current list of experimental features:

Documentation

Curve Description

BLS12-381 is a pairing-friendly elliptic curve construction from the BLS family, with embedding degree 12. It is built over a 381-bit prime field GF(p) with...

  • z = -0xd201000000010000
  • p = (z - 1)2(z4 - z2 + 1) / 3 + z
    • = 0x1a0111ea397fe69a4b1ba7b6434bacd764774b84f38512bf6730d2a0f6b0f6241eabfffeb153ffffb9feffffffffaaab
  • q = z4 - z2 + 1
    • = 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff00000001

... yielding two source groups G1 and G2, each of 255-bit prime order q, such that an efficiently computable non-degenerate bilinear pairing function e exists into a third target group GT. Specifically, G1 is the q-order subgroup of E(Fp) : y2 = x3 + 4 and G2 is the q-order subgroup of E'(Fp2) : y2 = x3 + 4(u + 1) where the extension field Fp2 is defined as Fp(u) / (u2 + 1).

BLS12-381 is chosen so that z has small Hamming weight (to improve pairing performance) and also so that GF(q) has a large 232 primitive root of unity for performing radix-2 fast Fourier transforms for efficient multi-point evaluation and interpolation. It is also chosen so that it exists in a particularly efficient and rigid subfamily of BLS12 curves.

Curve Security

Pairing-friendly elliptic curve constructions are (necessarily) less secure than conventional elliptic curves due to their small "embedding degree". Given a small enough embedding degree, the pairing function itself would allow for a break in DLP hardness if it projected into a weak target group, as weaknesses in this target group are immediately translated into weaknesses in the source group.

In order to achieve reasonable security without an unreasonably expensive pairing function, a careful choice of embedding degree, base field characteristic and prime subgroup order must be made. BLS12-381 uses an embedding degree of 12 to ensure fast pairing performance but a choice of a 381-bit base field characteristic to yield a 255-bit subgroup order (for protection against Pollard's rho algorithm) while reaching close to a 128-bit security level.

There are known optimizations of the Number Field Sieve algorithm which could be used to weaken DLP security in the target group by taking advantage of its structure, as it is a multiplicative subgroup of a low-degree extension field. However, these attacks require an (as of yet unknown) efficient algorithm for scanning a large space of polynomials. Even if the attack were practical it would only reduce security to roughly 117 to 120 bits. (This contrasts with 254-bit BN curves which usually have less than 100 bits of security in the same situation.)

Alternative Curves

Applications may wish to exchange pairing performance and/or G2 performance by using BLS24 or KSS16 curves which conservatively target 128-bit security. In applications that need cycles of elliptic curves for e.g. arbitrary proof composition, MNT6/MNT4 curve cycles are known that target the 128-bit security level. In applications that only need fixed-depth proof composition, curves of this form have been constructed as part of Zexe.

Acknowledgements

Please see Cargo.toml for a list of primary authors of this codebase.

License

Licensed under either of

at your option.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Comments
  • Basic Zeroize support

    Basic Zeroize support

    Keeping #14 open for now:

    • For some types Zeroize can't be derived and would be difficult to implement, e.g. because they contain vectors. We should evaluate which types potentially contain secret information.
    • If the zeroize feature is enabled, we should also use it in internal computations, and clear all temporary data that is potentially secret.

    On the other hand, I'd also be happy to remove Zeroize from the groups again, if we are confident that in practice, only the field elements will be secrets.

    opened by afck 7
  • Implemented serialization of Fp2, Fp6, Fp12 and Gt

    Implemented serialization of Fp2, Fp6, Fp12 and Gt

    Fixes #10, and by proxy #11.

    I still have to add a few tests. In expectation of a compressed Gt representation the corresponding methods are called from_uncompressed and to_uncompressed.

    Before continuing however I would like to discuss my heavy use of .copy_from_slice. As it stands the hierarchical use of Fq2, Fq6 and Fq12 ensures that lots of bytes are copied around. This is due the inability to split fixed length arrays to smaller fixed length arrays in standard Rust. The only way around this copying with Rust is by either coercing at runtime (i.e. TryInto) or using crates such as arrayref. This crate implements compile-time coercion of fixed-length arrays using unsafe. Given this coercion we hope that LLVM is capable of optimizing the intermediate arrays away. We could also change the function prototype to accept &mut [u8; N] array-references and write into those.

    Pending your opinions I prefer to use a crate like arrayref.

    opened by Wassasin 6
  • Enhance MillerLoopResult API

    Enhance MillerLoopResult API

    Changes:

    • Expose default fun for MillerLoopResult
    • Allow multiplying MillerLoopResult with another MillerLoopResult

    Context:

    I have been tinkering with this library a bit to test signature aggregation and I noticed that it would make it much easier if this library exposed a default MillerLoopResult (I can rename it to one if required) and also allow multiplying two MillerLoopResults together (mostly just to make external use slightly friendlier).

    Here's an example of the way I'm using it but I figured that perhaps it might be helpful for others if I open this up.

    There's at least a couple issues: #68 and #67 where this work may prove useful.

    opened by vihu 4
  • Implement Zeroize for public types

    Implement Zeroize for public types

    Previous discussion/work: https://github.com/zkcrypto/bls12_381/pull/26

    This makes zeroize an optional feature, and does not automatically zeroize any types on drop.

    Fixes #14

    opened by andrewwhitehead 4
  • Expose the MODULUS const

    Expose the MODULUS const

    Hi, we're using this lib for something at @nucypher and it'd be nice to have the modulus of the Scalar exposed. It's presently private, and this PR makes it pub.

    Thanks! :)

    opened by tuxxy 3
  • Add implementation of cyclotomic squaring for final exponentiation step

    Add implementation of cyclotomic squaring for final exponentiation step

    This is an extremely efficient squaring operation in the so-called cyclotomic subgroup of Fq^6.

    Closes #6

    Attached result of cargo bench -- "full pairing".

    Screen Shot 2019-11-22 at 16 51 39

    opened by saitima 3
  • Use crypto-bigint for Scalar and Fp

    Use crypto-bigint for Scalar and Fp

    Performance is generally improved due to a few algorithm updates including more use of sum_of_products_mod. This is currently using the git HEAD of crypto-bigint due to a small incompatibility with rust 1.57, plus some performance improvements, but I imagine a new release will be forthcoming.

    More testing is required on 32 bit platforms, benchmarking would be interesting too.

    Scalar benchmark results
    Scalar add              time:   [3.6612 ns 3.6732 ns 3.6854 ns]                        
    						change: [-22.740% -22.454% -22.186%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Scalar sub              time:   [3.4450 ns 3.4545 ns 3.4645 ns]                        
    						change: [+0.2271% +0.5603% +0.9052%] (p = 0.00 < 0.05)
    						Change within noise threshold.
    
    Scalar double           time:   [2.5990 ns 2.6066 ns 2.6145 ns]                           
    						change: [-27.561% -27.321% -27.063%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Scalar mul              time:   [17.470 ns 17.522 ns 17.578 ns]                        
    						change: [-20.321% -20.067% -19.804%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Scalar square           time:   [16.320 ns 16.376 ns 16.436 ns]                           
    						change: [-8.6400% -8.2618% -7.8922%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Scalar sqrt             time:   [29.178 us 29.277 us 29.378 us]                         
    						change: [-8.8626% -8.5340% -8.2014%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Scalar invert           time:   [6.5022 us 6.5229 us 6.5448 us]                           
    						change: [-18.758% -18.471% -18.192%] (p = 0.00 < 0.05)
    						Performance has improved.
    Found 2 outliers among 100 measurements (2.00%)
      2 (2.00%) high mild
    
    Scalar pow              time:   [12.244 us 12.284 us 12.325 us]                        
    						change: [-19.428% -19.126% -18.849%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Scalar from_bytes       time:   [24.342 ns 24.451 ns 24.563 ns]                               
    						change: [-7.6904% -7.2379% -6.7874%] (p = 0.00 < 0.05)
    						Performance has improved.
    Found 2 outliers among 100 measurements (2.00%)
      1 (1.00%) low mild
      1 (1.00%) high mild
    
    Scalar from_bytes_wide  time:   [31.434 ns 31.683 ns 31.963 ns]                                    
    						change: [-39.244% -38.986% -38.676%] (p = 0.00 < 0.05)
    						Performance has improved.
    Found 5 outliers among 100 measurements (5.00%)
      5 (5.00%) high severe
    
    Scalar to_bytes         time:   [15.709 ns 15.758 ns 15.809 ns]                             
    						change: [+11.708% +12.311% +12.942%] (p = 0.00 < 0.05)
    						Performance has regressed.
    
    Groups benchmark results
    full pairing            time:   [1.0606 ms 1.0641 ms 1.0677 ms]                          
    						change: [-8.1472% -7.6634% -7.1957%] (p = 0.00 < 0.05)
    						Performance has improved.
    Found 1 outliers among 100 measurements (1.00%)
      1 (1.00%) high mild
    
    Benchmarking G2 preparation for pairing: Collecting 100 samples in estimated 5.4546 s (50k iteration                                                                                                    G2 preparation for pairing                        
    						time:   [107.47 us 107.77 us 108.09 us]
    						change: [-9.7854% -9.4590% -9.1373%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    miller loop for pairing time:   [310.78 us 311.75 us 312.75 us]                                    
    						change: [-1.5543% -1.1635% -0.7893%] (p = 0.00 < 0.05)
    						Change within noise threshold.
    
    Benchmarking final exponentiation for pairing: Collecting 100 samples in estimated 6.5114 s (10k ite                                                                                                    final exponentiation for pairing                        
    						time:   [643.97 us 645.78 us 647.69 us]
    						change: [-9.0421% -8.6657% -8.3103%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G1Affine check on curve time:   [154.29 ns 154.77 ns 155.28 ns]                                    
    						change: [+0.0195% +0.4017% +0.8036%] (p = 0.04 < 0.05)
    						Change within noise threshold.
    
    G1Affine check equality time:   [29.959 ns 30.059 ns 30.161 ns]                                     
    						change: [+2.1783% +2.5461% +2.9045%] (p = 0.00 < 0.05)
    						Performance has regressed.
    
    Benchmarking G1Affine scalar multiplication: Collecting 100 samples in estimated 6.1443 s (20k itera                                                                                                    G1Affine scalar multiplication                        
    						time:   [303.24 us 304.19 us 305.18 us]
    						change: [-7.1361% -6.8124% -6.4782%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G1Affine subgroup check time:   [68.461 us 68.684 us 68.909 us]                                    
    						change: [-4.1456% -3.7713% -3.3888%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Benchmarking G1Affine deserialize compressed point: Collecting 100 samples in estimated 5.3160 s (56                                                                                                    G1Affine deserialize compressed point                        
    						time:   [95.151 us 95.445 us 95.760 us]
    						change: [-4.0997% -3.7456% -3.3897%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Benchmarking G1Affine deserialize uncompressed point: Collecting 100 samples in estimated 5.2179 s (                                                                                                    G1Affine deserialize uncompressed point                        
    						time:   [68.704 us 68.921 us 69.147 us]
    						change: [-3.8336% -3.4408% -3.0413%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Benchmarking G1Projective check on curve: Collecting 100 samples in estimated 5.0003 s (15M iteratio                                                                                                    G1Projective check on curve                        
    						time:   [335.03 ns 336.15 ns 337.33 ns]
    						change: [+0.8143% +1.1718% +1.5390%] (p = 0.00 < 0.05)
    						Change within noise threshold.
    
    Benchmarking G1Projective check equality: Collecting 100 samples in estimated 5.0010 s (23M iteratio                                                                                                    G1Projective check equality                        
    						time:   [215.98 ns 216.70 ns 217.43 ns]
    						change: [-6.5244% -5.9698% -5.5096%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G1Projective to affine  time:   [26.687 us 26.767 us 26.853 us]                                    
    						change: [-4.1964% -3.8577% -3.4989%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G1Projective doubling   time:   [470.45 ns 472.00 ns 473.61 ns]                                  
    						change: [-4.1497% -3.4990% -2.9780%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G1Projective addition   time:   [706.76 ns 708.87 ns 711.13 ns]                                   
    						change: [-10.762% -10.437% -10.103%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Benchmarking G1Projective mixed addition: Collecting 100 samples in estimated 5.0002 s (7.8M iterati                                                                                                    G1Projective mixed addition                        
    						time:   [635.80 ns 637.86 ns 640.00 ns]
    						change: [-7.5591% -7.2265% -6.9017%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Benchmarking G1Projective scalar multiplication: Collecting 100 samples in estimated 6.1491 s (20k i                                                                                                    G1Projective scalar multiplication                        
    						time:   [303.34 us 304.26 us 305.24 us]
    						change: [-7.2488% -6.9258% -6.6000%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Benchmarking G1Projective batch to affine n=10000: Collecting 100 samples in estimated 5.0475 s (210                                                                                                    G1Projective batch to affine n=10000                        
    						time:   [2.3988 ms 2.4051 ms 2.4115 ms]
    						change: [-8.4566% -8.1193% -7.7697%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G2Affine check on curve time:   [373.15 ns 374.38 ns 375.69 ns]                                    
    						change: [-8.2110% -7.9062% -7.6021%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G2Affine check equality time:   [57.400 ns 57.586 ns 57.777 ns]                                    
    						change: [+4.7097% +5.1048% +5.4732%] (p = 0.00 < 0.05)
    						Performance has regressed.
    
    Benchmarking G2Affine scalar multiplication: Collecting 100 samples in estimated 8.5644 s (10k itera                                                                                                    G2Affine scalar multiplication                        
    						time:   [844.42 us 846.86 us 849.44 us]
    						change: [-1.0881% -0.7373% -0.4015%] (p = 0.00 < 0.05)
    						Change within noise threshold.
    
    G2Affine subgroup check time:   [93.040 us 93.325 us 93.616 us]                                    
    						change: [-1.3574% -1.0275% -0.7165%] (p = 0.00 < 0.05)
    						Change within noise threshold.
    
    Benchmarking G2Affine deserialize compressed point: Collecting 100 samples in estimated 5.9712 s (25                                                                                                    G2Affine deserialize compressed point                        
    						time:   [236.00 us 236.77 us 237.56 us]
    						change: [-4.6933% -4.3459% -4.0030%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Benchmarking G2Affine deserialize uncompressed point: Collecting 100 samples in estimated 5.2117 s (                                                                                                    G2Affine deserialize uncompressed point                        
    						time:   [93.570 us 93.862 us 94.172 us]
    						change: [-1.4602% -1.1334% -0.8157%] (p = 0.00 < 0.05)
    						Change within noise threshold.
    
    Benchmarking G2Projective check on curve: Collecting 100 samples in estimated 5.0010 s (5.6M iterati                                                                                                    G2Projective check on curve                        
    						time:   [891.19 ns 894.03 ns 897.03 ns]
    						change: [-2.8362% -2.4676% -2.0877%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    Benchmarking G2Projective check equality: Collecting 100 samples in estimated 5.0004 s (8.1M iterati                                                                                                    G2Projective check equality                        
    						time:   [614.90 ns 616.73 ns 618.71 ns]
    						change: [+4.4022% +4.7763% +5.1489%] (p = 0.00 < 0.05)
    						Performance has regressed.
    
    G2Projective to affine  time:   [27.139 us 27.228 us 27.319 us]                                    
    						change: [-4.0145% -3.6433% -3.2905%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G2Projective doubling   time:   [1.2772 us 1.2812 us 1.2854 us]                                   
    						change: [-2.0537% -1.7139% -1.3663%] (p = 0.00 < 0.05)
    						Performance has improved.
    
    G2Projective addition   time:   [2.0551 us 2.0617 us 2.0685 us]                                   
    						change: [+0.1960% +0.5270% +0.8810%] (p = 0.00 < 0.05)
    						Change within noise threshold.
    
    Benchmarking G2Projective mixed addition: Collecting 100 samples in estimated 5.0014 s (2.7M iterati                                                                                                    G2Projective mixed addition                        
    						time:   [1.8447 us 1.8510 us 1.8572 us]
    						change: [+0.6162% +1.0019% +1.3586%] (p = 0.00 < 0.05)
    						Change within noise threshold.
    
    Benchmarking G2Projective scalar multiplication: Collecting 100 samples in estimated 8.5639 s (10k i                                                                                                    G2Projective scalar multiplication                        
    						time:   [845.51 us 847.83 us 850.26 us]
    						change: [-0.4515% -0.1366% +0.1693%] (p = 0.42 > 0.05)
    						No change in performance detected.
    
    Benchmarking G2Projective batch to affine n=10000: Collecting 100 samples in estimated 5.5263 s (800                                                                                                    G2Projective batch to affine n=10000                        
    						time:   [6.8998 ms 6.9171 ms 6.9349 ms]
    						change: [+2.2092% +2.6007% +2.9832%] (p = 0.00 < 0.05)
    						Performance has regressed.
    
    opened by andrewwhitehead 2
  • How can I multiply elements in Gt with another Gt?

    How can I multiply elements in Gt with another Gt?

    I was trying to implement https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-04#section-2.9. The algorithm is:

       1.  R = signature_to_point(signature)
       2.  If R is INVALID, return INVALID
       3.  If signature_subgroup_check(R) is INVALID, return INVALID
       4.  C1 = 1 (the identity element in GT)
       5.  for i in 1, ..., n:
       6.      If KeyValidate(PK_i) is INVALID, return INVALID
       7.      xP = pubkey_to_point(PK_i)
       8.      Q = hash_to_point(message_i)
       9.      C1 = C1 * pairing(Q, xP)
       10. C2 = pairing(R, P)
       11. If C1 == C2, return VALID, else return INVALID
    

    I'm stuck on line#9, the current code allows multiplying Gt * Scalar (if I'm reading the code correctly); is there a way to do Gt * Gt?

    Thanks! Specifically line#9;

    opened by vihu 2
  • Allow usage of MillerLoopResult independently of the builtin apis

    Allow usage of MillerLoopResult independently of the builtin apis

    In the former implementation of pairing it was possible to use Fp12 directly to work with the intermediary results of miller loops, before doing the final accumulation. With the new API of MillerLoopResult and Gt this is impossible.

    You can see an example of this here: https://github.com/filecoin-project/bls-signatures/blob/master/src/signature.rs#L158-L208, which I am trying to migrate to this crate.

    opened by dignifiedquire 2
  • Add convenience function to get a random scalar

    Add convenience function to get a random scalar

    This just adds a random function to the Scalar implementation. The reason I added this is just for convenience when using the bls crate in other projects. Please let me know if I have to tweak something here.

    opened by vihu 2
  • Add support for hash to curve draft 11

    Add support for hash to curve draft 11

    opened by andrewwhitehead 2
  • Get access to the `Fp12` representation from `Gt`

    Get access to the `Fp12` representation from `Gt`

    The https://docs.rs/bls12_381/0.7.0/bls12_381/struct.Gt.html has very little functionality exposed at the moment. It implements the Group trait and a few helpers, however this is not enough for one of the ZK protocols we have.

    What would suffice for us is a way to get the underlying Fp12 representation of Gt. For example,

    impl AsRef<Fp12> for Gt {
       ...
    }
    

    would be perfectly adequate, or any other alternative you would prefer.

    Is this something you are open to adding to the library? Without this we cannot upgrade from the old pairing crate that embedded the bls implementation to the recent one.

    This is related to https://github.com/zkcrypto/bls12_381/issues/10 although I need less than that.

    opened by abizjak 3
  • Update to hash-to-curve draft 16, with some API adjustments

    Update to hash-to-curve draft 16, with some API adjustments

    • Adds a Message trait for use by expand_message rather than requiring the message to be a single [u8] (more flexibility for larger message values and no-alloc situations)
    • Allows expand_message to be used with security levels other than k=128
    • Removes lifetime parameters and the separate InitExpandMessage trait
    • Moves unit tests to tests/ for compilation performance
    opened by andrewwhitehead 0
  • Faster scalar multiplication in G1.

    Faster scalar multiplication in G1.

    Implements the GLV method for scalar multiplication in G1 in constant time.

    The code includes a BETA constant (cube root of -1) to apply the GLV endomorphism, a GLV recoding algorithm to convert the scalar into subscalars and a regular recoding algorithm to compute a wNAF version with prescribed non-zero positions (due to Joye and Tunstall). The GLV and regular recoding methods are orthogonal and do not depend on each other if the former is deemed too risky.

    The code probably can be simplified, but this version should start some discussion.

    opened by dfaranha 2
  • Interest in faster implementation of scalar multiplication in G1/G2

    Interest in faster implementation of scalar multiplication in G1/G2

    Hi,

    I have a bunch of optimizations for faster G1/G2 scalar multiplications sitting in a fork at https://github.com/dfaranha/bls12_381

    These provide a 2x speedup and include:

    • Regular w-NAF recodings to reduce the number of point additions in comparison to double-and-always add
    • GLV recoding for scalar decomposition, combined with interleaving to save half of the point doublings
    • Moving to homogeneous projective coordinates for pairing computation to unify point arithmetic

    Some technical details can be found at https://skillsmatter.com/skillscasts/17052-experimenting-with-faster-elliptic-curves-in-rust

    I would like to know if there is interest in merging, so it makes sense to put time on preparing a proper pull request.

    Thank you for your attention!

    opened by dfaranha 3
Releases(0.1.1)
  • 0.1.1(Jan 28, 2020)

    Added clear_cofactor methods to G1Projective and G2Projective. If the crate feature endo is enabled the G2 cofactor clearing will use the curve endomorphism technique described by Budroni-Pintore. If the crate feature endo is not enabled then the code will simulate the effects of the Budroni-Pintore cofactor clearing in order to keep the API consistent. In September 2020, when patents US7110538B2 and US7995752B2 expire, the endo feature will be made default. However, for now it must be explicitly enabled.

    Source code(tar.gz)
    Source code(zip)
Owner
Zero-knowledge Cryptography in Rust
Zero-knowledge Cryptography in Rust
BLS12-381 cryptography using Apache Milagro

BLS12-381 Aggregate Signatures in Rust using Apache Milagro WARNING: This library is a work in progress and has not been audited. Do NOT consider the

Sigma Prime 21 Apr 4, 2022
Baek-Zheng threshold cryptosystem on top of BLS12-381

bzte A rust implementation of the Baek-Zhang threshold cryptosystem on top of BLS12-381 using arkworks Why threshold encrypt? The advantage of thresho

null 4 Jun 28, 2022
DKG using BLS12-381

DKG This library is an implementation of the distributed key generator required for blind DKG. Overview dkg-core: supports both std and no-std. When b

Ideal Labs 3 May 10, 2023
Rust implementation of {t,n}-threshold ECDSA (elliptic curve digital signature algorithm).

Multi-party ECDSA This project is a Rust implementation of {t,n}-threshold ECDSA (elliptic curve digital signature algorithm). Threshold ECDSA include

[ZenGo X] 706 Jan 5, 2023
X25519 elliptic curve Diffie-Hellman key exchange in pure-Rust, using curve25519-dalek.

x25519-dalek A pure-Rust implementation of x25519 elliptic curve Diffie-Hellman key exchange, with curve operations provided by curve25519-dalek. This

dalek cryptography 252 Dec 26, 2022
Multi Party Key Management System (KMS) for Secp256k1 Elliptic curve based digital signatures.

Key Management System (KMS) for curve Secp256k1 Multi Party Key Management System (KMS) for Secp256k1 Elliptic curve based digital signatures. Introdu

[ZenGo X] 61 Dec 28, 2022
Elliptic curve cryptography on Soroban.

Elliptic Curve Cryptography on Soroban Contract examples and reusable primitives. Groth 16 verifier. This crate provides a SorobanGroth16Verifier obje

Xycloo Labs 5 Feb 10, 2023
A pairing-based threshold cryptosystem for collaborative decryption and signatures used in HoneybadgerBFT implementation

threshold_crypto A pairing-based threshold cryptosystem for collaborative decryption and signatures. The threshold_crypto crate provides cryptographic

null 166 Dec 29, 2022
Pairing cryptography library in Rust

bn This is a pairing cryptography library written in pure Rust. It makes use of the Barreto-Naehrig (BN) curve construction from [BCTV2015] to provide

Electric Coin Company Prototypes and Experiments 139 Dec 15, 2022
Pairing cryptography library in Rust

bn This is a pairing cryptography library written in pure Rust. It makes use of the Barreto-Naehrig (BN) curve construction from [BCTV2015] to provide

Parity Technologies 23 Apr 22, 2022
Bulletproofs and Bulletproofs+ Rust implementation for Aggregated Range Proofs over multiple elliptic curves

Bulletproofs This library implements Bulletproofs+ and Bulletproofs aggregated range proofs with multi-exponent verification. The library supports mul

[ZenGo X] 62 Dec 13, 2022
Rust implementation of multi-party Schnorr signatures over elliptic curves.

Multi Party Schnorr Signatures This library contains several Rust implementations of multi-signature Schnorr schemes. Generally speaking, these scheme

[ZenGo X] 148 Dec 15, 2022
Implementation of the Grumpkin curve in Rust.

Grumpkin curve implementation in Rust This repository implements the Grumpkin curve for use in Rust, by building off of the code provided by ZCash and

Jules 3 Dec 26, 2022
L2 validity rollup combined with blind signatures over elliptic curves inside zkSNARK, to provide offchain anonymous voting with onchain binding execution on Ethereum

blind-ovote Blind-OVOTE is a L2 voting solution which combines the validity rollup ideas with blind signatures over elliptic curves inside zkSNARK, to

Aragon ZK Research 3 Nov 18, 2022
A pure-Rust implementation of group operations on Ristretto and Curve25519

curve25519-dalek A pure-Rust implementation of group operations on Ristretto and Curve25519. curve25519-dalek is a library providing group operations

dalek cryptography 611 Dec 25, 2022
A Rust implementation of the Message Layer Security group messaging protocol

Molasses An extremely early implementation of the Message Layer Security group messaging protocol. This repo is based on draft 4 of the MLS protocol s

Trail of Bits 109 Dec 13, 2022
Fast Hilbert space-filling curve transformation using a LUT

Fast Hilbert Fast Hilbert 2D curve computation using an efficient Lookup Table (LUT). Convert from discrete 2D space to 1D hilbert space and reverse V

Armin Becher 20 Nov 3, 2022
Implements ERC-5564 for the bn254 curve using arkworks-rs

erc-5564-bn254 Uses the arkworks-rs suite of libraries, and utilities from rln Usage Note: this scheme should be used with the fork of circom-rln. use

Aaryamann Challani 21 Sep 8, 2023
Flexible secp256k1 curve math library.

secp A flexible and secure secp256k1 elliptic curve math library, with constant-time support, and superb ergonomics. secp takes full advantage of Rust

null 7 Nov 1, 2023