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>
These functions are intended for compatibility with legacy software,
and are not normally needed in new secp256k1 applications.
They also do not obeying any particular standard (and likely cannot
without without undermining their compatibility), and so are a
better fit for contrib.
ECDSA signature verification now requires normalized signatures (with S in the
lower half of the range). In case the input cannot be guaranteed to provide this,
a new function secp256k1_ecdsa_signature_normalize is provided to preprocess it.
There are now 2 encoding formats supported: 64-byte "compact" and DER.
The latter is strict: the data has to be exact DER, though the values
inside don't need to be valid.
The use of static makes this somewhat redundant currently, though if
we later have multiple compilation units it will be needed.
This also sets the dllexport needed for shared libraries on win32.
Gregory Maxwell
Ferdinando M. Ametrano
Jonas Nick
Tim Ruffing
philsmd
Andrew Poelstra
Thomas Kerin
Dan Raviv
Pieter Wuille
Rusty Russell
Luke Dashjr