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.
0881633dfd0c530a915cf63be295f00841c94cc4 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 0881633dfd0c530a915cf63be295f00841c94cc4
real-or-random:
ACK 0881633dfd0c530a915cf63be295f00841c94cc4
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.
33cb3c2b1fc3f3fe46c6d0eab118248ea86c1f06 Add secret key extraction from keypair to constant time tests (Elichai Turkel)
36d9dc1e8e6e3b15d805f04c973a8784a78880f6 Add seckey extraction from keypair to the extrakeys tests (Elichai Turkel)
fc96aa73f5c7f62452847a31821890ff1f72a5a4 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 33cb3c2b1fc3f3fe46c6d0eab118248ea86c1f06
real-or-random:
ACK 33cb3c2b1fc3f3fe46c6d0eab118248ea86c1f06 code inspection, tests pass
Tree-SHA512: 11212db38c8b87a87e2dc35c4d6993716867b45215b94b20522b1b3164ca63d4c6bf5192a6bff0e9267b333779cc8164844c56669a94e9be72df9ef025ffcfd4
7b50483ad789081ba158799e5b94330f62932607 Adds a declassify operation to aid constant-time analysis. (Gregory Maxwell)
34a67c773b0871e5797c7ab506d004e80911f120 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 7b50483ad789081ba158799e5b94330f62932607
real-or-random:
ACK 7b50483ad789081ba158799e5b94330f62932607 I read the code carefully and tested it
jonasnick:
reACK 7b50483ad789081ba158799e5b94330f62932607
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>
Before this commit secp256k1_context_randomize called illegal_callback
when called on a context not initialized for signing. This is not
documented. Moreover, it is not desirable because non-signing contexts
may use randomization in the future.
This commit makes secp256k1_context_randomize a noop in this case. This
is safe because the context cannot be used for signing anyway.
This fixes#573 and it fixesrust-bitcoin/rust-secp256k1#82.
