_tagged_sha256 simply cannot have invalid inputs.
The other functions could in some sense have invalid inputs but only in
violation of the type system. For example, a pubkey could be invalid but
invalid objects of type secp256k1_pubkey either can't be obtained
via the API or will be caught by an ARG_CHECK when calling pubkey_load.
This is consistent with similar functions in the public API, e.g.,
_ec_pubkey_negate or _ec_pubkey_serialize.
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.
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.
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.
