Squashed and rebased. Thanks to @theuni and @faizkhan00 for doing
the majority of work here! Also thanks to @btchip for help with debugging
and review.
I Noticed this on OSX with clang, though it likely happens elsewhere as well.
The result is disabled x86_64 asm.
Due to missing escaping, this $0 was interpreted as the function name
SECP_64BIT_ASM_CHECK, causing the compile-check to be broken on some compilers.
The actual check looked like this:
int main()
{
uint64_t a = 11, tmp;
__asm__ __volatile__("movq SECP_64BIT_ASM_CHECKx100000000,%1; mulq %%rsi" : "+a"(a) : "S"(tmp) : "cc", "%rdx");
return 0;
}
It seems even more odd that it compiled anywhere.
These were generated by testing more than 10^12 random test vectors
for coverage on instrumented (comparison operator outcomes) 32-bit
and 64-bit code, plus additional edge condition requirements (e.g.
inputs of 0, 1, -1) and then solving a minimum set cover problem.
The required responses were generated with Sage.
This significantly improves the lcov branch coverage report and
makes the tests much more sensitive to mutation testing of the
scalar code.
The challenges and responses are in the form of pairs of scalars:
C1 * C2 == R1
(C1 * C2) * (1 / C2) == C1
C2 * (1 / C2) == 1
C1 * C1 == R2
C1^2 == R2
Makes secp256k1_ec_pubkey_serialize set the length to zero on failure,
also makes secp256k1_ec_pubkey_create set the pubkey to zeros when
the key argument is NULL.
Also adds many additional ARGCHECK tests.
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.
Jon Griffiths