e5de454609 tests: Add Wycheproof ECDSA vectors (RandomLattice)
Pull request description:
This PR adds a test using the Wycheproof vectors as outlined in #1106. We add all 463 ECDSA test vectors. These vectors cover:
- edge cases in arithmetic operations
- signatures with special values for (r,s) that should be rejected
- special cases of public keys
The vectors are pulled from the Wycheproof project using a python script to emit C code.
All the new ECDSA Wycheproof vectors pass.
ACKs for top commit:
sipa:
ACK e5de454609
real-or-random:
ACK e5de454609
Tree-SHA512: e9684f14ff3f5225a4a4949b490e07527d559c28aa61ed03c03bc52ea64785f0b80b9e1b1628665eacf24006526271ea0fb108629c9c3c1d758e52d214a056f1
Adds a test using the Wycheproof vectors as outlined in #1106. The
vectors are taken from the Wycheproof repo. We use a python script
to convert the JSON-formatted vectors into C code.
Co-authored-by: Sean Andersen <6730974+andozw@users.noreply.github.com>
4a496a36fb ct: Use volatile "trick" in all fe/scalar cmov implementations (Tim Ruffing)
Pull request description:
Apparently clang 15 is able to compile our cmov code into a branch, at least for fe_cmov and fe_storage_cmov. This commit makes the condition volatile in all cmov implementations (except ge but that one only calls into the fe impls).
This is just a quick fix. We should still look into other methods, e.g., asm and #457. We should also consider not caring about constant-time in scalar_low_impl.h
We should also consider testing on very new compilers in nightly CI, see https://github.com/bitcoin-core/secp256k1/pull/864#issuecomment-769211867
ACKs for top commit:
jonasnick:
ACK 4a496a36fb
Tree-SHA512: a6010f9d752e45f01f88b804a9b27e77caf5ddf133ddcbc4235b94698bda41c9276bf588c93710e538250d1a96844bcec198ec5459e675f166ceaaa42da921d5
Apparently clang 15 is able to compile our cmov code into a branch,
at least for fe_cmov and fe_storage_cmov. This commit makes the
condition volatile in all cmov implementations (except ge but that
one only calls into the fe impls).
This is just a quick fix. We should still look into other methods,
e.g., asm and #457. We should also consider not caring about
constant-time in scalar_low_impl.h
We should also consider testing on very new compilers in nightly CI,
see https://github.com/bitcoin-core/secp256k1/pull/864#issuecomment-769211867
5bb03c2911 Replace `SECP256K1_ECMULT_TABLE_VERIFY` macro by a function (Hennadii Stepanov)
4429a8c218 Suppress `-Wunused-parameter` when building for coverage analysis (Hennadii Stepanov)
Pull request description:
ACKs for top commit:
real-or-random:
utACK 5bb03c2911
jonasnick:
ACK 5bb03c2911
Tree-SHA512: 19a395434ecefea201a03fc45b3f0b88f1520908926ac1207bbc6570034b1141b49c3c98e66819dcd9069dfdd28c7c6fbe957f13fb6bd178fd57ce65bfbb8fbd
fd2a408647 Set ARM ASM symbol visibility to `hidden` (Hennadii Stepanov)
Pull request description:
Solves one item in #1181.
To test on arm-32bit hardware, run:
```
$ ./autogen.sh && ./configure --enable-experimental --with-asm=arm && make
```
On master branch (427bc3cdcf):
```
$ nm -D .libs/libsecp256k1.so | grep secp256k1_fe
0000e2bc T secp256k1_fe_mul_inner
0000e8dc T secp256k1_fe_sqr_inner
```
With this PR:
```
$ nm -D .libs/libsecp256k1.so | grep secp256k1_fe | wc -l
0
```
For reference, see https://sourceware.org/binutils/docs/as/Hidden.html.
ACKs for top commit:
theuni:
ACK fd2a408647.
sipa:
ACK fd2a408647
Tree-SHA512: abf8ad332631672c036844f69c5599917c49e12c4402bf9066f93a692d3007b1914bd3eea8f83f0141c1b09d5c88ebc5e6c8bfbb5444b7b3471749f7b901ca59
4ebd82852d Apply Checks only in VERIFY mode. (roconnor-blockstream)
Pull request description:
This is already done in `field_5x52_impl.h`.
ACKs for top commit:
sipa:
ACK 4ebd82852d
jonasnick:
ACK 4ebd82852d
Tree-SHA512: c24211e5219907e41e2c5792255734bd50ca5866a4863abbb3ec174ed92d1792dd10563a94c08e8fecd6cdf776a9c49ca87e8f9806a023d9081ecc0d55ae3e66
5d8f53e312 Remove redudent checks. (Russell O'Connor)
Pull request description:
These abs checks are implied by the subsequent line, and with the subsequent line written as it is, no underflow is possible with signed integers.
Follows up on https://github.com/bitcoin-core/secp256k1/pull/1218.
ACKs for top commit:
sipa:
utACK 5d8f53e312
real-or-random:
ACK 5d8f53e312
Tree-SHA512: ddd6758638fe634866fdaf900224372e2e51cb81ef4d024f169fbc39fff38ef1b29e90e0732877e8910158b82bc428ee9c3a4031882c2850b22ad87cc63ee305
The implementation calls the secp256k1_modinvNN_jacobi_var code, falling back
to computing a square root in the (extremely rare) case it failed converge.
This introduces variants of the divsteps-based GCD algorithm used for
modular inverses to compute Jacobi symbols. Changes compared to
the normal vartime divsteps:
* Only positive matrices are used, guaranteeing that f and g remain
positive.
* An additional jac variable is updated to track sign changes during
matrix computation.
* There is (so far) no proof that this algorithm terminates within
reasonable amount of time for every input, but experimentally it
appears to almost always need less than 900 iterations. To account
for that, only a bounded number of iterations is performed (1500),
after which failure is returned. In VERIFY mode a lower iteration
count is used to make sure that callers exercise their fallback.
* The algorithm converges to f=g=gcd(f0,g0) rather than g=0. To keep
this test simple, the end condition is f=1, which won't be reached
if started with non-coprime or g=0 inputs. Because of that we only
support coprime non-zero inputs.
e089eecc1e group: Further simply gej_add_ge (Tim Ruffing)
ac71020ebe group: Save a normalize_to_zero in gej_add_ge (Tim Ruffing)
Pull request description:
As discovered by sipa in #1033.
See commit message for reasoning but note that the infinity handling will be replaced in the second commit again.
ACKs for top commit:
sipa:
ACK e089eecc1e
apoelstra:
ACK e089eecc1e
Tree-SHA512: fb1b5742e73dd8b2172b4d3e2852490cfd626e8673b72274d281fa34b04e9368a186895fb9cd232429c22b14011df136f4c09bdc7332beef2b3657f7f2798d66
scalar_split_lambda requires that the input pointer is different to both output
pointers. Without this fix, the internal benchmarks crash when compiled with
-DVERIFY.
This was introduced in commit 362bb25608 (which
requires configuring with --enable-endomorphism to exhibit the crash).
e39d954f11 tests: Add CHECK_ILLEGAL(_VOID) macros and use in static ctx tests (Tim Ruffing)
61841fc9ee contexts: Forbid randomizing secp256k1_context_static (Tim Ruffing)
4b6df5e33e contexts: Forbid cloning/destroying secp256k1_context_static (Tim Ruffing)
Pull request description:
As discussed in #1126.
For randomization, this has a history. Initially, this threw the illegal callback but then we changed it to be a no-op on non-signing contexts: 6198375218 But this was with (non-static) none/verification contexts in mind, not with the static context. If we anyway forbid cloning the static context, you should never a way to randomize a copy of the static context. (You need a copy because the static context itself is not writable. But you cannot obtain a copy except when using memcpy etc.)
ACKs for top commit:
sipa:
utACK e39d954f11
apoelstra:
ACK e39d954f11
Tree-SHA512: dc804b15652d536b5d67db7297ac0e65eab3a64cbb35a9856329cb87e7ea0fe8ea733108104b3bba580077fe03d6ad6b161c797cf866a74722bab7849f0bb60c
8f51229e03 ctime_tests: improve output when CHECKMEM_RUNNING is not defined (Jonas Nick)
Pull request description:
When seeing the output
```
Unless compiled under msan, this test can only usefully be run inside valgrind.
```
I thought that I would have to go back to the `configure` output to manually check if it was compiled under memsan to determine whether this test can be usefully run outside valgrind. But when we go into this branch then it was definitely not compiled under msan, which means that we can make the output clearer.
ACKs for top commit:
sipa:
utACK 8f51229e03
real-or-random:
utACK 8f51229e03
Tree-SHA512: a4953a158b1375d8fc3a2ee29e7014c5399becf5f75ffd3765c0141861e092fbc120003e00dfd25ec54b92a466e133377b96d5a9f4017c100aaf64fb9a045df1
Adding U to the magic constants ensures that we are not mixing unsigned and signed value during multiplication, and ensures that the multiplication will not be subject to integer promotion.
The (uint32_t)/(uint64_t) casts ensure the values are properly truncated no matter the size of an int.
Prior to this commit, if secp256k1_ctz32_var_debruijn were some how managed to be built on a platform with 64-bit ints, (though this function is specifically only intended to be used on 32-bit platforms) it would perform an out-of-bounds array access.
ce60785b26 Introduce SECP256K1_B macro for curve b coefficient (Pieter Wuille)
4934aa7995 Switch to exhaustive groups with small B coefficient (Pieter Wuille)
Pull request description:
This has the advantage that in the future, multiplication with B can be done using `secp256k1_fe_mul_int` rather than the slower `secp256k1_fe_mul`.
ACKs for top commit:
real-or-random:
ACK ce60785b26 also ran the exhaustive tests with the group of size 7
apoelstra:
ACK ce60785b26
Tree-SHA512: 006041189d18319ddb9c0ed54e479f393b83ab2a368d198bd24860d1d2574c0c1a311aea24fbef2e74bb7859a687dfc803b9e963e6dc5c61cb707e20f52b5a70
