Fast isSquare / Legendre symbol / Jacobi symbol - 16.8x acceleration

[mratsim]

Upstreaming on behalf of @AlekseiVambol - original: taikoxyz#3

This implements optimized isSquare/legendre symbol as suggested in #73 (comment).

Performance

The performance improvement is an incredible 16.8x acceleration over exponentiation by (p-1)/2.

API direction

At the moment the procedure is named jacobi.

PR #77 introduced the Legendre trait.

1. AFAIK it was because exponentiation by (p-1)/2 needed to abstract away the usage of curve-specific modulus constants.
   In that case, the trait can be deleted, it should be recent enough that breakage is minimal if any (cc @huitseeker).
2. Alternatively, the legendre procedure can call jacobi instead and the Legendre trait can be preserved. Though I'm curious what's the use-case of a trait instead of a function in that case.

Implementation

After extensive testing between Bernstein-Yang and Pornin's algorithms,m it turns out that:

• Bernstein-Yang's is faster for modular inverse, hence we keep Fast modular inverse - 9.4x acceleration #83
• Pornin's is faster for Legendre, hence this PR uses the algorithm.

References:

• Writeups:
  • Perf: isSquare - constant-time Jacobi/Kronecker/Legendre symbol using fast GCD mratsim/constantine#199
  • https://github.com/bitcoin-core/secp256k1/blob/7e1bbef/doc/safegcd_implementation.md#8-from-gcds-to-jacobi-symbol
  • https://research.nccgroup.com/2020/09/28/faster-modular-inversion-and-legendre-symbol-and-an-x25519-speed-record/
• Implementations:
  • https://github.com/pornin/x25519-cm0/blob/75a53f2/src/x25519-cm0.S#L89-L155
  • https://github.com/supranational/blst/blob/711e1ee/src/no_asm.h#L996-L1085

[mratsim]

Actually speedup may not be 16.8x but only 10x, quote from original PR

The Legendre symbol is computed by the added method 10.1 times faster than by the previously existing one based on the Euler's criterion.

Note: According to the test bench in /benches/bn256_field.rs, the aforesaid performance advantage is more than 20 times, which is incorrect. The reason for this behavior of the test bench has not been found yet.

[huitseeker]

PR #77 introduced the Legendre trait.

AFAIK it was because exponentiation by (p-1)/2 needed to abstract away the usage of curve-specific modulus constants.
In that case, the trait can be deleted, it should be recent enough that breakage is minimal if any (cc @huitseeker).

To answer this part specifically: there should be no breakage, since PR #77 was not part of any released version of halo2curves (0.4.0 at the latest).

Though that should not be taken as a sign of support for a slow release schedule on my part!

[han0110]

LGTM! Thanks again for improving the library.

Although I still don't fully understand the reason of i being 30, but I don't want to block the PR. Other parts could be referenced from Computing the Jacobi symbol using Bernstein-Yang and Optimized Binary GCD for Modular Inversion.

Additional small notes for perhaps other reviewers:

1. (b ^ b >> 1) & 2 == 2 is equal to b % 8 == 3 || b % 8 == 5 when b is odd.
2. This python version might be the most unoptmized one to understand the algorithm https://gist.github.com/robot-dreams/ceb00162b80384f2ae1913aaa2b35e75 (also quoted in Perf: isSquare - constant-time Jacobi/Kronecker/Legendre symbol using fast GCD mratsim/constantine#199)

[AlekseiVambol]

LGTM! Thanks again for improving the library.

Although I still don't fully understand the reason of i being 30, but I don't want to block the PR. Other parts could be referenced from Computing the Jacobi symbol using Bernstein-Yang and Optimized Binary GCD for Modular Inversion.

Additional small notes for perhaps other reviewers:

1. `(b ^ b >> 1) & 2 == 2` is equal to `b % 8 == 3 || b % 8 == 5` when `b` is odd.

2. This python version might be the most unoptmized one to understand the algorithm https://gist.github.com/robot-dreams/ceb00162b80384f2ae1913aaa2b35e75 (also quoted in [Perf: `isSquare` - constant-time Jacobi/Kronecker/Legendre symbol using fast GCD mratsim/constantine#199](https://github.com/mratsim/constantine/issues/199))

Thank you for the review!

The python code you mentioned is not related to my modification of the Pornin's method. It seems to be the Wuille’s Bernstein-Yang-based method of Jacobi symbol computation. It is somewhat slower than the proposed method and lacks the proof of convergence. More information about this method can be found here: https://github.com/bitcoin-core/secp256k1/blob/master/doc/safegcd_implementation.md (section 8).

Regarding the number of the inner loop's iterations, which is 30 instead of 31:

The initial Pornin's method for modular inversion performs 31 iterations of the inner loop and uses "approximations" of the variables, which contain the arguments at the beginning of the algorithm's execution. These "approximations" are defined in the following way. Let n be the bit length of the largest argument without leading zeros. For n > 64 the "approximation" of the argument, which equals v, is (v div 2 ^ (n - 33)) * 2 ^ 33 + (v mod 2 ^ 31), i.e. it retains the 33 high and 31 low bits of the n-bit representation of v. If n does not exceed 64, an argument and its "approximation" are equal.

It is not hard to see, that before each of the 31 iterations of the inner loop the least significant bit of each "approximation" is the same as the least significant bit of the value that the corresponding variable would have had if it had been updated in the inner loop along with the "approximations". Let us call this value the "potential precise value". Before the first iteration of the inner loop an "approximation" and the corresponding "potential precise value" are equal modulo 2^31, before the second iteration they are equal at least modulo 2^30 and so on. the This allows the initial Pornin's method to make the correct decisions, which are related to parity checks.

However, we need an "approximation" to be equal to the corresponding "potential precise value" at least modulo 8 before each iteration to use the properties of the modified Jacobi symbol (x / |y|). The naive approach lies in performing just 29 iterations in the inner loop. However, I decided to change the "approximation" method in the terms of the used formula: here it is (v div 2 ^ (n - 32)) * 2 ^ 32 + (v mod 2 ^ 32), i.e. it retains the 32 high and 32 low bits of the n-bit representation of v. This modification allows to perform 30 iterations instead of 29. The admissibility of this modification I have proven using the appropriately modified Pornin's theorems.

PS I think I have to make a part of comments more accurate: replace

"corresponding "precise" variables' values, which would be computed, if the "precise" variables were used in the inner loop instead of the "approximation" ones."

with

"corresponding "precise" variables' values, which would have been computed, if the "precise" variables had been updated in the inner loop along with the "approximations"."

Should I do this after merging or now?

PPS Among the several improvements the most practically valuable one lies in using the short-arithmetic binary Euclidean algorithm to finish the computation, when the modified Pornin method’s "approximations" become absolutely precise.

[han0110]

The python code you mentioned is not related to my modification of the Pornin's method. It seems to be the Wuille’s Bernstein-Yang-based method of Jacobi symbol computation. It is somewhat slower than the proposed method and lacks the proof of convergence. More information about this method can be found here: https://github.com/bitcoin-core/secp256k1/blob/master/doc/safegcd_implementation.md (section 8).

Yeah I mean to understand Computing the Jacobi symbol using Bernstein-Yang the script might help, and from it to your optmized implementation is easier for myself, since I couldn't find other implementation taking the same strategy.

Before the first iteration of the inner loop an "approximation" and the corresponding "potential precise value" are equal modulo 2^31, before the second iteration they are equal at least modulo 2^30 and so on. the This allows the initial Pornin's method to make the correct decisions, which are related to parity checks. However, we need an "approximation" to be equal to the corresponding "potential precise value" at least modulo 8 before each iteration to use the properties of the modified Jacobi symbol (x / |y|).

I see it now, thanks for clarifying, I think this is what I was missing.

Should I do this after merging or now?

Feel free to do so, besides the PR needs a rebase.

[CPerezz]

LGTM!

Thanks so much for this work!