Add hashing into the curve. #30

mmaker · 2017-08-10T05:49:13Z

Hello.
A few days ago @zmanian said it'd be nice if somebody added hashing to the curve to pairing, and I found myself with a few spare days in bed, soo… I'd like to propose the folllowing changes:

Add Legendre symbol for Fq and Fq2, with test cases
Implement Foque-Ticouchi's hashing to the curve algorithm

The algorithm is pretty much along the lines of https://github.com/herumi/mcl/blob/9fbc54305d01b984e39d83e96bfa94bb17648a86/include/mcl/bn.hpp#L65-L127 , as suggested by @zmanian.

ebfull · 2017-08-10T12:32:40Z

(Awesome work!)

I don't have time to review this today, but one comment: why can't SqrtField have the Legendre symbol defined over it instead of making a new trait?

ebfull · 2017-08-10T13:18:19Z

Two additional comments:

The implementations of SqrtField internally perform residue tests that are perhaps redundant with legendre().
I think the implementation of rand in G1/G2 should probably just use this hashing, if it works.

ebfull · 2017-08-10T13:27:27Z

As far as I can tell this implementation does not currently guarantee hashing into the correct subgroup. BLS12-381 has nontrivial cofactors for G1/G2, whereas BN curves have h=1 for G1.

daira · 2017-08-10T14:49:43Z

If we add this then I'd like to make sure it is consistent with the hashing we specify for Sapling (if we decide to use diversified addresses and/or the generalized-Pedersen approach to UITs), so bear with me until I have time to review it and the Fouque–Joux–Tibouchi paper properly. Yes we'll need to hash into the subgroup.

[Edit: I had the wrong paper here.]

At first sight, +1 on moving legendre() into SqrtField and factoring out any redundancy there.

daira · 2017-08-10T14:59:46Z

src/bls12_381/fr.rs

@@ -561,8 +562,7 @@ impl SqrtField for Fr {
            return Some(*self);
        }

-        // if self^((r - 1) // 2) != 1
-        if self.pow([0x7fffffff80000000, 0xa9ded2017fff2dff, 0x199cec0404d0ec02, 0x39f6d3a994cebea4]) != Self::one() {
+        if let QNonResidue = self.legendre() {


Why is this if let QNonResidue =? (Maybe I'm just missing something about Rust pattern matching, but I would have expected if self.legendre() != QResidue for similarity to the existing code. I know the zero case is handled above.)

This is idomatic Rust. In order to do if self.legendre() != QResidue you need to implement PartialEq (equality) for LegendreSymbol, but absent a good reason to do this, it's preferable to use if let.

So, speaking of which, this code should use a match instead of if let and handle the Zero case of LegendreSymbol.

Because I'm a n00b.
I've polished that function a bit here mmaker@e27801d and it looks a bit better.

daira · 2017-08-10T15:29:17Z

src/bls12_381/ec.rs

+                    }
+
+                }
+                Self {x: Self::Base::zero(), y: Self::Base::zero(), infinity: true }


Can the hash be defined never to output the point at infinity?

That is just Rust not understanding that the function it will return before for sure. That line is never executed.

I wasn't really sure what would have been conventional to do there, whether panic! or return a silly point like infinity - bn.h returns an ERR_POINT as far as I remember.
Plus, from ocaml I had this feeling that exceptions are bad and that I should keep my functions pure, so …

In any case, I'm happy to change it if needed!
As a side note, making it constant-time will probably get rid of that for loop and the silly return
(as described on the paper). For now I am aiming at a state that allows me to generate test-vectors.

If it's true that the algorithm never can produce the point at infinity, then this should return unreachable!().

@ebfull, what's the policy for "cannot happen" cases? (Without having thought about it very hard, a panic! seems fine to me.)

unreachable!() is idiomatic rust. It just panics with "unreachable code".

mmaker · 2017-08-10T16:29:41Z

The implementations of SqrtField internally perform residue tests that are perhaps redundant with legendre().

At first sight, +1 on moving legendre() into SqrtField and factoring out any redundancy there.

Initially I created a separate trait because I wasn't sure I really needed to implement the legendre symbol for all fields implementing sqrt. Turns out this is the case.

I merged SqrtField and LegendreField at mmaker@e6014d1 as a separate commit. (can squash if needed!)

mmaker · 2017-08-10T16:38:04Z

The implementations of SqrtField internally perform residue tests that are perhaps redundant with legendre().

Right. So, fr.rsuses it; fq.rs and fq2.rs do not, and I don't really see how they would use it - the algorithms for sqrt mod 4 already understand if it is a quadratic residue or not.

mmaker · 2017-08-10T16:45:40Z

As far as I can tell this implementation does not currently guarantee hashing into the correct subgroup. BLS12-381 has nontrivial cofactors for G1/G2, whereas BN curves have h=1 for G1.

If we add this then I'd like to make sure it is consistent with the hashing we specify for Sapling (if we decide to use diversified addreses and/or the generalized-Pedersen approach to UITs), so bear with me until I have time to review it and the Foque-Ticouchi paper properly. Yes we'll need to hash into the subgroup.

oh silly silly me I didn't check at all this. Okay mm so in the meantime I'll dive into that loooong issue of yours

Thanks for poining this out!

zmanian · 2017-08-10T16:56:01Z

I'm unsure if Fouques and Tabouchi works with cofactor != 1.

This implies that we should potentially use some variant of Eligator -Squared (https://eprint.iacr.org/2014/043.pdf & https://hal.inria.fr/hal-01275711/document)

@hdevalence has argued that providing a mapping to curve point should be considered an essential part any curve library.

mmaker · 2017-08-10T18:25:19Z

what happens if I multiply by the cofactor at the end of the function?
The point is going to be in the subgroup no?

Edit: indeed the paper mentions BLS curves and suggests to multiply by the cofactor:

Our results apply almost without change to any elliptic curve of the form […]: this includes in particular the curves constructed by Barreto, Lynn and Scott in [2, §3.1] and […]
The elliptic curve group in those cases is not usually of prime order, […], so hashing to the prime order subgroup requires multiplying the point obtained with the technique described herein by the cofactor. This does not affect indifferentiability, as was shown in [12, §6.1].

In an attempt to see this with my own eyes I tried to add a patch that multiplies by the cofactor at the end, together with some test cases that verify "some images" are in the desidered subgroup.
Tests suceeds for G1, still failing for G2. The reason they fail for G2 (I think) is that the cofactor is "too big" for our type:

sage: cofactor_g2 = Integer(x**8 - 4*x**7 + 5*x**6 - 4*x**4 + 6*x**3 - 4*x**2 - 4*x + 13) / 9                   
sage: cofactor_g2           
305502333931268344200999753193121504214466019254188142667664032982267604182971884026507427359259977847832272839041616661285803823378372096355777062779109                                                     
sage: Fr(cofactor_g2)             
52435875175126190477137643957470197624944050669916493059025303477134612409005

and I need to do arithmetic outside Fr to do so. How can I do it?
Note: for G1 tests also properly fail if I comment out multiplication by the cofactor.

ebfull · 2017-08-11T04:25:35Z

Yes, the G2 cofactor is very large.

I'll have to think about a clean way to allow us to perform scalar multiplications of such magnitude. I don't want that capability to be generally available to downstream users because I never want to encourage them to multiply by non-Fr scalars.

In some of my tests I just manually perform double-and-add, like this:

// Cofactor of G2 is 305502333931268344200999753193121504214466019254188142667664032982267604182971884026507427359259977847832272839041616661285803823378372096355777062779109.
// Calculated by: ((x**8) - (4 * (x**7)) + (5 * (x**6)) - (4 * (x**4)) + (6 * (x**3)) - (4 * (x**2)) - (4*x) + 13) // 9
// where x is the BLS parameter.
for b in "101110101010100001110101001010101000001010011100111111100010000100100011101010100000111100100101000011101101010001000000010110011011001000111011110010001010100011100001000010110101011101010100110100010100010000001011011001011100101101001111101110111111010011000101000111100011100101101001101100111101000001011101111001000010101001101111110001010010011101001100110100100011010111000010110000101101110110001101110011110000110111100001100011100001100111100011100001110001110001100011100011100100011100011100101"
         .chars()
         .map(|c| c == '1')
{
    g2.double();

    if b {
        g2.add_assign_mixed(&p);
    }
}

You can just use this until we figure it out.

daira

Lots of comments.

daira · 2017-08-11T06:25:23Z

src/bls12_381/fr.rs

-
-            while t != Self::one() {
+        match self.legendre() {
+            Zero => Some(*self),


Will this return an object that stays zero if self is mutated?

I don't know; but it's behaving as it was before. https://github.com/ebfull/pairing/blob/master/src/bls12_381/fr.rs#L560-L562 @ebfull?

Yes, it dereferences self which copies it.

daira · 2017-08-11T06:26:57Z

src/bls12_381/fr.rs

@@ -557,45 +557,42 @@ impl SqrtField for Fr {
    fn sqrt(&self) -> Option<Self> {
        // Tonelli-Shank's algorithm for q mod 16 = 1
        // https://eprint.iacr.org/2012/685.pdf (page 12, algorithm 5)


Maybe assert somewhere that q mod 16 = 1.

(Nonblocking; I know this hasn't changed in this PR.)

daira · 2017-08-11T06:30:03Z

src/bls12_381/fr.rs

-                            break;
-                        }
+                    {
+                        let mut t2i = t;
                        t2i.square();


wishes that diff would not try so hard to find accidentally matching lines within modified blocks

daira · 2017-08-11T06:36:09Z

src/bls12_381/fq.rs

+        else if s == Fq::one() { QResidue }
+        else { QNonResidue }
+    }
+
    fn sqrt(&self) -> Option<Self> {
        // Shank's algorithm for q mod 4 = 3
        // https://eprint.iacr.org/2012/685.pdf (page 9, algorithm 2)


Maybe assert somewhere that q mod 4 = 3. (Nonblocking.)

Also, add constants for (q - 3)/2 and -1.

This can be left to another PR btw.

daira · 2017-08-11T06:37:55Z

src/bls12_381/fq.rs

+
+// C2 = (C1 - 1) / 2 mod q = 793479390729215512621379701633421447060886740281060493010456487427281649075476305620758731620350
+pub const C2: Fq = Fq(FqRepr([0x30f1361b798a64e8, 0xf3b8ddab7ece5a2a, 0x16a8ca3ac61577f7, 0xc26a2ff874fd029b, 0x3636b76660701c6e, 0x51ba4ab241b6160]));
+
 // GENERATOR = 2 (multiplicative generator of q-1 order, that is also quadratic nonresidue)
 const GENERATOR: FqRepr = FqRepr([0x321300000006554f, 0xb93c0018d6c40005, 0x57605e0db0ddbb51, 0x8b256521ed1f9bcb, 0x6cf28d7901622c03, 0x11ebab9dbb81e28c]);


Maybe assert that it is a quadratic nonresidue, now that we have legendre(). (Nonblocking.)

Why does it say "= 2", btw, @ebfull? (Nonblocking.)

It's 2 in the field. (Represented in Montgomery form, which is why it looks random.)

daira · 2017-08-11T07:42:19Z

src/bls12_381/fr.rs

+pub const G1_COFACTOR: Fr = Fr(FrRepr([0x31207728cdb90779, 0xffea90400320679a, 0xa479130bcc248091, 0x6d41ecdf98f9d8cc]));
+
+// G2 has cofactor (x^8 - 4x^7 + 5x^6 - 4x^4 + 6x^3 - 4x^2 - 4x + 13) / 9.
+pub const G2_COFACTOR: Fr = Fr(FrRepr([0x755c12a6851eb90e, 0xe117af10228fcb8c, 0xd67937ea756c9ced, 0x6dabbfa8c0fd834b]));


For each group, assert that the cofactor times the group order is the curve order.

daira · 2017-08-11T07:44:40Z

src/bls12_381/fr.rs

+                let mut c = Fr(ROOT_OF_UNITY);
+                // r = self^((t + 1) // 2)
+                let mut r = self.pow([0x7fff2dff80000000, 0x4d0ec02a9ded201, 0x94cebea4199cec04, 0x39f6d3a9]);
+                // t = self^t


These comments don't make sense to me; what is t initially? Is this a naming clash?

don't know; it was already there. See https://github.com/ebfull/pairing/blob/master/src/bls12_381/fr.rs#L569

daira · 2017-08-11T07:45:07Z

src/bls12_381/fr.rs

+                // r = self^((t + 1) // 2)
+                let mut r = self.pow([0x7fff2dff80000000, 0x4d0ec02a9ded201, 0x94cebea4199cec04, 0x39f6d3a9]);
+                // t = self^t
+                let mut t = self.pow([0xfffe5bfeffffffff, 0x9a1d80553bda402, 0x299d7d483339d808, 0x73eda753]);


What is this constant?

don't know; it was already there. See https://github.com/ebfull/pairing/blob/master/src/bls12_381/fr.rs#L571

It's explained in the algorithm I think.

daira · 2017-08-11T07:46:23Z

src/lib.rs

@@ -214,6 +214,9 @@ pub trait CurveAffine: Copy +
    fn into_uncompressed(&self) -> Self::Uncompressed {
        <Self::Uncompressed as EncodedPoint>::from_affine(*self)
    }
+
+    /// Hash into this curve


Be clearer about the properties of the mapping.

done, I tried to elaborate a bit more.

daira · 2017-08-11T07:47:13Z

src/lib.rs

@@ -325,11 +328,15 @@ pub trait Field: Sized +
 /// This trait represents an element of a field that has a square root operation described for it.
 pub trait SqrtField: Field
 {
+    /// Returns the legendre symbol of the field element.


"Legendre". (The method name is fine as lowercase.)

ebfull · 2017-08-11T16:28:13Z

Our review is going to be really exhaustive, I hope you can bear with us! 😅

@bmerge try

bmerge · 2017-08-11T16:28:19Z

⌛ Trying commit 84c9a83 with merge 80a963e...

@zmanian

Add hashing into the curve. Hello. A few days ago @zmanian said it'd be nice if somebody added hashing to the curve to `pairing`, and I found myself with a few spare days in bed, soo… I'd like to propose the folllowing changes: - Add Legendre symbol for Fq and Fq2, with test cases - Implement Foque-Ticouchi's hashing to the curve algorithm The algorithm is pretty much along the lines of https://github.com/herumi/mcl/blob/9fbc54305d01b984e39d83e96bfa94bb17648a86/include/mcl/bn.hpp#L65-L127 , as suggested by @zmanian.

ebfull · 2017-08-10T13:12:33Z

src/bls12_381/ec.rs

+                        0 =>  { x.mul_assign(&t); x.negate(); x.add_assign(&Self::get_c2()) },
+                        1 =>  {                   x.negate(); x.sub_assign(&Self::Base::one()) },
+                        2 =>  { x=w; x.square();  x = x.inverse().unwrap(); x.add_assign(&Self::Base::one()) },
+                        _ =>  {}


unreachable!()

ebfull · 2017-08-10T13:13:00Z

src/bls12_381/ec.rs

+                let mut x = w;
+                for i in 0..3 {
+                    match i {
+                        0 =>  { x.mul_assign(&t); x.negate(); x.add_assign(&Self::get_c2()) },


Separate these statements into individual lines.

ebfull · 2017-08-10T13:13:28Z

src/lib.rs

+#[derive(Debug, PartialEq)]
+pub enum LegendreSymbol {
+    Zero = 0,
+    QResidue = 1,


QuadraticResidue and QuadraticNonResidue

This blocks for me, I prefer explicit names like this. 😸

ebfull · 2017-08-10T13:14:15Z

src/lib.rs

+pub trait LegendreField: Field
+{
+    /// Returns the legendre symbol of the field element.
+    fn legendre(&self) -> LegendreSymbol;


Instead of making a trait let's add this to SqrtField (which will require us to additionally implement it for Fr.)

ebfull · 2017-08-10T16:14:11Z

src/bls12_381/fr.rs

@@ -561,8 +562,7 @@ impl SqrtField for Fr {
            return Some(*self);
        }

-        // if self^((r - 1) // 2) != 1
-        if self.pow([0x7fffffff80000000, 0xa9ded2017fff2dff, 0x199cec0404d0ec02, 0x39f6d3a994cebea4]) != Self::one() {
+        if let QNonResidue = self.legendre() {


This is idomatic Rust. In order to do if self.legendre() != QResidue you need to implement PartialEq (equality) for LegendreSymbol, but absent a good reason to do this, it's preferable to use if let.

So, speaking of which, this code should use a match instead of if let and handle the Zero case of LegendreSymbol.

ebfull · 2017-08-11T16:14:11Z

src/bls12_381/fr.rs

-
-            while t != Self::one() {
+        match self.legendre() {
+            Zero => Some(*self),


Yes, it dereferences self which copies it.

ebfull · 2017-08-11T16:14:54Z

src/bls12_381/fr.rs

+                // r = self^((t + 1) // 2)
+                let mut r = self.pow([0x7fff2dff80000000, 0x4d0ec02a9ded201, 0x94cebea4199cec04, 0x39f6d3a9]);
+                // t = self^t
+                let mut t = self.pow([0xfffe5bfeffffffff, 0x9a1d80553bda402, 0x299d7d483339d808, 0x73eda753]);


It's explained in the algorithm I think.

ebfull · 2017-08-11T16:39:49Z

src/bls12_381/ec.rs

+        for _ in 0 .. 20 {
+            let t = Fq::rand(&mut rng);
+            let p = G1Affine::hash(t);
+            assert!(G1Affine::is_on_curve(&p));


This can be just p.is_on_curve().

ebfull · 2017-08-11T16:41:09Z

src/bls12_381/ec.rs

+            }
+        }
+
+        /// Maps any elliptic curve point to the subgroup G2,


Well, it cannot map points from small subgroups into the G2 subgroup. I would rather call this scale_by_cofactor.

ebfull · 2017-08-11T16:42:54Z

src/bls12_381/fq.rs

+        else if s == Fq::one() { QResidue }
+        else { QNonResidue }
+    }
+
    fn sqrt(&self) -> Option<Self> {
        // Shank's algorithm for q mod 4 = 3
        // https://eprint.iacr.org/2012/685.pdf (page 9, algorithm 2)


This can be left to another PR btw.

bmerge · 2017-08-11T16:49:37Z

💔 Test failed - pairing-linux64-try

ebfull · 2017-08-11T16:53:40Z

Don't worry; that test failure has nothing to do with you. It's our clippy lints failing to compile on the latest nightly Rust. If you want, change Cargo.toml to use clippy version 0.0.150 and I can try again.

edit: actually, this would be a rabbit hole. Don't do it yet.

ebfull · 2017-08-11T17:07:40Z

(By the way, all of the other tests passed just fine.)

ebfull · 2017-08-11T17:29:53Z

There has to be something in the literature (like this paper) which we can apply here to avoid the huge G2 cofactor scaling.

ebfull · 2017-08-12T16:52:33Z

As @mmaker mentioned, the paper says:

We also assume that q ≡ 7 (mod 12) and that g(1) = 1 + b is a nonzero square in Fq.

I cannot tell if these assumptions are important or relied on strongly by the paper, but they aren't satisfied by BLS12-381. Fq(5) is nonsquare in Fq, and for G2, q^2 is 1 mod 12. (Perhaps the paper made a typo and meant for p to be 7 mod 12?)

One of the advantages of BLS12-381 is that all of the curve constants can be determined uniquely by a single parameter, which happens also to be part of a subfamily of parameters that are good candidates for standardization.

However, if we're willing to forgo this, we could get this hashing to work for G1 by using a different isomorphism. Barreto pointed out to me many months ago, with regards to BLS12-381:

there's a nicer isomorphic curve, E(F_p): y^2 = x^3 + 24, that admits G = h*(1, 5) as the generator for group G_1.

And of course, with Fq(25) being a nonzero square, it satisfies the assumptions of this paper. But since you still don't get G2 hashing with this... it's probably not worth it.

I would much rather implement hashing via a "try-and-increment" algorithm as suggested in the BLS signatures paper. This also avoids problems with points of small order.

mmaker · 2017-08-13T10:25:00Z

I cannot tell if these assumptions are important or relied on strongly by the paper, but they aren't satisfied by BLS12-381.

Going after the introduction to section 2:

Later works such as [31] use a different point as the generator, and the corresponding
construction does no longer ensure that 1 + b is a square. This only causes a minor inconvenience for our purposes, namely two extra elements of Fq that have to be treated separately in the encoding given in Section 3.

What happens in section 3 is that we have to handle the cases t = 0 and t^2+b+1 = 0 separately (see page 8, when giving a rational parametrization of the conic), mapping them to arbitrary points.

In fact, they already do this in Definition 2 for t = 0: they construct a nice map from Fq* to the curve, and they "program" the encoding for the case t = 0 reducing it to one of the cases already handled:

The encoding can be extended to all of Fq by sending 0 to some arbitrary point in E(Fq). Since
x1 is well-defined […]

I added a commit that does exately that (mapping to arbitrary points), in case you were interested in checking it out anyway.

I would much rather implement hashing via a "try-and-increment" algorithm as suggested in the BLS signatures paper. This also avoids problems with points of small order.

Alright, I can give it a shot and benchmark the two. Could you please pretty please bear with me and just take a look at both? This way we have some comparative terms.

ebfull · 2017-08-13T17:56:48Z

Hm, the way we would implement "try-and-increment" could vary. @daira might have some good ideas.

We'd like to be able to "hash to" Fr and Fq elements for the purpose of both hashing to BLS12-381 and hashing to constants/embedded curves for zk-SNARKs. I suppose we can build "hashing to" Fq2 and the curve on top of this.

I'm prepared to bite the bullet and let BLAKE2b be a dependency of pairing. :)

ebfull · 2017-08-13T17:59:10Z

src/bls12_381/ec.rs


                // w = (t^2 + b + 1)^(-1) * sqrt(-3) * t
                let mut w = t;
                w.square();
                w.add_assign(&Self::get_coeff_b());
                w.add_assign(&Self::Base::one());
+                // handle the case t^2 + b + 1 == 0
+                if w.is_zero() { return infty };


Just return Self::zero()

ebfull · 2018-03-31T05:53:54Z

@bmerge try

bmerge · 2018-03-31T05:54:00Z

⌛ Trying commit 3ce634a with merge 54b48e1...

@zmanian

Add hashing into the curve. Hello. A few days ago @zmanian said it'd be nice if somebody added hashing to the curve to `pairing`, and I found myself with a few spare days in bed, soo… I'd like to propose the folllowing changes: - Add Legendre symbol for Fq and Fq2, with test cases - Implement Foque-Ticouchi's hashing to the curve algorithm The algorithm is pretty much along the lines of https://github.com/herumi/mcl/blob/9fbc54305d01b984e39d83e96bfa94bb17648a86/include/mcl/bn.hpp#L65-L127 , as suggested by @zmanian.

bmerge · 2018-03-31T06:21:25Z

☀️ Test successful - pairing-linux32-try, pairing-linux64-try, pairing-windows32msvc-try, pairing-windows64msvc-try
State: approved= try=True

ebfull · 2018-03-31T17:06:42Z

src/bls12_381/ec.rs

@@ -10,6 +10,15 @@ macro_rules! curve_impl {
        $compressed:ident,
        $pairing:ident
    ) => {
+
+        fn y2_from_x(x: $basefield) -> $basefield {


I don't know if this change still needs to be in this PR anymore, it could be separate. I don't think y2_from_x is used directly in sw_encode etc. anymore. But, it's not a bad refactoring.

(Does not block this PR.)

ebfull · 2018-03-31T17:08:15Z

src/bls12_381/ec.rs

+                // x3 = 1/w^2 + 1
+                let mut x3 = w;
+                x3.square();
+                x3 = x3.inverse().unwrap();


I suspect this inverse could be optimized away. (Does not block this PR.)

1/w^2 is w^(q-4). Trouble is, this is much slower than egcd inverse.

Unless you have completely different formula for x3 in mind.

A = t^2

B = A + b + 1

C = 3 * A

D = B * C

E = D^(-1)

F = E * B makes for F = 1/(3t^2)

G = E * C makes for G = 1/(t^2 + b + 1)

I don't have time to write the rest of the formulas out, but I think that's one inversion that gets you everything you need.

ebfull · 2018-03-31T17:10:16Z

src/bls12_381/ec.rs

+        let p = G1Affine::sw_encode(t);
+        assert!(p.is_on_curve());
+        assert!(!p.is_zero());
+        assert_eq!(p.y.parity(), t.parity());


Oh, we should check assert_eq!(p, G1::one()) since these are well-defined edge cases.

ebfull · 2018-03-31T17:21:32Z

@bmerge try

bmerge · 2018-03-31T17:21:38Z

⌛ Trying commit a3bbece with merge d9f9b95...

@zmanian

Add hashing into the curve. Hello. A few days ago @zmanian said it'd be nice if somebody added hashing to the curve to `pairing`, and I found myself with a few spare days in bed, soo… I'd like to propose the folllowing changes: - Add Legendre symbol for Fq and Fq2, with test cases - Implement Foque-Ticouchi's hashing to the curve algorithm The algorithm is pretty much along the lines of https://github.com/herumi/mcl/blob/9fbc54305d01b984e39d83e96bfa94bb17648a86/include/mcl/bn.hpp#L65-L127 , as suggested by @zmanian.

bmerge · 2018-03-31T17:49:51Z

☀️ Test successful - pairing-linux32-try, pairing-linux64-try, pairing-windows32msvc-try, pairing-windows64msvc-try
State: approved= try=True

burdges · 2018-08-19T09:37:11Z

What is the status of this? As written, ff wants to take over much of this, but not sure if that's optimal.

dignifiedquire · 2018-11-02T17:43:31Z

@ebfull any update on the status of this and the intent of moving forward with it? Looks like I could really use this. Is it only a matter of using this as a baseline and making a PR on ff?

ebfull · 2019-04-09T03:44:55Z

I'm sorry that I haven't revisited this. This PR was in excellent shape prior to some modifications to master, and we've begun an effort to refactor the implementations which has put this on the sideline. (Zcash itself doesn't need hashing to the curve, but it's an absolute requirement for BLS signatures.)

I will try to revisit this in our new implementation of BLS12-381 which is an ongoing WIP and I'll update this thread with more info as soon as I have it.

paberr · 2019-04-27T17:43:38Z

While looking for an implementation of BLS signatures using BLS12-381, I stumbled across this PR after reading through the code of the bls crate.

There seems to be some pretty new work by Wahby and Boneh on "Fast and simple constant-time hashing to the BLS12-381 elliptic curve".
Are you already aware of this work and how does their Shallue–van de Woestijne map differ from your adaption?

mmaker · 2019-04-28T10:00:33Z

hey, yes I'm aware though I still have to look into that - I'm really sorry it's taking me so long.
Anyhoo SWU map aside, I already did some work on the fast cofactor multiplication here #102 which is what Boneh also is suggesting

Optimise Boolean::enforce_equal.

Sapling proving and verifying API

tuxxy · 2020-10-12T12:43:23Z

So what's the deal with this being closed? Are there any plans to add hash_to_curve support in this lib?

…/pairing#30

…/pairing#30.

str4d · 2021-02-22T18:03:32Z

@tuxxy no; this PR was closed because this crate no longer contains an implementation of BLS12-381. Hash-to-curve would need to be added to the bls12_381 crate instead.

daira reviewed Aug 10, 2017

View reviewed changes

mmaker force-pushed the master branch from c64c681 to b70696d Compare August 10, 2017 20:40

daira reviewed Aug 11, 2017

View reviewed changes

mmaker force-pushed the master branch 3 times, most recently from 2b1e33e to 84c9a83 Compare August 11, 2017 14:58

ebfull reviewed Aug 11, 2017

View reviewed changes

mmaker force-pushed the master branch from eb7b0ce to 832648a Compare August 13, 2017 10:06

ebfull reviewed Aug 13, 2017

View reviewed changes

ebfull requested review from daira and ebfull March 31, 2018 06:25

ebfull requested changes Mar 31, 2018

View reviewed changes

Test the degenerate cases for G1 sw_encode more thoroughly.

a3bbece

ebfull approved these changes Mar 31, 2018

View reviewed changes

mariano54 mentioned this pull request Sep 18, 2018

Fouque tibouchi Chia-Network/bls-signatures#19

Merged

dignifiedquire mentioned this pull request Jan 21, 2019

Avoiding forks and workarounds for known fixes for zkcrypto libraries filecoin-project/research#53

Closed

meyer9 mentioned this pull request May 1, 2019

constant time hashing algorithms? pairingwg/bls_standard#11

Open

This was referenced Jun 14, 2019

Hashing to G1/G2/Fr/Fq/Fq2 #56

Open

Adopt the IRTF CFRG draft standard w3f/bls#5

Open

str4d pushed a commit that referenced this pull request Apr 30, 2020

Merge pull request #30 from plutomonkey/boolean_enforce_equal

3c07a2d

Optimise Boolean::enforce_equal.

str4d pushed a commit that referenced this pull request Apr 30, 2020

Merge pull request #30 from str4d/sapling-api-cleanup

f65c37e

Sapling proving and verifying API

ebfull closed this Sep 8, 2020

mmaker added a commit to mmaker/bls12_381 that referenced this pull request Oct 27, 2020

Port (with bugs and no tests) my hashing into the curve from zkcrypto…

6847ced

…/pairing#30

mmaker added a commit to mmaker/bls12_381 that referenced this pull request Oct 27, 2020

Port (with bugs and no tests) my hashing into the curve from zkcrypto…

c4600d1

…/pairing#30.

Add hashing into the curve. #30

Add hashing into the curve. #30

Conversation

mmaker commented Aug 10, 2017 • edited Loading

ebfull commented Aug 10, 2017 • edited Loading

ebfull commented Aug 10, 2017

ebfull commented Aug 10, 2017

daira commented Aug 10, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mmaker commented Aug 10, 2017 • edited Loading

mmaker commented Aug 10, 2017

mmaker commented Aug 10, 2017 • edited Loading

zmanian commented Aug 10, 2017 • edited Loading

mmaker commented Aug 10, 2017 • edited Loading

ebfull commented Aug 11, 2017

daira left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mmaker Aug 11, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ebfull commented Aug 11, 2017

bmerge commented Aug 11, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bmerge commented Aug 11, 2017

ebfull commented Aug 11, 2017 • edited Loading

ebfull commented Aug 11, 2017

ebfull commented Aug 11, 2017

ebfull commented Aug 12, 2017 • edited Loading

mmaker commented Aug 13, 2017 • edited Loading

ebfull commented Aug 13, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ebfull commented Mar 31, 2018

bmerge commented Mar 31, 2018

bmerge commented Mar 31, 2018

ebfull Mar 31, 2018 • edited Loading

Choose a reason for hiding this comment

ebfull Mar 31, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ebfull Apr 2, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ebfull commented Mar 31, 2018

mmaker commented Aug 10, 2017 •

edited

Loading

ebfull commented Aug 10, 2017 •

edited

Loading

daira commented Aug 10, 2017 •

edited

Loading

mmaker commented Aug 10, 2017 •

edited

Loading

mmaker commented Aug 10, 2017 •

edited

Loading

zmanian commented Aug 10, 2017 •

edited

Loading

mmaker commented Aug 10, 2017 •

edited

Loading

mmaker Aug 11, 2017 •

edited

Loading

ebfull commented Aug 11, 2017 •

edited

Loading

ebfull commented Aug 12, 2017 •

edited

Loading

mmaker commented Aug 13, 2017 •

edited

Loading

ebfull commented Aug 13, 2017 •

edited

Loading

ebfull Mar 31, 2018 •

edited

Loading

ebfull Mar 31, 2018 •

edited

Loading

ebfull Apr 2, 2018 •

edited

Loading

burdges commented Aug 19, 2018 •

edited

Loading

mmaker commented Apr 28, 2019 •

edited

Loading