ec0a7b3 Don't touch leading zeros in wnaf_fixed. (Jonas Nick)
9e36d1b Fix bug in wnaf_fixed where the wnaf array is not completely zeroed when given a 0 scalar. (Jonas Nick)
96f68a0 Don't invert scalar in wnaf_fixed when it is even because a caller might intentionally give a scalar with many leading zeros. (Jonas Nick)
6dbb007 Increase sparsity of pippenger fixed window naf representation (Jonas Nick)
Pull request description:
Fixes#506
Tree-SHA512: 49a237a7d09c0c376ba4e6b1f522b9aff2517e420dfef9df810fd5ba920e0b98be8fe3f730b32e41b4aef475bc4cf3b13220024bd8d6f40c2744e6f392ff97a8
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.
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.
This has the effect of making `secp256k1_scalar_mul_shift_var` constant
time in both input scalars. Keep the _var name because it is NOT constant
time in the shift amount.
As used in `secp256k1_scalar_split_lambda_var`, the shift is always
the constant 272, so this function becomes constant time, and it
loses the `_var` suffix.
* Make secp256k1_gej_add_var and secp256k1_gej_double return the
Z ratio to go from a.z to r.z.
* Use these Z ratios to speed up batch point conversion to affine
coordinates, and to speed up batch conversion of points to a
common Z coordinate.
* Add a point addition function that takes a point with a known
Z inverse.
* Due to secp256k1's endomorphism, all additions in the EC
multiplication code can work on affine coordinate (with an
implicit common Z coordinate), correcting the Z coordinate of
the result afterwards.
Refactoring by Pieter Wuille:
* Move more global-z logic into the group code.
* Separate code for computing the odd multiples from the code to bring it
to either storage or globalz format.
* Rename functions.
* Make all addition operations return Z ratios, and test them.
* Make the zr table format compatible with future batch chaining
(the first entry in zr becomes the ratio between the input and the
first output).
Original idea and code by Peter Dettman.
Unbraced statements spanning multiple lines has been shown in many
projects to contribute to the introduction of bugs and a failure
to catch them in review, especially for maintenance on infrequently
modified code.
Most, but not all, of the existing practice in the codebase were not
cases that I would have expected to eventually result in bugs but
applying it as a rule makes it easier for other people to safely
contribute.
I'm not aware of any such evidence for the case with the statement
on a single line, but some people strongly prefer to never do that
and the opposite rule of "_always_ use a single line for single
statement blocks" isn't a reasonable rule for formatting reasons.
Might as well brace all these too, since that's more universally
acceptable.
[In any case, I seem to have introduced the vast majority of the
single-line form (as they're my preference where they fit).]
This also removes a broken test which is no longer needed.
- In secp256k1_gej_split_exp, there are two divisions used. Since the denominator is a constant known at compile-time, each can be replaced by a multiplication followed by a right-shift (and rounding).
- Add the constants g1, g2 for this purpose and rewrite secp256k1_scalar_split_lambda_var accordingly.
- Remove secp256k1_num_div since no longer used
Rebased-by: Pieter Wuille
GCC (and clang) supports extensions to annotate functions so that their
results must be used and so that their arguments can't be statically
provable to be null. If a caller violates these requirements they
get a warning, so this helps them write correct code.
I deployed this in libopus a couple years ago with good success, and
the implementation here is basically copied straight from that.
One consideration is that the non-null annotation teaches the optimizer
and will actually compile out runtime non-nullness checks as dead-code.
Since this is usually not whats wanted, the non-null annotations are
disabled when compiling the library itself.
The commit also removes some dead inclusions of assert.h and introduces
compatibility macros for restrict and inline in preparation for some
portability improvements.
