_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.
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.
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.
Identifiers starting with an underscore and followed immediately by a capital letter are reserved by the C++ standard.
The only header guards not fixed are those in the headers auto-generated from java.
bc61b91 add pubkey prefix constants to include/secp256k1.h (Andrew Poelstra)
Pull request description:
In future multisig implementations we will need to pass nonces around, which are algebraically pubkeys but should not be decodable as pubkeys. The way to do this is to change the prefix byte from the ordinary 0x02/0x03 to something else. However, some forks (notably `secp256k1-zkp`) have started using some bytes for their own encodings, and if we continue to use hardcoded constants the risk of conflict is increased.
This commit puts the prefixes used by the main library into the `include/secp256k1.h` so that the constants we're using will at least be in a standard easy-to-reference place.
Tree-SHA512: 37fa25be5074b7c519a9c69421320a62f32a3818f144254eb57f96c6657b993fc01962a5c670574275d1c59b095a6c89e60736123f032d6736907284eac526d7
I think I summarized it correctly after IRC discussion with gmaxwell
and andytoshi; I didn't know it existed :(
It's regrettable to expose this level of detail, but users need to know
this to make a decision about how to use it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cory Fields
Tim Ruffing
fanquake
Elichai Turkel
Jonas Nick
Andrew Poelstra
Gregory Maxwell
Ferdinando M. Ametrano
philsmd
Thomas Kerin
Dan Raviv
Pieter Wuille
Rusty Russell