This passes $(DEFS) (which should literally be "-DHAVE_CONFIG_H") to the
compiler when building gen_context.
This has currently no effect because gen_context.c does not check for
this macro but it's conceivable that it may do so in the future.
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
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
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
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.
make ECMULT_GEN_PREC_BITS configurable
ecmult_static_context.h: add compile time config assertion (#3) - Prevents accidentally using a file which was generated with a
different configuration.
README: mention valgrind issue
With --with-ecmult-gen-precision=8, valgrind needs a max stack size
adjustment to not run into a stack switching heuristic:
http://valgrind.org/docs/manual/manual-core.html
> -max-stackframe= [default: 2000000]
> The maximum size of a stack frame. If the stack pointer moves by more than this amount then Valgrind will assume that the program is switching to a different stack.
You may need to use this option if your program has large stack-allocated arrays.
basic-config: undef ECMULT_WINDOW_SIZE before (re-)defining it
This fix install all the headers under include/ into
/usr/local/include. The fix solves problems that arise
when building libraries that depend on secp256k1 such
as bitcoin-system which require all the headers
This fixes a bug where configure would fail or disable static
ecmult tables because it wrongly checks the native compiler using
the target CFLAGS (instead of the native CFLAGS_FOR_BUILD), and
similar for CPPFLAGS and LDFLAGS.
Moreover, this commit adds tests to figure out whether the native
compiler supports the warning flags passed during the build, and it
contains a few minor improvements to the code that checks the native
compiler.
If you compile without ./configure --enable-exhaustive-tests=no,
this will create a binary ./exhaustive_tests which will execute
every function possible on a group of small order obtained by
moving to a twist of our curve and locating a generator of small
order.
Currently defaults to order 13, though by changing some #ifdefs
you can get a couple other ones. (Currently 199, which will take
forever to run, and 14, which won't work because it's composite.)
TODO exhaustive tests for the various modules
We observe that when changing the b-value in the elliptic curve formula
`y^2 = x^3 + ax + b`, the group law is unchanged. Therefore our functions
for secp256k1 will be correct if and only if they are correct when applied
to the curve defined by `y^2 = x^3 + 4` defined over the same field. This
curve has a point P of order 199.
This commit adds a test which computes the subgroup generated by P and
exhaustively checks that addition of every pair of points gives the correct
result.
Unfortunately we cannot test const-time scalar multiplication by the same
mechanism. The reason is that these ecmult functions both compute a wNAF
representation of the scalar, and this representation is tied to the order
of the group.
Testing with the incomplete version of gej_add_ge (found in 5de4c5dff^)
shows that this detects the incompleteness when adding P - 106P, which
is exactly what we expected since 106 is a cube root of 1 mod 199.
gcc 6 will warn about our non-null checks when SECP256K1_BUILD
our NONNULL marker is nontrivial. This occurs unless SECP256K1_BUILD
is set, which we had forgotten to do for the internal benchmarks,
which compile directly against the library instead of linking.
Squashed and rebased. Thanks to @theuni and @faizkhan00 for doing
the majority of work here! Also thanks to @btchip for help with debugging
and review.
These functions are intended for compatibility with legacy software,
and are not normally needed in new secp256k1 applications.
They also do not obeying any particular standard (and likely cannot
without without undermining their compatibility), and so are a
better fit for contrib.
Libtool will do the right thing and use whatever is available
based on --enable-shared/--enable-static.
This also means that some of the things we build actually
test the dynamic library.
Designed with clear separation of the wNAF conversion, precomputation
and exponentiation (since the precomp at least we will probably want
to separate in the API for users who reuse points a lot.
Future work:
- actually separate precomp in the API
- do multiexp rather than single exponentiation
BUILT_SOURCES simply forces the header to be built first.
Use real dependencies instead. This fixes builds with dependency tracking
disabled where a real target is specified.
As a bonus, this also fixes the issue of gen_context and the header not being
rebuilt when gen_context.c is touched.
Gen_context was unable to find the required headers without some
autotools fixups. Make dist was also broken without the extra
sources for the host side table builder utility.
This vastly shrinks the size of the context required for signing on devices with
memory-mapped Flash.
Tables are generated by the new gen_context tool into a header.
Tim Ruffing
Gregory Maxwell
Pieter Wuille
Peter Dettman
Jonas Nick
fanquake
djb
ian
Víctor Mayoral Vilches
Pieter Wuille
Andrew Poelstra
Wladimir J. van der Laan
GreenAddress
ptschip
Cory Fields
Thomas Daede