field_get_b32: min 0.647us / avg 0.666us / max 0.751us
field_set_b32: min 0.551us / avg 0.571us / max 0.624us
becomes
field_get_b32: min 0us / avg 0.0000000477us / max 0.000000238us
field_set_b32: min 0us / avg 0.0000000238us / max 0.000000238us
(Patch from https://bitcointalk.org/index.php?topic=1740973.0
_get was reversed from the patch because this order appeared
somewhat faster in testing.)
Signed-off-by: Gregory Maxwell <greg@xiph.org>
5eb030c test: Use checked_alloc (Wladimir J. van der Laan)
Tree-SHA512: f0fada02664fca3b4f48795ce29a187331f86f80fc1605150fcfc451e7eb4671f7b5dff09105c9927e28af6d1dafd1edad1671dddd412110f4b5950153df499d
Mathematically, we always overflow when using the exhaustive tests (because our
scalar order is 13 and our field order is on the order of 2^256), but the
`overflow` variable returned when parsing a b32 as a scalar is always set
to 0, to prevent infinite (or practically infinite) loops searching for
non-overflowing scalars.
Whenever ecdsa_sig_sign is called, in the case that r == 0 or r overflows,
we want to retry with a different nonce rather than fail signing entirely.
Because of this, we always check the nonce conditions before calling
sig_sign, so these checks should always pass (and in particular, they
are inaccessible through the API and appear as uncovered code in test
coverage).
If you compile without ./configure --enable-exhaustive-tests=no,
this will create a binary ./exhaustive_tests which will execute
every function possible on a group of small order obtained by
moving to a twist of our curve and locating a generator of small
order.
Currently defaults to order 13, though by changing some #ifdefs
you can get a couple other ones. (Currently 199, which will take
forever to run, and 14, which won't work because it's composite.)
TODO exhaustive tests for the various modules
We observe that when changing the b-value in the elliptic curve formula
`y^2 = x^3 + ax + b`, the group law is unchanged. Therefore our functions
for secp256k1 will be correct if and only if they are correct when applied
to the curve defined by `y^2 = x^3 + 4` defined over the same field. This
curve has a point P of order 199.
This commit adds a test which computes the subgroup generated by P and
exhaustively checks that addition of every pair of points gives the correct
result.
Unfortunately we cannot test const-time scalar multiplication by the same
mechanism. The reason is that these ecmult functions both compute a wNAF
representation of the scalar, and this representation is tied to the order
of the group.
Testing with the incomplete version of gej_add_ge (found in 5de4c5dff^)
shows that this detects the incompleteness when adding P - 106P, which
is exactly what we expected since 106 is a cube root of 1 mod 199.
Make sure we clear the nonce data even if the nonce function fails (it may have written partial data), and call memset only once in the case we iterate to produce a valid signature.
Make sure we clear the nonce data even if the nonce function fails (it may have written partial data), and call memset only once in the case we iterate to produce a valid signature.
Fixes warnings of the form "warning: cast to pointer from integer of
different size" when building on 32 bit platforms. This is the same
approach used for pointer conversions in the openjdk sources.
