The new 2.1.0 version of subtle contains a CtOption<T> type which mirrors the functionality presented in the jubjub crate currently. Let's upgrade subtle and use their implementation instead.

Is there a use-case for exposing the base field of Jubjub? From the perspective of a user of the elliptic curve library, the base field of the curve is an implementation detail. From looking through the API it seemed like the only place that it's used in the public API is in functions like from_raw_unchecked for unsafely constructing points, but it's not clear why someone would need to do that.

Suggested by @str4d:

The Sarkar algorithm used in the Pasta implementation is applicable to Fq since it is highly 2-adic. (Fr is not, but optimizing Fq square roots is more important for Jubjub curve point decompression, and therefore for Sapling trial decryption; see zcash/librustzcash#423 (comment) ).

zcash/zips#442

We'd like to have Serde support for use implementing FROST for redjubjub (tracking issue: ZcashFoundation/redjubjub#21). I'd be happy to implement this (probably feature-gated behind a serde feature?) if it would fit with the library.

Test serialization for group elements and field elements.

In crates.io jubjub version is at 0.7.0 (https://crates.io/crates/jubjub) but here in github is 0.3.0 which is a bit confusing. Will it worth to tag 0.7.0 here now ?

Things like multiplicative generators, etc.

Take a 64-byte representation and reduce modulo q or r.

Jubjub needs you!

... to make efficient addition chains.

• 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfefffffffeffffffff (for inversion in Fq)
• 0x39f6d3a994cebea4199cec0404d0ec02a9ded2017fff2dff7fffffff80000000 (for Legendre symbol in Fq)
• 0x39f6d3a994cebea4199cec0404d0ec02a9ded2017fff2dff80000000 (for sqrt in Fq)
• 0x73eda753299d7d483339d80809a1d80553bda402fffe5bfeffffffff (also for sqrt in Fq)

• 0x0e7db4ea6533afa906673b0101343b00a6682093ccc81082d0970e5ed6f72cb5 (for inversion in Fr)

We currently re-export bls12_381::Scalar as jubjub::Fq, but it would be nice to refer to jubjub::Base instead.

I was running into some issues with broken homomorphic pederson commitments when I subtracted point values. I've reduced it down to this case:

Am I holding it wrong?

    #[test]
    fn test_negation_homomorphism() {
        use group::Group;

        let x = jubjub::Scalar::from(10);
        let g = jubjub::ExtendedPoint::generator();

        assert_eq!(-g * x, g * (-x));
    }

Output

assertion `left == right` failed
  left: ExtendedPoint { u: 0x197db5e33c8ad9e1083ac27de3533eaa9d36d097ff497c7a1aefbe6fd79e970a, v: 0x014240fbe01fc832a8db3b31dad62b3342b6577af812708bd4eb037e9ec18940, z: 0x21de9d247dfd4612f2180b944f760b04804a148e7f6d07b1ac2a703c14c08366, t1: 0x1ad0c3e44043bd97c832b7bb93f2528a818acb98ed64023e0d9be596ea354ee1, t2: 0x6c9dfbcc6cb85642265607a563bb90395c824e73d5986d4571fd80f25570b146 }
 right: ExtendedPoint { u: 0x2cbdca09b095734a2f37e363921cfe8bb4c579dc5120aab8bb068c9ad310f0cc, v: 0x03ceb419990ddd670da7d465709e0b15a47f39ea6e8a59d351a57ebf47a5d9d6, z: 0x455532f07662b915a30e7fe0e12d6afde9d45d31ddebcc1d5dd3af8255ad5329, t1: 0x69031d715b41e5931ce23214aee1d100ccdd5421cf77f57708e90c6a5ed5837b, t2: 0x45fc30f281451a660751e6a3972364cc190b56721923afb370fa323452516884 }

The implementation of WnafGroup::recommended_wnaf_for_num_scalars copies the empirical recommendations from the old pairing::bls12_381 implementation of G1. We should recalculate them for this implementation.

zcash/librustzcash#245 (comment)

This is all of the point arithmetic we could possibly need; though we have to consider what is and isn't necessary downstream, and expose a simpler interface. This is mostly based on what curve25519-dalek does. I've modified my proposed API based on Mike Hamburg's paper.

• AffinePoint represents a (u, v) coordinate in memory.
  • ::identity() -> Self (forward from Default::default())
  • ::compress(&self) -> [u8; 32]
  • ::decompress_vartime([u8; 32]) -> Self
  • ::get_u(&self) -> Fq
  • ::get_v(&self) -> Fq
  • ::to_affine_niels(&self) -> AffineNielsPoint
  • ::double(&self) -> ExtendedPoint
  • (private) ::is_on_curve_var(&self) -> bool
• ExtendedPoint represents a (U, V, T1, T2, Z) coordinate in memory. (u:Z, v:Z with T1*T2 = uv/Z)
  • ::to_affine(&self) -> AffinePoint
  • ::double(&self) -> CompletedPoint
• AffineNielsPoint represents an affine point in Niels coordinates (v+u, v-u, uv2d)
• ProjectiveNielsPoint represents a projective point in Niels coordinates (V+U, V-U, Z, 2dUV)

Traits

• impl Add<&ExtendedNielsPoint> for &ExtendedPoint
• impl Add<&AffineNielsPoint> for &ExtendedPoint
• impl Sub<&ExtendedNielsPoint> for &AffinePoint
• impl Sub<&AffineNielsPoint> for &AffinePoint
• impl Neg for &AffineNielsPoint
• impl Neg for &ProjectiveNielsPoint
• impl Neg for &AffinePoint
• impl Neg for &ExtendedPoint