Varlen message support for the default sign function comes from recommending
tagged_sha256. sign_custom on the other hand gets the ability to directly sign
message of any length. This also implies signing and verification support for
the empty message (NULL) with msglen 0.
Tests for variable lengths follow in a later commit.
This makes the default sign function easier to use while allowing more granular
control through sign_custom.
Tests for sign_custom follow in a later commit.
9570f674cc Avoid passing out-of-bound pointers to 0-size memcpy (Pieter Wuille)
Pull request description:
Doing so could be considered UB in a pedantic interpretation of the standard. Avoid it.
Closes#876.
ACKs for top commit:
practicalswift:
cr ACK 9570f674cc729cafcba65f4cce03552d9a6108f4: patch looks correct
real-or-random:
ACK 9570f674cc
Tree-SHA512: f991462d72e39f14e609021b8427c2e6756009bc8cd21efca2da46ec9410250725a4fed662df20fcdcfd10a4dc59038f13e8c166362b2eadde4366586b9ca72b
14c9739a1f tests: Improve secp256k1_ge_set_all_gej_var for some infinity inputs (Tim Ruffing)
4a19668c37 tests: Test secp256k1_ge_set_all_gej_var for all infinity inputs (Tim Ruffing)
45b6468d7e Have secp256k1_ge_set_all_gej_var initialize all fields. Previous behaviour would not initialize r->y values in the case where infinity is passed in. Furthermore, the previous behaviour wouldn't initialize anything in the case where all inputs were infinity. (Russell O'Connor)
31c0f6de41 Have secp256k1_gej_double_var initialize all fields. Previous behaviour would not initialize r->x and r->y values in the case where infinity is passed in. (Russell O'Connor)
dd6c3de322 Have secp256k1_ge_set_gej_var initialize all fields. Previous behaviour would not initialize r->x and r->y values in the case where infinity is passed in. (Russell O'Connor)
Pull request description:
Previous behaviour would not initialize `r->x` and `r->y` values in the case where infinity is passed in.
ACKs for top commit:
gmaxwell:
ACK 14c9739a1f
sipa:
utACK 14c9739a1f
real-or-random:
ACK 14c9739a1f
Tree-SHA512: 2e779b767f02e348af4bbc62aa9871c3d1d29e61a6c643c879c49f2de27556a3588850acd2f7c7483790677597d01064025e14befdbf29e783f57996fe4430f9
Previous behaviour would not initialize r->y values in the case where infinity is passed in.
Furthermore, the previous behaviour wouldn't initialize anything in the case where all inputs were infinity.
This makes a difference with mingw builds on Wine, where the subsequent
fread() may abort early in the default text mode.
The Microsoft C docs say:
"In text mode, CTRL+Z is interpreted as an EOF character on input."
be0609fd54 Add unit tests for edge cases with delta=1/2 variant of divsteps (Pieter Wuille)
cd393ce228 Optimization: only do 59 hddivsteps per iteration instead of 62 (Pieter Wuille)
277b224b6a Use modified divsteps with initial delta=1/2 for constant-time (Pieter Wuille)
376ca366db Fix typo in explanation (Pieter Wuille)
Pull request description:
This updates the divsteps-based modular inverse code to use the modified version which starts with delta=1/2. For variable time, the delta=1 variant is still used as it appears to be faster.
See https://github.com/sipa/safegcd-bounds/tree/master/coq and https://medium.com/blockstream/a-formal-proof-of-safegcd-bounds-695e1735a348 for a proof of correctness of this variant.
TODO:
* [x] Update unit tests to include edge cases specific to this variant
I'm still running the Coq proof verification for the 590 bound in non-native mode. It's unclear how long this will take.
ACKs for top commit:
gmaxwell:
ACK be0609fd54
sanket1729:
crACK be0609fd54
real-or-random:
ACK be0609fd54 careful code review and some testing
Tree-SHA512: 2f8f400ba3ac8dbd08622d564c3b3e5ff30768bd0eb559f2c4279c6c813e17cdde71b1c16f05742c5657b5238b4d592b48306f9f47d7dbdb57907e58dd99b47a
Before this commit, gen_context.c both included libsecp256k1-config.h
and basic-config.h: The former only to obtain ECMULT_GEN_PREC_BITS
and the latter to obtain a basic working configuration to be able to
use the library.
This was inelegant and confusing: It meant that basic-config.h needs
to #undef all the macros defined in libsecp256k1-config.h. Moreover,
it meant that basic-config.h cannot define ECMULT_GEN_PREC_BITS,
essentially making this file specific for use in gen_context.c.
After this commit, gen_context.c include only libsecp256k1-config.h.
basic-config.h is not necessary anymore for the modules used in
gen_context.c because 79f1f7a made the preprocessor detect all the
relevant config options.
On the way, we remove an unused #define in basic-config.h.
Instead of using eta=-delta, use zeta=-(delta+1/2) to represent
delta. This variant only needs at most 590 iterations for 256-bit
inputs rather than 724 (by convex hull bounds analysis).
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.
Refactored by: Pieter Wuille <pieter@wuille.net>
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.
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.
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.
This adds tests for the modinv{32,64}_impl.h directly (before the functions are used
inside the field/scalar code). It uses a naive implementation of modular multiplication
and gcds in order to verify the modular inverses themselves.
This adds a long comment explaining the algorithm and implementation choices by building
it up step by step in Python.
Comments in the code are also reworked/added, with references to the long explanation.
This was detected while running the tests with the `-Wconditional-uninitialized` flag
```
./autogen.sh
CC=clang CFLAGS="-Wconditional-uninitialized" ./configure
make check
```
The resulting warning is a false positive, but setting the value to -1
ensures that the CHECK below will fail if recid is never written to.
b6f649889a Add parens around ROUND_TO_ALIGN's parameter. This makes the macro robust against a hypothetical ROUND_TO_ALIGN(foo ? sizeA : size B) invocation. (Russell O'Connor)
Pull request description:
This makes the macro robust against a hypothetical `ROUND_TO_ALIGN(foo ? sizeA : size B)` invocation.
See also <https://wiki.sei.cmu.edu/confluence/display/c/PRE01-C.+Use+parentheses+within+macros+around+parameter+names>.
ACKs for top commit:
sipa:
ACK b6f649889a. This is the way.
jonasnick:
utACK b6f649889a
real-or-random:
utACK b6f649889a
Tree-SHA512: 6a2685f959e8ae472259e5ea75fe12e8e6213f56f5aec7603a896c294e6a8833caae25c412607d9c9a3125370a7765a3e506127b101a1b87203f95e326f6c6c6
fb390c5299 Remove underscores from header defs. This makes them consistent with other files and avoids reserved identifiers. (Russell O'Connor)
Pull request description:
ACKs for top commit:
real-or-random:
utACK fb390c5299
jonasnick:
ACK fb390c5299
Tree-SHA512: f49da79c0a90d1e82494821e7cf6f61c66bc377a3f37b2d4787ef19d2126e000627bfe4a76aa1c5bfffeb1382054aa824a7e9ab5d73c19d876b0828722c73854
3c15130709 Improve CC_FOR_BUILD detection (Tim Ruffing)
47802a4762 Restructure and tidy configure.ac (Tim Ruffing)
252c19dfc6 Ask brew for valgrind include path (Tim Ruffing)
Pull request description:
See individual commit messages. These are improvements in preparation of the switch to Cirrus CI. (Maybe I'll just open a PR on top of this one.)
The first commit made the difference between successful build https://cirrus-ci.com/task/6740575057608704 and unsuccessful build https://cirrus-ci.com/task/4909571074424832.
I've tested the second commit without cross-compilation and with cross-compilation for android (https://github.com/bitcoin-core/secp256k1/issues/621#issuecomment-495703399)
When working on the autoconf stuff, I noticed two things that I just want to write down here:
- At some point we should update [build-aux/m4/ax_prog_cc_for_build.m4](https://www.gnu.org/software/autoconf-archive/ax_prog_cc_for_build.html). This is outdated, and [there have been a lot of fixes](https://github.com/autoconf-archive/autoconf-archive/pull/207) But the latest version is [broken](https://lists.gnu.org/archive/html/autoconf-archive-maintainers/2020-06/msg00002.html), so now is probably not the time.
- The latest autoconf 2.70 deprecates `AC_PROG_CC_C89`. It's not needed anymore because `AC_PROG_CC` cares about testing for version support. This makes autoconf 2.70 output a warning that we should probably just ignore. We don't want to force users onto 2.70...
ACKs for top commit:
sipa:
utACK 3c15130709
jonasnick:
utACK 3c15130 makes sense (with my very basic understanding of autoconf)
Tree-SHA512: 595b9de316374c2213f1340cddaa22eb3190b01fa99aa6ae26e77804df41e7ecf96a09e03c28e8f8b9fd04e211e4ee2f78f1e5a7995143c84f99d2e16d4f0260
33cb3c2b1f Add secret key extraction from keypair to constant time tests (Elichai Turkel)
36d9dc1e8e Add seckey extraction from keypair to the extrakeys tests (Elichai Turkel)
fc96aa73f5 Add a function to extract the secretkey from a keypair (Elichai Turkel)
Pull request description:
With schnorrsig if you need to tweak the secret key (for BIP32) you must use the keypair API to get compatible secret/public keys which you do by calling `secp256k1_keypair_xonly_tweak_add()`, but after that there's no currently a way to extract the secret key back for storage.
so I added a `secp256k1_keypair_seckey` function to extract the key
ACKs for top commit:
jonasnick:
ACK 33cb3c2b1f
real-or-random:
ACK 33cb3c2b1f code inspection, tests pass
Tree-SHA512: 11212db38c8b87a87e2dc35c4d6993716867b45215b94b20522b1b3164ca63d4c6bf5192a6bff0e9267b333779cc8164844c56669a94e9be72df9ef025ffcfd4
This commits simply uses CC as CC_FOR_BUILD and the same for
corresponding flags if we're not cross-compiling. This has a number of
benefits in this common case:
- It avoids strange cases where very old compilers are used (#768).
- Flags are consistently set for CC and CC_FOR_BUILD.
- ./configure is faster.
- You get compiler x consistently if you set CC=x; we got this wrong
in CI in the past.
./configure warns if a _FOR_BUILD variable is set but ignored because
we're not cross-compiling.
The change exposed that //-style comments are used in gen_context.c,
which is also fixed by this commit.
This commit also reorganizes code in configure.ac to have a cleaner
separation of sections.
1f4dd03838 Typedef (u)int128_t only when they're not provided by the compiler (Tim Ruffing)
e89278f211 Don't use reserved identifiers memczero and benchmark_verify_t (Tim Ruffing)
Pull request description:
As identified in #829 and #833. Fixes#829.
Since we touch this anyway, this commit additionally makes the
identifiers in the benchmark files a little bit more consistent.
This is necessary before we can merge #833. I preferred a separate PR because it makes it easier to see the results of Travis in #833.
ACKs for top commit:
sipa:
utACK 1f4dd03838
jonasnick:
ACK 1f4dd03838
Tree-SHA512: c0ec92798f3c94f3ef6ac69b3f0f39a39257a32be9d9a068832cece1ebe64c89848b70e44652fc397004b8b240883ac4bc0c8f95abbe4ba4b028de120e6734bf
29a299e373 Run the undefined behaviour sanitizer on Travis (Fabien)
7506e064d7 Prevent arithmetic on NULL pointer if the scratch space is too small (Fabien)
Pull request description:
ACKs for top commit:
sipa:
ACK 29a299e373. Reviewed the code changes and verified that building with these sanitizer flags catches the existing error, as well as a signed integer overflow if introduced.
real-or-random:
ACK 29a299e373 code inspection
jonasnick:
utACK 29a299e373
Tree-SHA512: 4d788f12f3d7b48018e884910adb9b530a05d88f504de83dadeab8a22d75da83c05a1518f7317de5f536c4dd243ea7b347b1eaddb2ca1d804c663e41b85db69d
If the user passes invalid flags to _context_create, and the default
illegal callback does not abort the program (which is possible), then we
work with the result of malloc(0), which may be undefined behavior. This
violates the promise that a library function won't crash after the
illegal callback has been called.
This commit fixes this issue by returning NULL early in _context_create
in that case.
If the scratch space is too small when calling
`secp256k1_ecmult_strauss_batch()`, the `state.pre_a` allocation will
fail and the pointer will be `NULL`. This causes `state.pre_a_lam` to be
computed from the `NULL` pointer.
It is also possible that the first allocation to fail is for `state.ps`,
which will cause the failure to occur when in
`secp256k1_ecmult_strauss_wnaf()`.
The issue has been detected by UBSAN using Clang 10:
```
CC=clang \
CFLAGS="-fsanitize=undefined -fno-omit-frame-pointer" \
LDFLAGS="-fsanitize=undefined -fno-omit-frame-pointer" \
../configure
UBSAN_OPTIONS=print_stacktrace=1:halt_on_error=1 make check
```
As identified in #829 and #833. Fixes#829.
Since we touch this anyway, this commit additionally makes the
identifiers in the benchmark files a little bit more consistent.
The VERIFY macro turns on various paranoid consistency checks, but
the complete functionality should still be tested without it.
This also adds a couple of static test points for extremely small
split inputs/outputs. The existing bounds vectors already check
extremely large outputs.
This allows us to shift by 256+128 = 384 bits, which is a multiple of the limb size of
the scalar representation. This also happens to be the most precision possible for g2
that still fits into a 256-bit value.
a45c1fa63c Rename testrand functions to have test in name (Pieter Wuille)
Pull request description:
Suggested here: https://github.com/bitcoin-core/secp256k1/pull/808#discussion_r488871913
ACKs for top commit:
real-or-random:
ACK a45c1fa63c diff looks good
elichai:
utACK a45c1fa63c
Tree-SHA512: a15c29b88877e0f1a099acab90cbfa1e70420527e07348a69c8a5b539319a3131b771b86852e772a669a1eb3475d508d0f7e10f37eec363dc6640d4eaf967536
c0041b5cfc Add static assertion that uint32_t is unsigned int or wider (Tim Ruffing)
Pull request description:
Solves one item in #792 .
ACKs for top commit:
sipa:
utACK c0041b5cfc
elichai:
ACK c0041b5cfc
Tree-SHA512: 9f700e89be39e15983260da94642593d16b9c437171e10377837ac73731ca7ba5dd7e328b3d93d0a24d143fb9e73abd11c578f6b58e2f94c82b783e977173b0c
8b7dcdd955 Add exhaustive test for extrakeys and schnorrsig (Pieter Wuille)
08d7d89299 Make pubkey parsing test whether points are in the correct subgroup (Pieter Wuille)
87af00b511 Abstract out challenge computation in schnorrsig (Pieter Wuille)
63e1b2aa7d Disable output buffering in tests_exhaustive.c (Pieter Wuille)
39f67dd072 Support splitting exhaustive tests across cores (Pieter Wuille)
e99b26fcd5 Give exhaustive_tests count and seed cmdline inputs (Pieter Wuille)
49e6630bca refactor: move RNG seeding to testrand (Pieter Wuille)
b110c106fa Change exhaustive test groups so they have a point with X=1 (Pieter Wuille)
cec7b18a34 Select exhaustive lambda in function of order (Pieter Wuille)
78f6cdfaae Make the curve B constant a secp256k1_fe (Pieter Wuille)
d7f39ae4b6 Delete gej_is_valid_var: unused outside tests (Pieter Wuille)
8bcd78cd79 Make secp256k1_scalar_b32 detect overflow in scalar_low (Pieter Wuille)
c498366e5b Move exhaustive tests for recovery to module (Pieter Wuille)
be31791543 Make group order purely compile-time in exhaustive tests (Pieter Wuille)
Pull request description:
A few miscellaneous improvements:
* Just use EXHAUSTIVE_TEST_ORDER as order everywhere, rather than a variable
* Move exhaustive tests for recovery module to the recovery module directory
* Make `secp256k1_scalar_set_b32` detect overflow correctly for scalar_low (a comment in the recovery exhaustive test indicated why this was the case, but this looks incorrect).
* Change the small test groups so that they include a point with X coordinate 1.
* Initialize the RNG seed, allowing configurating from the cmdline, and report it.
* Permit changing the number of iterations (re-randomizing for each).
* Support splitting the work across cores from the cmdline.
And a big one:
* Add exhaustive tests for schnorrsig module (and limited ones for extrakeys).
ACKs for top commit:
real-or-random:
ACK 8b7dcdd955
jonasnick:
ACK 8b7dcdd955
Tree-SHA512: 18d7f362402085238faaced164c0ca34079717a477001fc0b13448b3529ea2ad705793a13b7a36f34bf12e9231fee11070f88cc51bfc2a83ca82aa13f7aaae71
This enables testing overflow is correctly encoded in the recid, and
likely triggers more edge cases.
Also introduce a Sage script to generate the parameters.
f431b3f28a valgrind_ctime_test: Add schnorrsig_sign (Jonas Nick)
16ffa9d97c schnorrsig: Add taproot test case (Jonas Nick)
8dfd53ee3f schnorrsig: Add benchmark for sign and verify (Jonas Nick)
4e43520026 schnorrsig: Add BIP-340 compatible signing and verification (Jonas Nick)
7332d2db6b schnorrsig: Add BIP-340 nonce function (Jonas Nick)
7a703fd97d schnorrsig: Init empty experimental module (Jonas Nick)
eabd9bc46a Allow initializing tagged sha256 (Jonas Nick)
6fcb5b845d extrakeys: Add keypair_xonly_tweak_add (Jonas Nick)
58254463f9 extrakeys: Add keypair struct with create, pub and pub_xonly (Jonas Nick)
f0010349b8 Separate helper functions for pubkey_create and seckey_tweak_add (Jonas Nick)
910d9c284c extrakeys: Add xonly_pubkey_tweak_add & xonly_pubkey_tweak_add_test (Jonas Nick)
176bfb1110 Separate helper function for ec_pubkey_tweak_add (Jonas Nick)
4cd2ee474d extrakeys: Add xonly_pubkey with serialize, parse and from_pubkey (Jonas Nick)
47e6618e11 extrakeys: Init empty experimental module (Jonas Nick)
3e08b02e2a Make the secp256k1_declassify argument constant (Jonas Nick)
Pull request description:
This PR implements signing, verification and batch verification as described in [BIP-340](https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki) in an experimental module named `schnorrsig`. It includes the test vectors and a benchmarking tool.
This PR also adds a module `extrakeys` that allows [BIP-341](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki)-style key tweaking.
(Adding ChaCha20 as a CSPRNG and batch verification was moved to PR #760).
In order to enable the module run `./configure` with `--enable-experimental --enable-module-schnorrsig`.
Based on apoelstra's work.
ACKs for top commit:
gmaxwell:
ACK f431b3f28a (exactly matches the previous post-fixup version which I have already reviewed and tested)
sipa:
ACK f431b3f28a
real-or-random:
ACK f431b3f28a careful code review
Tree-SHA512: e15e849c7bb65cdc5d7b1d6874678e275a71e4514de9d5432ec1700de3ba92aa9f381915813f4729057af152d90eea26aabb976ed297019c5767e59cf0bbc693
47a7b8382f Clear field elements when writing infinity (Elichai Turkel)
61d1ecb028 Added test with additions resulting in infinity (Elichai Turkel)
Pull request description:
Currently if `secp256k1_gej_add_var` / `secp256k1_gej_add_ge_var` /` secp256k1_gej_add_zinv_var` receive `P + (-P)` it will set `gej->infinity = 1` but doesn't call initialize the field elements.
Notice that this is the only branch in the function that results in an uninitialized output.
By using `secp256k1_gej_set_infinity()` it will set the field elements to zero while also setting the infinity flag.
I also added a test that fails with valgrind on current master but passes with the fix.
EDIT: This isn't a bug or something necessary, I just personally found this helpful.
ACKs for top commit:
real-or-random:
ACK 47a7b8382f
Tree-SHA512: cdc2efc242a1b04b4f081183c07d4b2602cdba705e6b30b548df4e115e54fb97691f4b1a28f142f02d5e523c020721337a297b17d732acde147b910f5c53bd0a
8bc6aeffa9 Add SHA256 selftest (Pieter Wuille)
5e5fb28b4a Use additional system macros to figure out endianness (Pieter Wuille)
Pull request description:
These are all the architecture macros I could find with known endianness. Use those as a fallback when __BYTE_ORDER__ isn't available.
See https://github.com/bitcoin-core/secp256k1/pull/787#issuecomment-673764652
It also adds a SHA256 selftest, so that improperly overriding the endianness detection will be detected at runtime.
ACKs for top commit:
real-or-random:
ACK 8bc6aeffa9 I read the diff, and tested that the self-test passes/fails with/without the correct endianness setting
gmaxwell:
ACK 8bc6aeffa9 looks good and I also ran the tests on MIPS-BE and verified that forcing it to LE makes the runtime test fail.
Tree-SHA512: aca4cebcd0715dcf5b58f5763cb4283af238987f43bd83a650e38e127f348131692b2eed7ae5b2ae96046d9b971fc77c6ab44467689399fe470a605c3458ecc5
60f7f2de5d Don't assume that ALIGNMENT > 1 in tests (Tim Ruffing)
ada6361dec Use ROUND_TO_ALIGN in scratch_create (Jonas Nick)
8ecc6ce50e Add check preventing rounding to alignment from wrapping around in scratch_alloc (Jonas Nick)
4edaf06fb0 Add check preventing integer multiplication wrapping around in scratch_max_allocation (Jonas Nick)
Pull request description:
This PR increases the general robustness of scratch spaces. It does not fix an existing vulnerability because scratch spaces aren't used anywhere in master. Additionally, it must be prevented anyway that an attacker has (indirect) control over the arguments touched in this PR.
ACKs for top commit:
sipa:
ACK 60f7f2de5d
Tree-SHA512: ecdd794b55a01d1d6d24098f3abff34cb8bb6f33737ec4ec93714aa631c9d397b213cc3603a916ad79f4b09d6b2f8973bf87fc07b81b25a530cc72c4dbafaba9
0dccf98a21 Use preprocessor macros instead of autoconf to detect endianness (Tim Ruffing)
Pull request description:
This does not fix any particular issue but it's preferable to not
rely on autoconf. This avoids endianness mess for users on BE hosts
if they use their build without autoconf.
The macros are carefully written to err on the side of the caution,
e.g., we #error if the user manually configures a different endianness
than what we detect.
Supersedes #770 .
ACKs for top commit:
sipa:
ACK 0dccf98a21
gmaxwell:
ACK 0dccf98a21
Tree-SHA512: 6779458de5cb6eaef2ac37f9d4b8fa6c9b299f58f6e5b72f2b0d7e36c12ea06074e483acfb85085a147e0f4b51cd67d897f61a67250ec1cea284a0f7680eb2e8
This does not fix any particular issue but it's preferable to not
rely on autoconf. This avoids endianness mess for users on BE hosts
if they use their build without autoconf.
The macros are carefully written to err on the side of the caution,
e.g., we #error if the user manually configures a different endianness
than what we detect.
Instead of supporting configuration of the field and scalar size independently,
both are now controlled by the availability of a 64x64->128 bit multiplication
(currently only through __int128). This is autodetected from the C code through
__SIZEOF_INT128__, but can be overridden using configure's
--with-test-override-wide-multiply, or by defining
USE_FORCE_WIDEMUL_{INT64,INT128} manually.
So far this has not been needed, as it's only used by the static precomputation
which always builds with 32-bit fields.
This prepares for the ability to have __int128 detected on the C side, breaking
that restriction.
67a429f31f Suppress a harmless variable-time optimization by clang in _int_cmov (Tim Ruffing)
5b196338f0 Remove redundant "? 1 : 0" after comparisons in scalar code (Tim Ruffing)
Pull request description:
Attempt at resolving #771 .
This surprisingly seems to improve the situation at least for the compilers available on godbolt.
ACKs for top commit:
gmaxwell:
ACK 67a429f31f
elichai:
tACK 67a429f31f
Tree-SHA512: ee8b0c86831ec8c3d5a9abcad773ed8a0f267e5c47012e4e1423b10a64c26b4cf6e3c466c3df765ba7e636787a3fe134d633926d67b599287f12c51be924f478
37dba329c6 Remove unnecessary sign variable from wnaf_const (Jonas Nick)
6bb0b77e15 Fix test_constant_wnaf for -1 and add a test for it. (Jonas Nick)
Pull request description:
There currently is a single branch in the `ecmul_const` function that is not being exercised by the tests. This branch is unreachable and therefore I'm suggesting to remove it.
For your convenience the paper the wnaf algorithm can be found [here (The Width-w NAF Method Provides Small Memory and Fast Elliptic Scalar Multiplications Secure against Side Channel Attacks)](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.563.1267&rep=rep1&type=pdf). Similarly, unless I'm missing something important, I don't see how their algorithm needs to consider `sign(u[i-1])` unless `d` can be negative - which doesn't make much sense to me either.
ACKs for top commit:
real-or-random:
ACK 37dba329c6 I verified the correctness of the change and claimed invariant by manual inspection. I tested the code, both with 32bit and 64bit scalars.
Tree-SHA512: 9db45f76bd881d00a81923b6d2ae1c3e0f49a82a5d55347f01e1ce4e924d9a3bf55483a0697f25039c327e33edca6796ba3205c068d9f2f99aa5d655e46b15be
7e3952ae82 Clarify documentation of tweak functions. (Jonas Nick)
89853a0f2e Make tweak function documentation more consistent. (Jonas Nick)
41fc785602 Make ec_privkey functions aliases for ec_seckey_negate, ec_seckey_tweak_add and ec_seckey_mul (Jonas Nick)
22911ee6da Rename private key to secret key in public API (with the exception of function names) (Jonas Nick)
5a73f14d6c Mention that value is unspecified for In/Out parameters if the function returns 0 (Jonas Nick)
f03df0e6d7 Define valid ECDSA keys in the documentation of seckey_verify (Jonas Nick)
5894e1f1df Return 0 if the given seckey is invalid in privkey_negate, privkey_tweak_add and privkey_tweak_mul (Jonas Nick)
8f814cddb9 Add test for boundary conditions of scalar_set_b32 with respect to overflows (Jonas Nick)
3fec982608 Use scalar_set_b32_seckey in ecdsa_sign, pubkey_create and seckey_verify (Jonas Nick)
9ab2cbe0eb Add scalar_set_b32_seckey which does the same as scalar_set_b32 and also returns whether it's a valid secret key (Jonas Nick)
Pull request description:
Fixes#671. Supersedes #668.
This PR unifies handling of invalid secret keys by introducing a new function `scalar_set_b32_secret` which returns false if the b32 overflows or is 0. By using this in `privkey_{negate, tweak_add, tweak_mul}` these function will now return 0 if the secret key is invalid which matches the behavior of `ecdsa_sign` and `pubkey_create`.
Instead of deciding whether to zeroize the secret key on failure, I only added documentation for now that the value is undefined on failure.
ACKs for top commit:
real-or-random:
ACK 7e3952ae82 I read the diff carefully and tested the changes
apoelstra:
ACK 7e3952ae82
Tree-SHA512: 8e9a66799cd3b6ec1c3acb731d6778035417e3dca9300d840e2437346ff0ac94f0c9be4de20aa2fac9bb4ae2f8a36d4e6a34795a640b9cfbfee8311decb102f0
Before, test_constant_wnaf used scalar_cadd_bit to correct for the skew. But
this function does not correctly deal with overflows which is why num = -1
couldn't be tested.
This commit also adds tests for 0, 1/2 and 1/2-1 as they are corner cases
in constant_wnaf.
37ed51a7ea Make ecdsa_sig_sign constant-time again after reverting 25e3cfb (Tim Ruffing)
93d343bfc5 Revert "ecdsa_impl: replace scalar if-checks with VERIFY_CHECKs in ecdsa_sig_sign" (Tim Ruffing)
Pull request description:
ACKs for top commit:
elichai:
ACK 37ed51a7ea makes sense.
jonasnick:
ACK 37ed51a7ea
Tree-SHA512: 82b5b8e29f48e84fd7a0681b62923d3bd87d724b38ef18e8c7969b0dcc5a405ebb26c14b5c5f4c7ba0ccabd152d1531d217809d1daf40872fe0c1e079b55c64b
This reverts commit 25e3cfbf9b. The reverted
commit was probably based on the assumption that this is about the touched
checks cover the secret nonce k instead of r, which is the x-coord of the public
nonce. A signature with a zero r is invalid by the spec, so we should return 0
to make the caller retry with a different nonce. Overflow is not an issue.
Fixes#720.
This has been not been caught by the new constant-time tests because
valgrind currently gives us a zero exit code even if finds errors, see
https://github.com/bitcoin-core/secp256k1/pull/723#discussion_r388246806 .
This commit also simplifies the arithmetic in memczero.
Note that the timing leak here was the bit whether a secret key was
out of range. This leak is harmless and not exploitable. It is just
our overcautious practice to prefer constant-time code even here.
Valgrind does bit-level tracking of the "uninitialized" status of memory,
property tracks memory which is tainted by any uninitialized memory, and
warns if any branch or array access depends on an uninitialized bit.
That is exactly the verification we need on secret data to test for
constant-time behaviour. All we need to do is tell valgrind our
secret key is actually uninitialized memory.
This adds a valgrind_ctime_test which is compiled if valgrind is installed:
Run it with libtool --mode=execute:
$ libtool --mode=execute valgrind ./valgrind_ctime_test
7b50483ad7 Adds a declassify operation to aid constant-time analysis. (Gregory Maxwell)
34a67c773b Eliminate harmless non-constant time operations on secret data. (Gregory Maxwell)
Pull request description:
There were several places where the code was non-constant time
for invalid secret inputs. These are harmless under sane use
but get in the way of automatic const-time validation.
(Nonce overflow in signing is not addressed, nor is s==0 in signing)
ACKs for top commit:
sipa:
utACK 7b50483ad7
real-or-random:
ACK 7b50483ad7 I read the code carefully and tested it
jonasnick:
reACK 7b50483ad7
Tree-SHA512: 0776c3a86e723d2f97b9b9cb31d0d0e59dfcf308093b3f46fbc859f73f9957f3fa977d03b57727232040368d058701ef107838f9b1ec98f925ec78ddad495c4e
ECDSA signing has a retry loop for the exceptionally unlikely case
that S==0. S is not a secret at this point and this case is so
rare that it will never be observed but branching on it will trip
up tools analysing if the code is constant time with respect to
secrets.
Derandomized ECDSA can also loop on k being zero or overflowing,
and while k is a secret these cases are too rare (1:2^255) to
ever observe and are also of no concern.
This adds a function for marking memory as no-longer-secret and
sets it up for use with the valgrind memcheck constant-time
test.
There were several places where the code was non-constant time
for invalid secret inputs. These are harmless under sane use
but get in the way of automatic const-time validation.
(Nonce overflow in signing is not addressed, nor is s==0 in
signing)
642cd062bd Remove Java Native Interface (Jonas Nick)
Pull request description:
This was discussed in #508. The main reasons are that the existing Java Native Interface (JNI) bindings would need way more work to remain useful to Java developers but the maintainers and regular contributors of libsecp are not very familiar with Java (and evidently are motivated enough to improve the situation). We don't know who relies on these bindings with the exception of ACINQ who have their own fork at https://github.com/ACINQ/secp256k1/tree/jni-embed/src/java (@sstone). Bitcoinj can optionally use the libsecp bindings.
Ideally, there would be a separate repository owned by Java developers with just the bindings. Until this exists, Java developers relying on libsecp can use ACINQs fork or an older commit of libsecp.
ACKs for top commit:
real-or-random:
ACK 642cd062bd I read the diff
real-or-random:
ACK 642cd062bd I read the diff, and I verified that the diff to 7d9066a66c0f13cabb0c4f71aca30edd3494f0d5, which has been ACKed by sipa, is only the additonal removal of ax_jni_include_dir.m4
Tree-SHA512: 9e573f2b01897bd5f301707062b41de53424517b537ce0834d9049d003cfd73fa1bcc024b543256016e4c9a1126f7c7fef559b84dc4914083b5a2d0ad5e57ea8
ECMULT_CONST_TABLE_GET_GE was branching on its secret input.
Also makes secp256k1_gej_double_var implemented as a wrapper
on secp256k1_gej_double_nonzero instead of the other way
around. This wasn't a constant time bug but it was fragile
and could easily become one in the future if the double_var
algorithm is changed.
bde2a32286 Convert bench.h to fixed-point math (Wladimir J. van der Laan)
Pull request description:
Convert `bench.h` to fixed-point math, removing all use of float math from the repository:
- Use 64-bit integer microsecond timestamps
- Use decimal fixed-point math for formatting numbers
It turned out to be a little trickier than I expected because of formatting and rounding. But, output should be the same before and after.
I used the following to test the number formatting: https://gist.github.com/laanwj/f971bfbe018e39c19677a21ff954d0c7
ACKs for top commit:
real-or-random:
ACK bde2a32286 I've read the code in detail and I've tested it. I haven't explicitly tested the formatting function with known/hardcoded inputs.
Tree-SHA512: 41ab6024b88c65a4b194272097c70d527bedb396dc7ab9d3d93165f1a19d31092798370f66399443a8d5393d0a6dcf5825679de5a325550865cfdef3586bf64c
- Use 64-bit integer microsecond timestamps
- Use fixed-point math for formatting numbers
Then, remove "except in benchmarks" exception from `README.md`.
Jonas Nick
Pieter Wuille
Tim Ruffing
Andrew Poelstra
William Bright
Russell O'Connor
Gregory Maxwell
Aaron Voisine
Peter Dettman
PiRK
Elichai Turkel
Dimitris Apostolou
Tim Gates
Fabien
f-daniel
Marko Bencun
Wladimir J. van der Laan