This commit adds three new cryptosystems to libsecp256k1:
Pedersen commitments are a system for making blinded commitments
to a value. Functionally they work like:
commit_b,v = H(blind_b || value_v),
except they are additively homorphic, e.g.
C(b1, v1) - C(b2, v2) = C(b1 - b2, v1 - v2) and
C(b1, v1) - C(b1, v1) = 0, etc.
The commitments themselves are EC points, serialized as 33 bytes.
In addition to the commit function this implementation includes
utility functions for verifying that a set of commitments sums
to zero, and for picking blinding factors that sum to zero.
If the blinding factors are uniformly random, pedersen commitments
have information theoretic privacy.
Borromean ring signatures are a novel efficient ring signature
construction for AND/OR admissions policies (the code here implements
an AND of ORs, each of any size). This construction requires
32 bytes of signature per pubkey used plus 32 bytes of constant
overhead. With these you can construct signatures like "Given pubkeys
A B C D E F G, the signer knows the discrete logs
satisifying (A || B) & (C || D || E) & (F || G)".
ZK range proofs allow someone to prove a pedersen commitment is in
a particular range (e.g. [0..2^64)) without revealing the specific
value. The construction here is based on the above borromean
ring signature and uses a radix-4 encoding and other optimizations
to maximize efficiency. It also supports encoding proofs with a
non-private base-10 exponent and minimum-value to allow trading
off secrecy for size and speed (or just avoiding wasting space
keeping data private that was already public due to external
constraints).
A proof for a 32-bit mantissa takes 2564 bytes, but 2048 bytes of
this can be used to communicate a private message to a receiver
who shares a secret random seed with the prover.
Also: get rid of precomputed H tables (Pieter Wuille)
This makes WINDOW_G a configurable value in the range of [2..24].
The upper limit of 24 is a defensive choice. The code is probably
correct for values up to 27 but those larger values yield in huge
tables (>= 256MiB), which are i) unlikely to be really beneficial
in practice and ii) increasingly difficult to test.
a34bcaa Actually pass CFLAGS_FOR_BUILD and LDFLAGS_FOR_BUILD to linker (Tim Ruffing)
2d5f4ce configure: Use CFLAGS_FOR_BUILD when checking native compiler (Tim Ruffing)
Pull request description:
This fixes a bug where configure would fail or disable static
ecmult tables because it wrongly checks the native compiler using
the target CFLAGS (instead of the native CFLAGS_FOR_BUILD).
Moreover, this commit adds tests to figure out whether the native
compiler supports the warning flags passed during the build, and it
contains a few minor improvements to the code that checks the native
compiler.
Tree-SHA512: 31a92a5516cf2f9801c918edfba0059aa4f8549b0c1de94fc166b5e92ad1868a480c48cdc5ff62679ba20e26f4a0e2948c71fd2b3e80766673d2bf7512da3875
3965027 Summarize build options in configure script (Evan Klitzke)
Pull request description:
This is a trivial build system change to summarize the build options after running configure.
Example output:
```
$ ./configure
....
<many lines omitted>
...
config.status: src/libsecp256k1-config.h is unchanged
config.status: executing depfiles commands
config.status: executing libtool commands
Build Options:
with endomorphism = no
with ecmult precomp = yes
with jni = no
module ecdh = no
module recovery = no
asm = x86_64
bignum = gmp
field = 64bit
scalar = 64bit
CC = gcc
CFLAGS = -g -O2 -W -std=c89 -pedantic -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -Wno-unused-function -Wno-long-long -Wno-overlength-strings -fvisibility=hidden -O3
CPPFLAGS =
LDFLAGS =
```
I tried to just include the configure options that looked interesting; let me know if there are any I didn't include that I should have.
Tree-SHA512: 428381654d772f76bc81210d39ba5c3f07a94dc6a6378a02ccc6f23ebce7f501896268bcd2e94e2b0d8aea54c9c70c44a9238a0f0960600f463b1e2847c7ed1f
270f6c8 Portability fix for the configure scripts generated (Pierre Pronchery)
Pull request description:
Found thanks to the developer checks from the pkgsrc software
distribution (for NetBSD, SmartOS, Minix, MacOS X, Linux, and more).
Tree-SHA512: 2589545aa4d0620db66e79df1dc148a487384b5169ba7323937490d802973388859d30d45b35ee3e614be6d49cb694f37f585a16caa87ad1e500a0b7368dcc0a
This fixes a bug where configure would fail or disable static
ecmult tables because it wrongly checks the native compiler using
the target CFLAGS (instead of the native CFLAGS_FOR_BUILD), and
similar for CPPFLAGS and LDFLAGS.
Moreover, this commit adds tests to figure out whether the native
compiler supports the warning flags passed during the build, and it
contains a few minor improvements to the code that checks the native
compiler.
57752d2 [build] Set --enable-jni to no by default instead of auto. (Karl-Johan Alm)
Pull request description:
Having `--enable-jni` be `auto` doesn't make a lot of sense, and results in things like https://github.com/bitcoin/bitcoin/pull/11056.
Tree-SHA512: 27d6ea041f5d6e249857869ab87b8f7b1f6d18ec5ec82d2c46e692cd690b9f5c5857886725901a29d3539d427d8b6154d0c7909cfa2ce30bb3d4460c05708386
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.
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.
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 update is to make libsecp256k1 build on OpenBSD (more specifically OpenBSD 5.7 with Autotools 2.69).
Without the "AM_PROG_CC_C_O" line in configure.ac, ./autogen.sh crashes with "Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in `configure.ac'\nautoreconf-2.69: automake failed with exit status: 1".
This vastly shrinks the size of the context required for signing on devices with
memory-mapped Flash.
Tables are generated by the new gen_context tool into a header.
