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.
5eb030c test: Use checked_alloc (Wladimir J. van der Laan)
Tree-SHA512: f0fada02664fca3b4f48795ce29a187331f86f80fc1605150fcfc451e7eb4671f7b5dff09105c9927e28af6d1dafd1edad1671dddd412110f4b5950153df499d
I think I summarized it correctly after IRC discussion with gmaxwell
and andytoshi; I didn't know it existed :(
It's regrettable to expose this level of detail, but users need to know
this to make a decision about how to use it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
OpenSSL 1.1 makes ECDSA_SIG opaque and our tests need access
inside this object.
The comparison tests against OpenSSL aren't important for most
users, but the build failing is...
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).
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)
