-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safegcd inverses, drop Jacobi symbols, remove libgmp #831
Conversation
Ping @peterdettman I made the following change to avoid signed overflow: diff --git a/src/field_10x26_impl.h b/src/field_10x26_impl.h
index d5ff75c..a2c16a6 100644
--- a/src/field_10x26_impl.h
+++ b/src/field_10x26_impl.h
@@ -1362,7 +1362,7 @@ static void secp256k1_fe_update_de_30(int32_t *d, int32_t *e, const int32_t *t)
/* P == 2^256 - 2^32 - C30 */
const int64_t C30 = 0x3D1L;
/* I30 == -P^-1 mod 2^30 */
- const int32_t I30 = 0x12253531L;
+ const uint32_t I30 = 0x12253531L;
const int32_t M30 = (int32_t)(UINT32_MAX >> 2);
const int32_t u = t[0], v = t[1], q = t[2], r = t[3];
int32_t di, ei, md, me;
@@ -1377,8 +1377,8 @@ static void secp256k1_fe_update_de_30(int32_t *d, int32_t *e, const int32_t *t)
/* Calculate the multiples of P to add, to zero the 30 bottom bits. We choose md, me
* from the centred range [-2^29, 2^29) to keep d, e within [-2^256, 2^256). */
- md = (I30 * 4 * (int32_t)cd) >> 2;
- me = (I30 * 4 * (int32_t)ce) >> 2;
+ md = ((int32_t)(I30 * 4 * (uint32_t)cd)) >> 2;
+ me = ((int32_t)(I30 * 4 * (uint32_t)ce)) >> 2;
cd -= (int64_t)C30 * md;
ce -= (int64_t)C30 * me;
diff --git a/src/field_5x52_impl.h b/src/field_5x52_impl.h
index 2e81fc2..8f7d290 100644
--- a/src/field_5x52_impl.h
+++ b/src/field_5x52_impl.h
@@ -663,7 +663,7 @@ static void secp256k1_fe_update_de_62(int64_t *d, int64_t *e, const int64_t *t)
/* P == 2^256 - C62 */
const int64_t C62 = 0x1000003D1LL;
/* I62 == -P^-1 mod 2^62 */
- const int64_t I62 = 0x1838091DD2253531LL;
+ const uint64_t I62 = 0x1838091DD2253531LL;
const int64_t M62 = (int64_t)(UINT64_MAX >> 2);
const int64_t d0 = d[0], d1 = d[1], d2 = d[2], d3 = d[3], d4 = d[4];
const int64_t e0 = e[0], e1 = e[1], e2 = e[2], e3 = e[3], e4 = e[4];
@@ -676,8 +676,8 @@ static void secp256k1_fe_update_de_62(int64_t *d, int64_t *e, const int64_t *t)
/* Calculate the multiples of P to add, to zero the 62 bottom bits. We choose md, me
* from the centred range [-2^61, 2^61) to keep d, e within [-2^256, 2^256). */
- md = (I62 * 4 * (int64_t)cd) >> 2;
- me = (I62 * 4 * (int64_t)ce) >> 2;
+ md = ((int64_t)(I62 * 4 * (uint64_t)cd)) >> 2;
+ me = ((int64_t)(I62 * 4 * (uint64_t)ce)) >> 2;
cd -= (int128_t)C62 * md;
ce -= (int128_t)C62 * me;
diff --git a/src/scalar_4x64_impl.h b/src/scalar_4x64_impl.h
index 5dfa742..b649928 100644
--- a/src/scalar_4x64_impl.h
+++ b/src/scalar_4x64_impl.h
@@ -1113,7 +1113,7 @@ static uint64_t secp256k1_scalar_divsteps_62_var(uint64_t eta, uint64_t f0, uint
static void secp256k1_scalar_update_de_62(int64_t *d, int64_t *e, const int64_t *t) {
/* I62 == -P^-1 mod 2^62 */
- const int64_t I62 = 0x0B0DFF665588B13FLL;
+ const uint64_t I62 = 0x0B0DFF665588B13FLL;
const int64_t M62 = (int64_t)(UINT64_MAX >> 2);
const int64_t P[5] = { 0x3FD25E8CD0364141LL, 0x2ABB739ABD2280EELL, -0x15LL, 0, 256 };
const int64_t d0 = d[0], d1 = d[1], d2 = d[2], d3 = d[3], d4 = d[4];
@@ -1127,8 +1127,8 @@ static void secp256k1_scalar_update_de_62(int64_t *d, int64_t *e, const int64_t
/* Calculate the multiples of P to add, to zero the 62 bottom bits. We choose md, me
* from the centred range [-2^61, 2^61) to keep d, e within [-2^256, 2^256). */
- md = (I62 * 4 * (int64_t)cd) >> 2;
- me = (I62 * 4 * (int64_t)ce) >> 2;
+ md = ((int64_t)(I62 * 4 * (uint64_t)cd)) >> 2;
+ me = ((int64_t)(I62 * 4 * (uint64_t)ce)) >> 2;
cd += (int128_t)P[0] * md;
ce += (int128_t)P[0] * me;
diff --git a/src/scalar_8x32_impl.h b/src/scalar_8x32_impl.h
index 40fcaf7..66c4494 100644
--- a/src/scalar_8x32_impl.h
+++ b/src/scalar_8x32_impl.h
@@ -914,7 +914,7 @@ static uint32_t secp256k1_scalar_divsteps_30_var(uint32_t eta, uint32_t f0, uint
static void secp256k1_scalar_update_de_30(int32_t *d, int32_t *e, const int32_t *t) {
/* I30 == -P^-1 mod 2^30 */
- const int32_t I30 = 0x1588B13FL;
+ const uint32_t I30 = 0x1588B13FL;
const int32_t P[9] = { 0x10364141L, 0x3F497A33L, 0x348A03BBL, 0x2BB739ABL, -0x146L,
0, 0, 0, 65536 };
const int32_t M30 = (int32_t)(UINT32_MAX >> 2);
@@ -930,8 +930,8 @@ static void secp256k1_scalar_update_de_30(int32_t *d, int32_t *e, const int32_t
/* Calculate the multiples of P to add, to zero the 30 bottom bits. We choose md, me
* from the centred range [-2^29, 2^29) to keep d, e within [-2^256, 2^256). */
- md = (I30 * 4 * (int32_t)cd) >> 2;
- me = (I30 * 4 * (int32_t)ce) >> 2;
+ md = ((int32_t)(I30 * 4 * (uint32_t)cd)) >> 2;
+ me = ((int32_t)(I30 * 4 * (uint32_t)ce)) >> 2;
cd += (int64_t)P[0] * md;
ce += (int64_t)P[0] * me; With that, all tests pass when compiled with |
59d69a3
to
4ad49c8
Compare
I want to rework this a bit still, introducing structs for the signed-limb and transformation-matrix for clarify, and adding comments to explain my own understanding. Marking as draft for now, but it can be built/benchmarked/tested already. |
I added a commit that introduces shared modinv* files with the bulk of the algorithm, which is then used by both scalar and field code. I measure around a 1% slowdown for the variable-time versions, but a 2% speedup for the constant-time version with this (?!). I'd be interested to hear what benchmarks others see with/without the last commit. |
(only testing 64bit) I see very little change apart from field_inverse getting noticeably slower (4%), which is presumably down to no longer having the nice prime shape baked in to _update_de_62. |
@peterdettman Oh, I see - you're saying that these aren't invariants that hold for all signed62 values; of course. This _verify function is a bit of a leftover - it should just be inlined back into the _from_signedXX functions, as that's where this strict condition is required. An internal _verify function may be helpful too, but would need to be less strict. |
Rebased on top of the endomorphism changes, included the recent fixes from sipa#6, squashed the implementation commits, removed the I'd like to make a few more changes, adding checks for the ranges of variables and additional comments, but if someone is interested I think this is pretty close to done otherwise. |
@peterdettman I had to make these additional changes to satisfy ubsan (they were actually invoking UB, I believe): diff --git a/src/modinv32.h b/src/modinv32.h
index 74fc3fd8..d46447b1 100644
--- a/src/modinv32.h
+++ b/src/modinv32.h
@@ -22,7 +22,7 @@ typedef struct {
secp256k1_modinv32_signed30 modulus;
/* modulus^{-1} mod 2^30 */
- int32_t modulus_inv30;
+ uint32_t modulus_inv30;
} secp256k1_modinv32_modinfo;
static void secp256k1_modinv32(secp256k1_modinv32_signed30 *x, const secp256k1_modinv32_modinfo *modinfo);
diff --git a/src/modinv32_impl.h b/src/modinv32_impl.h
index 2cd65557..a15bd2f9 100644
--- a/src/modinv32_impl.h
+++ b/src/modinv32_impl.h
@@ -201,8 +201,8 @@ static void secp256k1_modinv32_update_de_30(secp256k1_modinv32_signed30 *d, secp
* the range (-2.P, P), consistent with the input constraint.
*/
- md -= (modinfo->modulus_inv30 * (int32_t)cd + md) & M30;
- me -= (modinfo->modulus_inv30 * (int32_t)ce + me) & M30;
+ md -= (modinfo->modulus_inv30 * (uint32_t)cd + md) & M30;
+ me -= (modinfo->modulus_inv30 * (uint32_t)ce + me) & M30;
/* The modulus has to be odd, so we can assume it is nonzero. */
cd += (int64_t)modinfo->modulus.v[0] * md;
@@ -380,8 +380,8 @@ static void secp256k1_modinv32_var(secp256k1_modinv32_signed30 *x, const secp256
cond |= gn ^ (gn >> 31);
if (cond == 0) {
- f.v[len - 2] |= fn << 30;
- g.v[len - 2] |= gn << 30;
+ f.v[len - 2] |= (uint32_t)fn << 30;
+ g.v[len - 2] |= (uint32_t)gn << 30;
--len;
}
}
diff --git a/src/modinv64.h b/src/modinv64.h
index caff6f5a..6fea9651 100644
--- a/src/modinv64.h
+++ b/src/modinv64.h
@@ -26,7 +26,7 @@ typedef struct {
secp256k1_modinv64_signed62 modulus;
/* modulus^{-1} mod 2^62 */
- int64_t modulus_inv62;
+ uint64_t modulus_inv62;
} secp256k1_modinv64_modinfo;
static void secp256k1_modinv64(secp256k1_modinv64_signed62 *x, const secp256k1_modinv64_modinfo *modinfo);
diff --git a/src/modinv64_impl.h b/src/modinv64_impl.h
index ebf1fe7f..7ce6c909 100644
--- a/src/modinv64_impl.h
+++ b/src/modinv64_impl.h
@@ -177,8 +177,8 @@ static void secp256k1_modinv64_update_de_62(secp256k1_modinv64_signed62 *d, secp
* the range (-2.P, P), consistent with the input constraint.
...skipping...
index 2cd65557..a15bd2f9 100644
--- a/src/modinv32_impl.h
+++ b/src/modinv32_impl.h
@@ -201,8 +201,8 @@ static void secp256k1_modinv32_update_de_30(secp256k1_modinv32_signed30 *d, secp
* the range (-2.P, P), consistent with the input constraint.
*/
- md -= (modinfo->modulus_inv30 * (int32_t)cd + md) & M30;
- me -= (modinfo->modulus_inv30 * (int32_t)ce + me) & M30;
+ md -= (modinfo->modulus_inv30 * (uint32_t)cd + md) & M30;
+ me -= (modinfo->modulus_inv30 * (uint32_t)ce + me) & M30;
/* The modulus has to be odd, so we can assume it is nonzero. */
cd += (int64_t)modinfo->modulus.v[0] * md;
@@ -380,8 +380,8 @@ static void secp256k1_modinv32_var(secp256k1_modinv32_signed30 *x, const secp256
cond |= gn ^ (gn >> 31);
if (cond == 0) {
- f.v[len - 2] |= fn << 30;
- g.v[len - 2] |= gn << 30;
+ f.v[len - 2] |= (uint32_t)fn << 30;
+ g.v[len - 2] |= (uint32_t)gn << 30;
--len;
}
}
diff --git a/src/modinv64.h b/src/modinv64.h
index caff6f5a..6fea9651 100644
--- a/src/modinv64.h
+++ b/src/modinv64.h
@@ -26,7 +26,7 @@ typedef struct {
secp256k1_modinv64_signed62 modulus;
/* modulus^{-1} mod 2^62 */
- int64_t modulus_inv62;
+ uint64_t modulus_inv62;
} secp256k1_modinv64_modinfo;
static void secp256k1_modinv64(secp256k1_modinv64_signed62 *x, const secp256k1_modinv64_modinfo *modinfo);
diff --git a/src/modinv64_impl.h b/src/modinv64_impl.h
index ebf1fe7f..7ce6c909 100644
--- a/src/modinv64_impl.h
+++ b/src/modinv64_impl.h
@@ -177,8 +177,8 @@ static void secp256k1_modinv64_update_de_62(secp256k1_modinv64_signed62 *d, secp
* the range (-2.P, P), consistent with the input constraint.
*/
- md -= (modinfo->modulus_inv62 * (int64_t)cd + md) & M62;
- me -= (modinfo->modulus_inv62 * (int64_t)ce + me) & M62;
+ md -= (modinfo->modulus_inv62 * (uint64_t)cd + md) & M62;
+ me -= (modinfo->modulus_inv62 * (uint64_t)ce + me) & M62;
/* The modulus has to be odd, so we can assume it is nonzero. */
cd += (int128_t)modinfo->modulus.v[0] * md;
@@ -388,8 +388,8 @@ static void secp256k1_modinv64_var(secp256k1_modinv64_signed62 *x, const secp256
cond |= gn ^ (gn >> 63);
if (cond == 0) {
- f.v[len - 2] |= fn << 62;
- g.v[len - 2] |= gn << 62;
+ f.v[len - 2] |= (uint64_t)fn << 62;
+ g.v[len - 2] |= (uint64_t)gn << 62;
--len;
}
} |
7a5c193
to
b4721dc
Compare
@peterdettman It seems that the bounds on (u,v,q,r) after N divsteps are:
If we'd negate those coefficients, 31/63 fit in a single int{32,64}_t transformation matrix. Is there any reason why 30/62 are preferable? For the 32-bit constant time version this gains us one big step. For the variable-time version it may mean doing a group less in some cases. Some additional bounds that may help reasoning about ranges:
|
Summary: Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@5437e7b Depends on D9406. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9407
Summary: ``` These functions count the number of trailing zeroes in non-zero integers. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@de0a643 Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9401
Summary: Comes with full documentation and tests. Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@8e415ac bitcoin-core/secp256k1@d8a92fc bitcoin-core/secp256k1@151aac0 Depends on D9401. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9402
Summary: ``` This commit adds functions to verify and compare numbers in signed{30,62} notation, and uses that to do more extensive bounds checking on various variables in the modinv code. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@08d5496 Depends on D9402. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9403
…k1_fe_inverse{_var} to per-impl files Summary: Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@aa404d5 bitcoin-core/secp256k1@436281a These are move only commits in preparation for replacing the functions with their new safegcd variants. There is no change in behavior. Depends on D9403. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9404
…erses Summary: Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@1e0e885 Depends on D9404. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9405
Summary: ``` Add a new run_inverse_tests that replaces all existing field/scalar inverse tests, and tests a few identities for fixed inputs, small numbers (-999...999), random inputs (structured and unstructured), as well as comparing with the output of secp256k1_fe_inv_all_var. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@aa9cc52 Depends on D9405. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9406
Summary: Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@5437e7b Depends on D9406. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9407
Summary: ``` The whole "num" API and its libgmp-based implementation are now unused. Remove them. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@1f233b3 Depends on D9407. Test Plan: ninja all check-all Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Subscribers: majcosta Differential Revision: https://reviews.bitcoinabc.org/D9408
Summary: ``` Both the field and scalar modulus can be written in signed{30,62} notation with one or more zero limbs. Make use of this in the update_de function to avoid a few wide multiplications when that is the case. This doesn't appear to be a win in the 32-bit implementation, so only do it for the 64-bit one. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@9164a1b Depends on D9408. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9409
…ancelling g bits Summary: ``` This only seems to be a win on 64-bit platforms, so only do it there. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@b306935 Depends on D9409. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9410
…le-time update_fg_var Summary: ``` The magnitude of the f and g variables generally goes down as the algorithm progresses. Make use of this by keeping tracking how many limbs are used, and when the number becomes small enough, make use of this to reduce the complexity of arithmetic on them. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@ebc1af7#diff-91cfb587705679268ee32d45895a62884faf262add85ba385cf55f74fcd51471R32-R575 Depends on D9410. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9411
…_BENCH_ITERS Summary: Completes backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@24ad04f Depends on D9411. Test Plan: ninja bench-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9412
Summary: ``` The whole "num" API and its libgmp-based implementation are now unused. Remove them. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@1f233b3 Depends on D9407. Test Plan: ninja all check-all Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Subscribers: majcosta Differential Revision: https://reviews.bitcoinabc.org/D9408
Summary: ``` Both the field and scalar modulus can be written in signed{30,62} notation with one or more zero limbs. Make use of this in the update_de function to avoid a few wide multiplications when that is the case. This doesn't appear to be a win in the 32-bit implementation, so only do it for the 64-bit one. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@9164a1b Depends on D9408. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9409
…ancelling g bits Summary: ``` This only seems to be a win on 64-bit platforms, so only do it there. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@b306935 Depends on D9409. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9410
…le-time update_fg_var Summary: ``` The magnitude of the f and g variables generally goes down as the algorithm progresses. Make use of this by keeping tracking how many limbs are used, and when the number becomes small enough, make use of this to reduce the complexity of arithmetic on them. ``` Partial backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@ebc1af7#diff-91cfb587705679268ee32d45895a62884faf262add85ba385cf55f74fcd51471R32-R575 Depends on D9410. Test Plan: ninja check-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9411
…_BENCH_ITERS Summary: Completes backport of [[bitcoin-core/secp256k1#831 | secp256k1#831]]: bitcoin-core/secp256k1@24ad04f Depends on D9411. Test Plan: ninja bench-secp256k1 Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D9412
…ster 5c7ee1b libsecp256k1 no longer has --with-bignum= configure option (Pieter Wuille) bdca9bc Squashed 'src/secp256k1/' changes from 3967d96bf1..efad3506a8 (Pieter Wuille) cabb566 Disable certain false positive warnings for libsecp256k1 msvc build (Pieter Wuille) Pull request description: This updates our src/secp256k1 subtree to the latest upstream master. The changes include: * The introduction of safegcd-based modular inverses, reducing ECDSA signing time by 25%-30% and ECDSA verification time by 15%-17%. * [Original paper](https://gcd.cr.yp.to/papers.html) by Daniel J. Bernstein and Bo-Yin Yang * [Implementation](bitcoin-core/secp256k1#767) by Peter Dettman; [final](bitcoin-core/secp256k1#831) version * [Explanation](https://github.com/bitcoin-core/secp256k1/blob/master/doc/safegcd_implementation.md) of the algorithm using Python snippets * [Analysis](https://github.com/sipa/safegcd-bounds) of the maximum number of iterations the algorithm needs * [Formal proof in Coq](https://medium.com/blockstream/a-formal-proof-of-safegcd-bounds-695e1735a348) by Russell O'Connor, for a high-level equivalent algorithm * Removal of libgmp as an (optional) dependency (which wasn't used in the Bitcoin Core build) * CI changes (Travis -> Cirrus) * Build system improvements ACKs for top commit: laanwj: Tested ACK 5c7ee1b Tree-SHA512: ad8ac3746264d279556a4aa7efdde3733e114fdba8856dd53218588521f04d83950366f5c1ea8fd56329b4c7fe08eedf8e206f8f26dbe3f0f81852e138655431
5c7ee1b libsecp256k1 no longer has --with-bignum= configure option (Pieter Wuille) bdca9bc Squashed 'src/secp256k1/' changes from 3967d96..efad350 (Pieter Wuille) cabb566 Disable certain false positive warnings for libsecp256k1 msvc build (Pieter Wuille) Pull request description: This updates our src/secp256k1 subtree to the latest upstream master. The changes include: * The introduction of safegcd-based modular inverses, reducing ECDSA signing time by 25%-30% and ECDSA verification time by 15%-17%. * [Original paper](https://gcd.cr.yp.to/papers.html) by Daniel J. Bernstein and Bo-Yin Yang * [Implementation](bitcoin-core/secp256k1#767) by Peter Dettman; [final](bitcoin-core/secp256k1#831) version * [Explanation](https://github.com/bitcoin-core/secp256k1/blob/master/doc/safegcd_implementation.md) of the algorithm using Python snippets * [Analysis](https://github.com/sipa/safegcd-bounds) of the maximum number of iterations the algorithm needs * [Formal proof in Coq](https://medium.com/blockstream/a-formal-proof-of-safegcd-bounds-695e1735a348) by Russell O'Connor, for a high-level equivalent algorithm * Removal of libgmp as an (optional) dependency (which wasn't used in the Bitcoin Core build) * CI changes (Travis -> Cirrus) * Build system improvements ACKs for top commit: laanwj: Tested ACK 5c7ee1b Tree-SHA512: ad8ac3746264d279556a4aa7efdde3733e114fdba8856dd53218588521f04d83950366f5c1ea8fd56329b4c7fe08eedf8e206f8f26dbe3f0f81852e138655431
5c7ee1b libsecp256k1 no longer has --with-bignum= configure option (Pieter Wuille) bdca9bc Squashed 'src/secp256k1/' changes from 3967d96..efad350 (Pieter Wuille) cabb566 Disable certain false positive warnings for libsecp256k1 msvc build (Pieter Wuille) Pull request description: This updates our src/secp256k1 subtree to the latest upstream master. The changes include: * The introduction of safegcd-based modular inverses, reducing ECDSA signing time by 25%-30% and ECDSA verification time by 15%-17%. * [Original paper](https://gcd.cr.yp.to/papers.html) by Daniel J. Bernstein and Bo-Yin Yang * [Implementation](bitcoin-core/secp256k1#767) by Peter Dettman; [final](bitcoin-core/secp256k1#831) version * [Explanation](https://github.com/bitcoin-core/secp256k1/blob/master/doc/safegcd_implementation.md) of the algorithm using Python snippets * [Analysis](https://github.com/sipa/safegcd-bounds) of the maximum number of iterations the algorithm needs * [Formal proof in Coq](https://medium.com/blockstream/a-formal-proof-of-safegcd-bounds-695e1735a348) by Russell O'Connor, for a high-level equivalent algorithm * Removal of libgmp as an (optional) dependency (which wasn't used in the Bitcoin Core build) * CI changes (Travis -> Cirrus) * Build system improvements ACKs for top commit: laanwj: Tested ACK 5c7ee1b Tree-SHA512: ad8ac3746264d279556a4aa7efdde3733e114fdba8856dd53218588521f04d83950366f5c1ea8fd56329b4c7fe08eedf8e206f8f26dbe3f0f81852e138655431
2cd4e3c Drop no longer used `SECP_{LIBS,INCLUDE}` variables (Hennadii Stepanov) 613626f Drop no longer used `SECP_TEST_{LIBS,INCLUDE}` variables (Hennadii Stepanov) Pull request description: `SECP_INCLUDES`, `SECP_LIBS`, `SECP_TEST_LIBS` and `SECP_TEST_INCLUDES` were introduced in 78cd96b. The last usage of the `SECP_TEST_{LIBS,INCLUDE}` variables was removed in #983. The last usage of the `SECP_LIBS` variable was removed in #831. The last usage of the `SECP_INCLUDE` variable was removed in #1169. ACKs for top commit: sipa: utACK 2cd4e3c real-or-random: utACK 2cd4e3c Tree-SHA512: ceee39dfb74aaeaa9a1e52fba819f32cee8e08922872bca2bfd6db8575c9b4695da476a4b8e8579abb92d6484fbf461e691369b160ecbc792261dbb454349efb
5c7ee1b libsecp256k1 no longer has --with-bignum= configure option (Pieter Wuille) bdca9bc Squashed 'src/secp256k1/' changes from 3967d96..efad350 (Pieter Wuille) cabb566 Disable certain false positive warnings for libsecp256k1 msvc build (Pieter Wuille) Pull request description: This updates our src/secp256k1 subtree to the latest upstream master. The changes include: * The introduction of safegcd-based modular inverses, reducing ECDSA signing time by 25%-30% and ECDSA verification time by 15%-17%. * [Original paper](https://gcd.cr.yp.to/papers.html) by Daniel J. Bernstein and Bo-Yin Yang * [Implementation](bitcoin-core/secp256k1#767) by Peter Dettman; [final](bitcoin-core/secp256k1#831) version * [Explanation](https://github.com/bitcoin-core/secp256k1/blob/master/doc/safegcd_implementation.md) of the algorithm using Python snippets * [Analysis](https://github.com/sipa/safegcd-bounds) of the maximum number of iterations the algorithm needs * [Formal proof in Coq](https://medium.com/blockstream/a-formal-proof-of-safegcd-bounds-695e1735a348) by Russell O'Connor, for a high-level equivalent algorithm * Removal of libgmp as an (optional) dependency (which wasn't used in the Bitcoin Core build) * CI changes (Travis -> Cirrus) * Build system improvements ACKs for top commit: laanwj: Tested ACK 5c7ee1b Tree-SHA512: ad8ac3746264d279556a4aa7efdde3733e114fdba8856dd53218588521f04d83950366f5c1ea8fd56329b4c7fe08eedf8e206f8f26dbe3f0f81852e138655431
5c7ee1b libsecp256k1 no longer has --with-bignum= configure option (Pieter Wuille) bdca9bc Squashed 'src/secp256k1/' changes from 3967d96..efad350 (Pieter Wuille) cabb566 Disable certain false positive warnings for libsecp256k1 msvc build (Pieter Wuille) Pull request description: This updates our src/secp256k1 subtree to the latest upstream master. The changes include: * The introduction of safegcd-based modular inverses, reducing ECDSA signing time by 25%-30% and ECDSA verification time by 15%-17%. * [Original paper](https://gcd.cr.yp.to/papers.html) by Daniel J. Bernstein and Bo-Yin Yang * [Implementation](bitcoin-core/secp256k1#767) by Peter Dettman; [final](bitcoin-core/secp256k1#831) version * [Explanation](https://github.com/bitcoin-core/secp256k1/blob/master/doc/safegcd_implementation.md) of the algorithm using Python snippets * [Analysis](https://github.com/sipa/safegcd-bounds) of the maximum number of iterations the algorithm needs * [Formal proof in Coq](https://medium.com/blockstream/a-formal-proof-of-safegcd-bounds-695e1735a348) by Russell O'Connor, for a high-level equivalent algorithm * Removal of libgmp as an (optional) dependency (which wasn't used in the Bitcoin Core build) * CI changes (Travis -> Cirrus) * Build system improvements ACKs for top commit: laanwj: Tested ACK 5c7ee1b Tree-SHA512: ad8ac3746264d279556a4aa7efdde3733e114fdba8856dd53218588521f04d83950366f5c1ea8fd56329b4c7fe08eedf8e206f8f26dbe3f0f81852e138655431
It was removed in bitcoin-core/secp256k1#831, and results in: ```bash configure: WARNING: unrecognized options: --with-bignum ```
This is a rebased and squashed version of #767, adding safegcd-based implementations of constant-time and variable-time modular inverses for scalars and field elements, by Peter Dettman. The PR is organized as follows:
__builtin_ctz
on recent GCC and Clang, but fall back to using a software emulation using de Bruijn on other platforms). This isn't used anywhere in this commit, but does include tests.doc/safegcd_implementation.md
, as well as additional comments to the code itself. It is probably best to review this together with the previous commit (they're separated to keep authorship).