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.
The side-effects make review somewhat harder because 99.9% of the
time the macro usage has no sideeffects, so they're easily ignored.
The main motivation for avoiding the side effects is so that the
macro can be completely stubbed out for branch coverage analysis
otherwise all the unreachable verify code gets counted against
coverage.
This avoids data=NULL and data = zeros to producing the same nonce.
Previously the code tried to avoid the case where some data inputs
aliased algo16 inputs by always padding out the data.
But because algo16 and data are different lengths they cannot
emulate each other, and the padding would match a data value of
all zeros.
This makes it somewhat less constant time in error conditions, but
avoids encountering an internal assertion failure when trying
to write out the point at infinity.
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.
This commit adds functions:
* secp256k1_rand_bits, which works like secp256k1_rand32, but consumes
less randomness
* secp256k1_rand_int, which produces a uniform integer over any range
* secp256k1_rand_bytes_test, which works like secp256k1_rand256_test
but for arbitrary byte array
This also makes use of optional valgrind instrumentation if -DVALGRIND
is set.
This also moves secp256k1.c above secp256k1.h in tests.c or otherwise
we get non-null macros on the public functions which may defeat some
of the VERIFY checks.
Libtool will do the right thing and use whatever is available
based on --enable-shared/--enable-static.
This also means that some of the things we build actually
test the dynamic library.
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.
This makes it more clear that a null check is intended. Avoiding the
use of a pointer as a test condition alse increases the type-safety
of the comparisons.
(This is also MISRA C 2012 rules 14.4 and 11.9)
Pieter Wuille