Pieter Wuille [Mon, 18 Dec 2017 22:38:35 +0000 (14:38 -0800)]
Merge #480: Enable benchmark building by default
7a78f60 Print whether we're building benchmarks (Pieter Wuille) 4afec9f Build benchmarks by default (Pieter Wuille)
Pull request description:
Building benchmarks is fast, and I have on more than one occasion forgotten to pass `--enable-benchmark`, resulting in accidentally benchmarking a former build.
Pieter Wuille [Fri, 8 Dec 2017 00:46:30 +0000 (16:46 -0800)]
Merge #486: Add pippenger_wnaf for multi-multiplication
d2f9c6b Use more precise pippenger bucket windows (Jonas Nick) 4c950bb Save some additions per window in _pippenger_wnaf (Peter Dettman) a58f543 Add flags for choosing algorithm in ecmult_multi benchmark (Jonas Nick) 36b22c9 Use scratch space dependent batching in ecmult_multi (Jonas Nick) 355a38f Add pippenger_wnaf ecmult_multi (Jonas Nick) bc65aa7 Add bench_ecmult (Pieter Wuille) dba5471 Add ecmult_multi tests (Andrew Poelstra) 8c1c831 Generalize Strauss to support multiple points (Pieter Wuille) 548de42 add resizeable scratch space API (Andrew Poelstra)
Pull request description:
This PR is based on #473 and adds a variant of "Pippengers algorithm" (see [Bernstein et al., Faster batch forgery identification](https://eprint.iacr.org/2012/549.pdf), page 15 and https://github.com/scipr-lab/libff/pull/10) for point multi-multiplication that performs better with a large number of points than Strauss' algorithm.
Thanks to @sipa for providing `wnaf_fixed`, benchmarking, and the crucial suggestion to use affine addition.
The PR also makes `ecmult_multi` decide which algorithm to use, based on the number of points and the available scratch space.
For restricted scratch spaces this can be further optimized in the future (f.e. a 35kB scratch space allows batches of 11 points with strauss or 95 points with pippenger; choosing pippenger would be 5% faster).
As soon as this PR has received some feedback I'll repeat the benchmarks to determine the optimal `pippenger_bucket_window` with the new benchmarking code in #473.
Pieter Wuille [Thu, 10 Aug 2017 23:41:39 +0000 (16:41 -0700)]
Merge #459: Add pubkey prefix constants to include/secp256k1.h
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.
Merge #452: Minor optimizations to _scalar_inverse to save 4M
465159c Further shorten the addition chain for scalar inversion. (Brian Smith) cf12fa1 Minor optimizations to _scalar_inverse to save 4M (Peter Dettman)
CryptoGuru [Mon, 9 Jan 2017 23:18:57 +0000 (23:18 +0000)]
Unroll secp256k1_fe_(get|set)_b32 for 5x52.
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.)
Andrew Poelstra [Mon, 28 Nov 2016 18:59:38 +0000 (18:59 +0000)]
exhaustive tests: remove erroneous comment from ecdsa_sig_sign
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.
Andrew Poelstra [Sat, 26 Nov 2016 20:14:19 +0000 (20:14 +0000)]
ecdsa_impl: replace scalar if-checks with VERIFY_CHECKs in ecdsa_sig_sign
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).
Pieter Wuille [Sat, 26 Nov 2016 00:48:14 +0000 (16:48 -0800)]
Merge #310: Add exhaustive test for group functions on a low-order subgroup
b4ceedf Add exhaustive test for verification (Andrew Poelstra) 83836a9 Add exhaustive tests for group arithmetic, signing, and ecmult on a small group (Andrew Poelstra) 20b8877 Add exhaustive test for group functions on a low-order subgroup (Andrew Poelstra)
Andrew Poelstra [Thu, 7 Jul 2016 10:11:30 +0000 (10:11 +0000)]
Add exhaustive tests for group arithmetic, signing, and ecmult on a small group
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.)
Andrew Poelstra [Thu, 17 Sep 2015 23:54:52 +0000 (18:54 -0500)]
Add exhaustive test for group functions on a low-order subgroup
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.
bgorlick [Fri, 21 Oct 2016 11:59:32 +0000 (04:59 -0700)]
Restructure nonce clearing
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.
bgorlick [Fri, 21 Oct 2016 10:50:10 +0000 (03:50 -0700)]
Restructure nonce clearing
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.
Andrew Poelstra [Mon, 6 Jun 2016 18:32:29 +0000 (18:32 +0000)]
build: add -DSECP256K1_BUILD to benchmark_internal build flags
gcc 6 will warn about our non-null checks when SECP256K1_BUILD
our NONNULL marker is nontrivial. This occurs unless SECP256K1_BUILD
is set, which we had forgotten to do for the internal benchmarks,
which compile directly against the library instead of linking.