After this commit, int128.h and int128_impl.h are included as follows:
- .c files which use int128 include int128_impl.h (after util.h)
- .h files which use int128 include int128.h (after util.h)
This list is exhaustive. util.h needs to included first because it sets
up necessary #defines.
This is a backwards-compatible API change: Before this commit, a context
initialized for signing was required to call functions that rely on
ecmult_gen. After this commit, this is no longer necessary because the
static ecmult_gen table is always present. In practice this means that
the corresponding functions will just work instead of calling the
illegal callback when given a context which is not (officially)
initialized for signing.
This is in line with 6815761, which made the analogous change with
respect to ecmult and contexts initialized for signing. But as opposed
to 681571, which removed the ecmult context entirely, we cannot remove
the ecmult_gen context entirely because it is still used for random
blinding. Moreover, since the secp256k1_context_no_precomp context is
const and cannot meaningfully support random blinding, we refrain (for
now) from changing its API, i.e., the illegal callback will still be
called when trying to use ecmult_gen operations with the static
secp256k1_context_no_precomp context.
adec5a16383f1704d80d7c767b2a65d9221cee08 Add missing null check for ctx and input keys in the public API (Elichai Turkel)
f4edfc758142d6e100ca5d086126bf532b8a7020 Improve consistency for NULL arguments in the public interface (Elichai Turkel)
Pull request description:
I went over the public API and added missing explanations on when a pointer can be null and when it cannot,
and added some missing checks for null ctx and null pubkey pointers.
Open questions IMHO:
1. Can `secp256k1_context_create` return NULL? right now it could return null if you replaced the callbacks at compile time to ones that do return(unlike the default ones which never return).
2. Related to the first, should we document that the callbacks should never return? (in the tests we use returning callbacks but we can violate our own API) right now we say the following:
> After this callback returns, anything may happen, including crashing.
Is this enough to document answer `no` for the first question and just saying that if the callback returned then you violated the API so `secp256k1_context_create` can return NULL even though it is promised not to?
Right now we AFAICT we never check if it returns null
Another nit I'm not sure about is wording `(does nothing if NULL)`/`(ignored if NULL)`/`(can be NULL)`
More missing docs:
1. Documenting the `data` argument to the default nonce functions
ACKs for top commit:
ariard:
ACK adec5a16
jonasnick:
ACK adec5a16383f1704d80d7c767b2a65d9221cee08
Tree-SHA512: 6fe785776b7e451e9e8cae944987f927b1eb2e2d404dfcb1b0ceb0a30bda4ce16469708920269417e5ada09739723a430e270dea1868fe7d12ccd5699dde5976
1f4dd0383807bfb7fef884601357b4c629dfb566 Typedef (u)int128_t only when they're not provided by the compiler (Tim Ruffing)
e89278f211a526062745c391d48a7baf782b4b2b 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 1f4dd0383807bfb7fef884601357b4c629dfb566
jonasnick:
ACK 1f4dd0383807bfb7fef884601357b4c629dfb566
Tree-SHA512: c0ec92798f3c94f3ef6ac69b3f0f39a39257a32be9d9a068832cece1ebe64c89848b70e44652fc397004b8b240883ac4bc0c8f95abbe4ba4b028de120e6734bf
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.
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.
f431b3f28ac95a3645ad5a6dc96b878fa30a1de3 valgrind_ctime_test: Add schnorrsig_sign (Jonas Nick)
16ffa9d97cef93f49544b016339c107882f9a1c3 schnorrsig: Add taproot test case (Jonas Nick)
8dfd53ee3fa059562483d1867815f78b9e00d947 schnorrsig: Add benchmark for sign and verify (Jonas Nick)
4e43520026f5bcd182d21f0759bac159ef47bb62 schnorrsig: Add BIP-340 compatible signing and verification (Jonas Nick)
7332d2db6b62fda851f9ed8adbfda187a875b84e schnorrsig: Add BIP-340 nonce function (Jonas Nick)
7a703fd97db0161bae07ef84513ddde6e0d27353 schnorrsig: Init empty experimental module (Jonas Nick)
eabd9bc46a31c0da6db6d88840eadbe9006447b1 Allow initializing tagged sha256 (Jonas Nick)
6fcb5b845d2832ce019d60507033f74426290768 extrakeys: Add keypair_xonly_tweak_add (Jonas Nick)
58254463f9a2e96d893157a341c9953c440fdf60 extrakeys: Add keypair struct with create, pub and pub_xonly (Jonas Nick)
f0010349b876bc6b3f0a6ec6c8bad0b12ca17b51 Separate helper functions for pubkey_create and seckey_tweak_add (Jonas Nick)
910d9c284c33b77774a9316d4524f313357d441c extrakeys: Add xonly_pubkey_tweak_add & xonly_pubkey_tweak_add_test (Jonas Nick)
176bfb1110147b5dca1834ea071acc846fb1cab3 Separate helper function for ec_pubkey_tweak_add (Jonas Nick)
4cd2ee474d178bd1b5602486104db346a7562c67 extrakeys: Add xonly_pubkey with serialize, parse and from_pubkey (Jonas Nick)
47e6618e11813cfabe91f0909ca031f960cb7dd4 extrakeys: Init empty experimental module (Jonas Nick)
3e08b02e2a78f2a1fc457efab665db8ab8085373 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 f431b3f28ac95a3645ad5a6dc96b878fa30a1de3 (exactly matches the previous post-fixup version which I have already reviewed and tested)
sipa:
ACK f431b3f28ac95a3645ad5a6dc96b878fa30a1de3
real-or-random:
ACK f431b3f28ac95a3645ad5a6dc96b878fa30a1de3 careful code review
Tree-SHA512: e15e849c7bb65cdc5d7b1d6874678e275a71e4514de9d5432ec1700de3ba92aa9f381915813f4729057af152d90eea26aabb976ed297019c5767e59cf0bbc693
8bc6aeffa9a191e677cb9e3a22fff130f16990f3 Add SHA256 selftest (Pieter Wuille)
5e5fb28b4a45d7e35e55b5f5feead2be07bccc28 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 8bc6aeffa9a191e677cb9e3a22fff130f16990f3 I read the diff, and tested that the self-test passes/fails with/without the correct endianness setting
gmaxwell:
ACK 8bc6aeffa9a191e677cb9e3a22fff130f16990f3 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
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)
cd473e0 Avoid calling secp256k1_*_is_zero when secp256k1_*_set_b32 fails. (Gregory Maxwell)
Pull request description:
Most of the codebase correctly used short-cutting to avoid calling
_is_zero on possibly incompletely initialized elements, but a few
places were missed.
ACKs for commit cd473e:
sipa:
utACK cd473e02c372217c3a6608ce5afaa543ed78f891
jonasnick:
utACK cd473e02c372217c3a6608ce5afaa543ed78f891
Tree-SHA512: d6af2863f6795d2df26f2bd05a4e33085e88c45f7794601ea57e67238a2073ef1ee3ba0feab62a7fcbc0636c48dfd80eea07d0ca4f194414127f914b0478c732
Most of the codebase correctly used short-cutting to avoid calling
_is_zero on possibly incompletely initialized elements, but a few
places were missed.
