zkcrypto/bellman 527
zkSNARK library.
zkcrypto/pairing 218
Pairingfriendly elliptic curve library.
Implementation of the BLS12381 pairingfriendly elliptic curve group
zkcrypto/ff 80
Traits and utilities for working with finite fields.
Implementation of the Jubjub elliptic curve group
Elliptic curve group traits and utilities.
Implementation of the Groth16 zkSNARK proving system
zkcrypto/curve25519dalekng 17
A pureRust implementation of group operations on Ristretto and Curve25519
A pureRust implementation of Bulletproofs using Ristretto.
Composable proof transcripts for publiccoin arguments of knowledge
startedzkcrypto/bellman
started time in 4 hours
startedzkcrypto/group
started time in a day
startedzkcrypto/bellman
started time in a day
startedzkcrypto/bls12_381
started time in 2 days
startedzkcrypto/bellman
started time in 3 days
startedzkcrypto/ff
started time in 6 days
startedzkcrypto/bellman
started time in 6 days
startedzkcrypto/ff
started time in 6 days
issue openedzkcrypto/curve25519dalekng
Can't compile feature `simd_backend` in current nightly
error[E0557]: feature has been removed
> registry/src/github.com1ecc6299db9ec823/curve25519dalekng3.0.3/src/lib.rs:13:42

13  #![cfg_attr(feature = "nightly", feature(external_doc))]
 ^^^^^^^^^^^^ feature has been removed

= note: use #[doc = include_str!("filename")] instead, which handles macro invocations
created time in 8 days
Pull request review commentzkcrypto/group
pub trait Group: /// Doubles this element. #[must_use] fn double(&self) > Self;++ /// Perform multiscalar multiplication of the form `sum(base[i] * scalar[i])`.+ fn multiscalar_mul(bases: &[Self], scalars: &[Self::Scalar]) > Self {
It could be for this default implementation, but I think that would be too limiting in general. It's usually beneficial to have random access to the elements.
comment created time in 9 days
Pull request review commentzkcrypto/group
pub trait Group: /// Doubles this element. #[must_use] fn double(&self) > Self;++ /// Perform multiscalar multiplication of the form `sum(base[i] * scalar[i])`.+ fn multiscalar_mul(bases: &[Self], scalars: &[Self::Scalar]) > Self {
Since you're zipping them anyway below, perhaps it would make sense to take something like an impl IntoIterator<Item = (&Self, &Self::Scalar)>
?
comment created time in 9 days
issue openedzkcrypto/ff
ff_derive: unnecessary limb required for large modulus (e.g. for NIST Pcurves)
When using ff_derive
with the base or scalar field modulus of elliptic curves like P256 or P384, ff_derive
requires one more limb than is strictly necessary.
Example:
use ff::PrimeField;
#[derive(PrimeField)]
#[PrimeFieldModulus = "115792089210356248762697446949407573530086143415290314195533631308867097853951")
#[PrimeFieldGenerator = "6"]
#[PrimeFieldReprEndianness = "big"]
struct P256FieldElement([u64; 4]);
...fails with the following error:
error: The given modulus requires 5 limbs.
> src/lib.rs:7:31

7  struct P256FieldElement([u64; 4]);
created time in 9 days
PR opened zkcrypto/group
For discussion, an attempt at resolving #25
This PR adds a multiscalar_mul
method to Group
with a default implementation that isn't any more efficient than the naive method of calculating the result. I believe optimized versions of this method signature can be supported by the reference crates (as well as curve25519dalekng).
A MultiScalarPreparedMul
trait is added for groups that support precomputation of the bases. Generally this computes multiples of the base for a fixed window size, for example b*n^{0..w}
. The representation of these prepared values is not specified, but I think all the examples are using a Vec
so this might be behind an alloc
flag in the target crates. A library could choose to add a trivial implementation which simply used the Group
type as the Prepared
type in case it did not benefit from precomputation but wanted to support the trait anyway.
Some caveats:
 I expect the
multiscalar_mul
method would generally be constanttime, while in some cases a variable time implementation could be desired as well  Parallel computation can be supported at a higher level by relying on the trait methods. I don't think that the implementations of these methods should be automatically spinning up threads
 In some cases (for example the two uses of
lincomb
ink256
) precomputed bases would ideally be constructed by aconst
method, particularly for the generator point. This is assumed to be implemented by nontrait methods when supported  The window size for computation is not configurable here
 I think it could be possible to implement a generic doubleandadd along the lines of the one in halo2 by requiring
PrimeFieldBits
, but because targets can likely offer a better implementation I don't suggest adding it here
pr created time in 10 days
Elliptic curve group traits and utilities.
fork in 10 days
issue openedzkcrypto/ff
Would be nice to get a bitvec
bump now that 1.0 is out:
https://crates.io/crates/bitvec/1.0.0
created time in 10 days
startedzkcrypto/bls12_381
started time in 11 days
startedzkcrypto/bls12_381
started time in 12 days
startedzkcrypto/pairing
started time in 12 days
startedzkcrypto/bls12_381
started time in 13 days
startedzkcrypto/pairing
started time in 13 days
startedzkcrypto/bellman
started time in 13 days
startedzkcrypto/bellman
started time in 14 days
startedzkcrypto/bellman
started time in 17 days
Implementation of the BLS12381 pairingfriendly elliptic curve group
fork in 17 days