BIP340's default signing algorithm always requires an aux_rnd argument,
but permits using an all-zero one when no randomness is available.
Make secp256k1_schnorrsig_sign follow this even when aux_rnd32==NULL,
by treating the same as if an all-zero byte array was provided as
input.
adec5a1638 Add missing null check for ctx and input keys in the public API (Elichai Turkel)
f4edfc7581 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 adec5a1638
Tree-SHA512: 6fe785776b7e451e9e8cae944987f927b1eb2e2d404dfcb1b0ceb0a30bda4ce16469708920269417e5ada09739723a430e270dea1868fe7d12ccd5699dde5976
unsigned char foo[4] = "abcd" is not valid C++ because the string
literal "abcd" does not fit into foo due to the terminating NUL
character. This is valid in C, it will just omit the NUL character.
Fixes#962.
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.
0881633dfd secp256k1.h: clarify that by default arguments must be != NULL (Jonas Nick)
Pull request description:
The same file says that the illegal callback will only triger for violations
explicitly mentioned, which is not true without this commit because we often
don't mention that an argument is not allowed to be NULL.
This line is extracted from #783 in the hope that it gets merged faster because other PRs depend on it.
ACKs for top commit:
gmaxwell:
ACK 0881633dfd
real-or-random:
ACK 0881633dfd
Tree-SHA512: ecdc6954a1c21c333da5b03db51f50a0e53984aaef69cc697adaddc96b276da23e342037f476d21742632f6ec02bfa0574f837a5b5791f5985f4c355037176fa
The same file says that the illegal callback will only triger for violations
explicitly mentioned, which is not true without this commit because we often
don't mention that an argument is not allowed to be NULL.
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
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.
It's subtle, since it is actually only touched by hashfp (though
we assert it's non-NULL), but give explicit advice in the default
case.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Pieter Wuille
Jonas Nick
Tim Ruffing
Elichai Turkel
Andrew Poelstra
Gregory Maxwell
Ferdinando M. Ametrano
Rusty Russell
Jan Xie
philsmd