Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

post-quantum Zcash #805

Open
daira opened this issue Mar 28, 2016 · 26 comments
Open

post-quantum Zcash #805

daira opened this issue Mar 28, 2016 · 26 comments

Comments

@daira
Copy link
Contributor

@daira daira commented Mar 28, 2016

There are three components needed for a post-quantum Zcash:

  • a post-quantum public key encryption scheme;
  • reanalysis of symmetric crypto parameter choices against quantum attacks;
  • a practical post-quantum zkSNARK.

The first of these is already available, for example using New Hope key exchange in place of Curve25519 elliptic curve key exchange. A complication is that New Hope has larger public keys and larger ciphertexts (2048 bytes each; see section 7.1 of the New Hope paper). The public key size means that a New Hope key can't be encoded directly in an address, but that is not a fundamental obstacle: it might be possible to use an address registration protocol as described in #340, for example. The ciphertext size is quite large compared to the rest of a Pour description (and remember that we need two of them), but not totally impractical. Alternatively some other scheme may have shorter ciphertexts.

For the zkSNARK, in principle the existence of one-way functions is sufficient for the existence of ZK proof systems. The issue is practicality: practical zkSNARKs use pairing-based cryptography, and it is not clear whether or not that is available for PQ public key cryptosystems.

Note that even though lacking a PQ-zkSNARK means that arbitrary currency could be forged by a quantum attacker (if quantum computers are ever practical), there is still value in switching to a PQ encryption scheme and ensuring that the symmetric parameter choices are sufficient. This is because a quantum attacker could otherwise break the Curve25519-based encryption (for known addresses) and obtain past transaction metadata.

It is also useful to reanalyse the symmetric parameter choices in order to check whether Zcash already achieves post-quantum past privacy for payments to addresses that have been kept secret. If this were the case then it would allow Zcash to be used now by people who require that property.

@imichaelmiers
Copy link

@imichaelmiers imichaelmiers commented Mar 28, 2016

Given the changes in the commitment scheme, we no longer provide post quantum privacy for zcash even if the ciphertext is null or done using post quantum secure crypto. Because the commitment scheme is only computationally hiding, it is breakable by a powerful attacker.

@daira
Copy link
Contributor Author

@daira daira commented Mar 28, 2016

@imichaelmiers Post-quantum security does not mean security against computationally unbounded attackers. The commitment scheme [in Sprout] is post-quantum secure if the SHA-256 compression function is a post-quantum collision-resistant PRF. (It may or may not be, but computationally unbounded attackers are not the issue.)

@defuse
Copy link
Contributor

@defuse defuse commented Mar 28, 2016

If you have a guess for a_pk and rho then some kind of a Grover search probably lets you find the 192-bit r in ~2^96 time on a quantum computer.

[Edit by Daira: the length of r was increased to 256 bits, mostly for this reason.]

@matthewdgreen
Copy link

@matthewdgreen matthewdgreen commented Mar 28, 2016

Aside from using perfect/statistical commitments and ZK (and maybe symmetric primitives with very large key sizes), I don't think we know enough in 2016 to meaningfully guess at what will be post-quantum in 2040 or whenever real quantum machines arrive. The most we could do is take a stab and potentially put people at great risk by being wrong. *

To meaningfully enable PQ Zcash I would suggest that the following elements are most critical:

  1. Replace the SHA256 commitments with Pedersen commitments in the appropriate bilinear group. See the Pinnochio-coin paper for estimates of the cost.
  2. Keep all symmetric and public key encryption decisions independent of the core Zcash construction, so users have agility to choose alternate encryption algorithms -- including the "algorithm" that consists of writing your coin trapdoors on paper and handing them to your friend, who subsequently burns them.

I wouldn't worry too much about the zkSNARK. There will be plenty of warning before QCs reach the level of capability that makes currency forgery a concern.

  • Note: here I mean risk that we are wrong about PQ-security, but /also/ risk that we are wrong about classical security. Let's not do this.
@daira
Copy link
Contributor Author

@daira daira commented Mar 28, 2016

Grover's algorithm (the multi-target version) is provably optimal for a black-box quantum preimage search. I think there is considerable value in choosing parameters to resist that if we can do so by making minor tweaks, like the length of r.

(Note that we're already arguably over the performance cost budget and will need significant optimizations to make Zcash really practical; making the protocol even more expensive by use of Pedersen commitments etc. is not really on the table.)

[Much later edit: Sapling uses statistically hiding Pedersen commitments, so that issue is resolved. I disagree about algorithm agility; it would greatly complicate the protocol. On the other hand we have been careful to not exclude out-of-band transmission of notes, even though the protocol spec does not describe how to do it.]

@defuse
Copy link
Contributor

@defuse defuse commented Mar 29, 2016

Grover can also be used to speed up collision-finding to the cube-root rather than the square-root, e.g. http://arxiv.org/pdf/quant-ph/9705002.pdf (Høyer was my quantum computing prof and this was on the final exam!). So a quantum attacker can find a SHA256 collision in ~2^85 time and space. This impacts everywhere we rely on collision resistance of 256-bit values: the binding of the commitment scheme, faerie gold defense, etc.

The cube root algorithm above is optimal for searching for collisions in black boxes.

Increasing the lengths of hash outputs to 384 bits requires a change of hash function which is definitely out of scope for the 1.0 launch. We just need to keep this fact in mind if we're answering questions about post-quantum security.

@matthewdgreen
Copy link

@matthewdgreen matthewdgreen commented Mar 29, 2016

@daira I agree -- I don't think we have any runway or engineering budget to spend time on considerations about PQ security in v1.0. But if you think it's valuable enough to start a thread and have a discussion about it, I'm happy to include my recommendations. These are not near-term recommendations, but given the Pinnochio-coin results it seems obvious that they're not that far from practice (for a 2.0 or a 3.0 release). I would say these probably deserve a higher priority rank than experiments with new public-key cryptography, since statistically-hiding commitments provide tangible benefits we can actually deliver.

@daira
Copy link
Contributor Author

@daira daira commented Mar 29, 2016

@defuse wrote:

Grover can also be used to speed up collision-finding to the cube-root rather than the square-root, e.g. http://arxiv.org/pdf/quant-ph/9705002.pdf

Dan Bernstein disagrees:

A quantum algorithm by Brassard, Høyer, and Tapp has frequently been claimed to reduce the cost of b-bit hash collisions from 2b/2 to 2b/3. This paper analyzes the Brassard–Høyer–Tapp algorithm and shows that it has fundamentally worse price-performance ratio than the classical van Oorschot–Wiener hash-collision circuits, even under optimistic assumptions regarding the speed of quantum computers.

@daira
Copy link
Contributor Author

@daira daira commented Apr 26, 2016

Note that Pedersen commitments are not post-quantum binding. Neither are the potentially more SNARK circuit-efficient commitments in section 4 of https://eprint.iacr.org/2014/719

Later edit: commitments based on circuit-efficient hashes such as MiMC, Rescue, or Poseidon would be post-quantum binding. (That doesn't address the proof system; you would need both the proof system and the commitments to be post-quantum secure in order to get post-quantum integrity.)

@daira
Copy link
Contributor Author

@daira daira commented Apr 26, 2016

BTW, let's agree to use "post-quantum" only for protocols that, as far as we know now, actually have some hope of being secure against quantum computers. Let's use "quantum forward-private" for protocols that, as far as we know now, avoid leading secret/private information to future quantum adversaries (under the assumption that no-one has a large quantum computer now), but may not meet their other security goals against a quantum adversary.

@daira daira added the M-requires-zip label Oct 2, 2016
@burdges
Copy link

@burdges burdges commented Dec 6, 2016

I'd just say "post-quantum anonymity" as opposed to "post-quantum financial soundness" because "forward-private" sounds too much like "forward-secure", which always denotes an improvement, not a weakening.

If folk want post-quantum anonymity now, then they could set up a modified Taler exchange to provide it. RSA blind signatures do offer post-quantum anonymity for customers. As is, Taler's refresh protocol is not post-quantum, but if you do not care about taxability then it can be made post-quantum trivially. And I can tell you how to make it post-quantum with taxability if anyone cares. RSA blind signatures do not provide anonymity for merchants, if the customer is compromised, but you always buy something from yourself and delete the records.

In any case, I'd think Tor needs a post-quantum key exchange before any of this makes any difference.

@daira
Copy link
Contributor Author

@daira daira commented Dec 14, 2016

I'd like to reiterate that Zcash as it stands, already is conjectured to be post-quantum forward private when addresses are kept secret.

@daira
Copy link
Contributor Author

@daira daira commented Feb 27, 2017

@elibensasson et al's work on post-quantum STARKs is relevant here: https://www.youtube.com/watch?v=HJ9K_o-RRSY

@daira
Copy link
Contributor Author

@daira daira commented Apr 23, 2017

See #570 (comment) for a note on post-quantum forward privacy.

@daira
Copy link
Contributor Author

@daira daira commented May 3, 2017

https://www.youtube.com/watch?v=kYmnXxs9kUM is a version of Eli's talk with more technical detail.

@str4d
Copy link
Contributor

@str4d str4d commented Jun 13, 2017

@imichaelmiers and I were discussing PQ-privacy of note ciphertexts in the Zcash block chain, and came up with the following proposal for a scheme that requires no modification to the current Zcash protocol. Assume that the existing symmetric encryption scheme is itself PQ-secure (which it should be) - the current lack of PQ privacy is due to the use of public-key crypto to derive the symmetric encryption key.

  1. Alice and Bob use an out-of-band PQ-secure communication channel to negotiate a symmetric encryption key for Alice to use for sending payments to Bob, and an associated "key ID". The key ID could perhaps be derived from the symmetric key itself instead, or from some part of the PQ process (whatever can be done securely) - it just needs to be know to both Alice and Bob, but no one else.
  2. Alice derives a 256-bit "key tag" from the key ID using a rachet-like system, e.g. key_tag = SHA256(1 || key_id). The exact scheme may end up being slightly different - the goal is for the key tag to be a plausible Curve25519 public key.
  3. Alice creates her first JoinSplit to Bob, encrypts the output note for Bob using the negotiated symmetric encryption key, and sets e_pk to the key tag. She then increments her ratchet (so the next note she sends will use e.g. key_tag = SHA256(2 || key_id)).
  4. When scanning the block chain, Bob first checks the e_pk to see if it is derived from one of his key IDs. If it is, he uses the corresponding symmetric key to decrypt and checks whether the resulting note is valid (by checking the commitment). If it is invalid, Bob assumes the e_pk just collided with his key tags, and proceeds as normal with trial decryption of the note ciphertext with all his z-addresses. If it is valid, Bob increments his ratchet.

Ratcheting is used to ensure that sequential JoinSplits encrypted to the same symmetric key remain indistinguishable (as using the key ID directly would make them trivially linkable). As an additional benefit, a non-PQ adversary cannot distinguish between a JoinSplit using this scheme, and one using the existing non-PQ-secure scheme. A PQ adversary can only determine that some out-of-band mechanism is being used, but not which one (ie. this scheme is indistinguishable from users simply sending the notes out-of-band and filling the ciphertext fields with random data).

For Bob finding and decrypting notes on the block chain, this scheme is effectively O(1) in the number of PQ keys (compared to O(N) for Bob having N z-addresses), because deriving ratchet values is significantly cheaper than trial decryption (and key tags can be pre-computed at various ratchet points, whereas trial decryption against a random e_pk is inherently un-cacheable).

@str4d
Copy link
Contributor

@str4d str4d commented Jun 13, 2017

The above scheme is insecure because it re-uses keys. The current Zcash note encryption scheme (libsodium's aead_chacha20poly1305_ietf) uses a zero nonce because keys are never re-used: the ephemeral nature of e_pk means a unique Curve25519 output per JoinSplit, and the symmetric key used is derived from that via a KDF that takes the note index within the JoinSplit as an input. The obvious solution is to extend the ratcheting system to the symmetric keys themselves:

  1. Alice and Bob use an out-of-band PQ-secure communication channel to negotiate a seed for Alice to use when sending payments to Bob.
  2. Alice derives a 256-bit symmetric key and a 256-bit "key tag" from the seed using a rachet-like system, e.g. symm_key = SHA256("SymmKey" || 1 || seed) and key_tag = SHA256("KeyTag" || 1 || seed). The exact scheme for the key tag may end up being slightly different - the goal is for the key tag to be a plausible Curve25519 public key.
  3. Alice creates her first JoinSplit to Bob, encrypts the output note for Bob using the derived symmetric encryption key, and sets e_pk to the derived key tag. She then increments her ratchet (so the next note she sends will use e.g. symm_key = SHA256("SymmKey" || 2 || seed) and key_tag = SHA256("KeyTag" || 2 || seed)).
  4. When scanning the block chain, Bob first checks the e_pk to see if it is a key tag derived from one of his seeds. If it is, he uses the corresponding symmetric key to decrypt and checks whether the resulting note is valid (by checking the commitment). If it is invalid, Bob assumes the e_pk just collided with his key tags, and proceeds as normal with trial decryption of the note ciphertext with all his z-addresses. If it is valid, Bob increments his ratchet.
@daira
Copy link
Contributor Author

@daira daira commented Jun 13, 2017

What's the advantage of this over PQ-securely negotiating a shared-secret address, and then using the current note encryption with it?

The shared-secret address approach has the advantage that it's still conventionally secure if the PQ-confidentiality of the secure channel fails, which given the current state of cryptanalysis (due to their being new crypto) of candidates for PQ-secure key exchange, might be a very good idea.

@str4d
Copy link
Contributor

@str4d str4d commented Jun 15, 2017

@daira could you elaborate on the shared-secret address you are thinking of? I can imagine two different strategies consistent with that name; one of them is the proposal I outlined above (where the shared secret is roughly equivalent to the output of Curve25519 in our current note encryption), and the other one is PQ-insecure because it still uses Curve25519 (where the shared secret is the z-key).

@daira
Copy link
Contributor Author

@daira daira commented Jun 16, 2017

Instead of negotiating a shared symmetric key on the PQ-secure channel, the payee generates a new (spending key, payment address) and sends the payment address to the payer on the PQ-secure channel. That's all there is to it; everything else is the same as the current usage of Zcash. This is PQ-secure as explained in #570 (comment) , but if the PQ channel confidentiality fails, it devolves to classical security (unlike the scheme in #805 (comment) which fails completely in that case).

(Note that PQ-authentication is easier than PQ-confidentiality because you can use a hash-based signature, of which there are candidates such as SPHINCS that are already practical and proven secure based on quite weak assumptions.)

@daira
Copy link
Contributor Author

@daira daira commented Jul 17, 2017

A commitment based on a SNARK-friendly cipher such as MiMC could be post-quantum hiding and binding, and also practically efficient (even more so than Pedersen commitments).

However I think we're likely to go with Pedersen commitments for Sapling despite their failure to be post-quantum binding, because:

  • we have more assurance of their classical security (than, say, MiMC);
  • it wouldn't really affect post-quantum soundness because we've already lost on that until we have a post-quantum sound zk-SNARK;
  • they are statistically (and therefore post-quantum) hiding, so we don't lose on privacy relative to Sprout, at least not for this reason.
@daira
Copy link
Contributor Author

@daira daira commented Nov 10, 2017

@defuse wrote, before the Zcash launch:

Grover can also be used to speed up collision-finding to the cube-root rather than the square-root, e.g. http://arxiv.org/pdf/quant-ph/9705002.pdf (Høyer was my quantum computing prof and this was on the final exam!). So a quantum attacker can find a SHA256 collision in ~2^85 time and space. This impacts everywhere we rely on collision resistance of 256-bit values: the binding of the commitment scheme, faerie gold defense, etc.

I previously pointed out Bernstein's paper disputing that Brassard–Høyer–Tapp provides any cost improvement over classical parallel-rho collision search. Recently another quantum collision-search algorithm was published by André Chailloux, Marı́a Naya-Plasencia, and André Schrottenloher, with title "An efficient quantum collision search algorithm and implications on symmetric cryptography". Bernstein disputes the implication of better-than-classical efficiency of this one as well, in a comprehensive blog post.

Note that we don't claim resistance to quantum attacks on soundness / balance preservation. (Indeed, a DLP-breaking adversary can easily break soundness of the zk-SNARK, and a quantum adversary can apply the discrete-log variant of Shor's algorithm to do that.) We claim it only for privacy of transactions for which destination addresses are kept secret, and that does not, as far as I'm aware, rely on collision-resistance of any hash function in Sprout. In particular, the hiding property of SHA256Compress does not depend on collision resistance. We need to make sure that is still the case in Sapling, which is the topic of #2527, but I don't see any obstacle.

@defuse
Copy link
Contributor

@defuse defuse commented Jun 12, 2018

Another consideration for post-quantum Zcash is the proof-of-work. A Grover search could speed up finding solutions to Bitcoin's PoW, but this paper suggests Bitcoin ASICs are so fast that it will be a while before quantum computers can compete. The same paper suggests that hash-collision-based PoWs (Momentum, Equihash) are more resistant to quantum attack.

@daira
Copy link
Contributor Author

@daira daira commented Jan 12, 2019

@defuse posted a potential attack on privacy in Sapling by DLP-breaking adversaries: #2527 (comment) but it doesn't work: #2527 (comment)

@daira
Copy link
Contributor Author

@daira daira commented Aug 17, 2019

SIDH/SIKE isogeny-based cryptosystems are starting to look quite promising for post-quantum key exchange. Here's a recent paper with benchmarks: https://eprint.iacr.org/2018/1215

str4d added a commit to str4d/zcash that referenced this issue Oct 1, 2020
8ab24e8da Merge zcash#558: Add schnorrsig module which implements BIP-340 compliant signatures
f3733c543 Merge zcash#797: Fix Jacobi benchmarks and other benchmark improvements
cb5524adc Add benchmark for secp256k1_ge_set_gej_var
5c6af60ec Make jacobi benchmarks vary inputs
d0fdd5f00 Randomize the Z coordinates in bench_internal
c7a3424c5 Rename bench_internal variables
875d68b95 Merge zcash#699: Initialize field elements when resulting in infinity
54caf2e74 Merge zcash#799: Add fallback LE/BE for architectures with known endianness + SHA256 selftest
f431b3f28 valgrind_ctime_test: Add schnorrsig_sign
16ffa9d97 schnorrsig: Add taproot test case
8dfd53ee3 schnorrsig: Add benchmark for sign and verify
4e4352002 schnorrsig: Add BIP-340 compatible signing and verification
7332d2db6 schnorrsig: Add BIP-340 nonce function
7a703fd97 schnorrsig: Init empty experimental module
eabd9bc46 Allow initializing tagged sha256
6fcb5b845 extrakeys: Add keypair_xonly_tweak_add
58254463f extrakeys: Add keypair struct with create, pub and pub_xonly
f0010349b Separate helper functions for pubkey_create and seckey_tweak_add
910d9c284 extrakeys: Add xonly_pubkey_tweak_add & xonly_pubkey_tweak_add_test
176bfb111 Separate helper function for ec_pubkey_tweak_add
4cd2ee474 extrakeys: Add xonly_pubkey with serialize, parse and from_pubkey
f49c9896b Merge zcash#806: Trivial: Add test logs to gitignore
aabf00c15 Merge zcash#648: Prevent ints from wrapping around in scratch space functions
f5adab16a Merge zcash#805: Remove the extremely outdated TODO file.
bceefd654 Add test logs to gitignore
1c325199d Remove the extremely outdated TODO file.
47e6618e1 extrakeys: Init empty experimental module
3e08b02e2 Make the secp256k1_declassify argument constant
8bc6aeffa Add SHA256 selftest
670cdd3f8 Merge zcash#798: Check assumptions on integer implementation at compile time
5e5fb28b4 Use additional system macros to figure out endianness
7c068998b Compile-time check assumptions on integer types
02b6c87b5 Add support for (signed) __int128
979961c50 Merge zcash#787: Use preprocessor macros instead of autoconf to detect endianness
887bd1f8b Merge zcash#793: Make scalar/field choice depend on C-detected __int128 availability
0dccf98a2 Use preprocessor macros instead of autoconf to detect endianness
b2c8c42cf Merge zcash#795: Avoid linking libcrypto in the valgrind ct test.
57d3a3c64 Avoid linking libcrypto in the valgrind ct test.
79f1f7a4f Autodetect __int128 availability on the C side
0d7727f95 Add SECP256K1_FE_STORAGE_CONST_GET to 5x52 field
805082de1 Merge zcash#696: Run a Travis test on s390x (big endian)
39295362c Test travis s390x (big endian)
6034a04fb Merge zcash#778: secp256k1_gej_double_nonzero supports infinity
f60915906 Merge zcash#779: travis: Fix argument quoting for ./configure
9e49a9b25 travis: Fix argument quoting for ./configure
18d36327f secp256k1_gej_double_nonzero supports infinity
214cb3c32 Merge zcash#772: Improve constant-timeness on PowerPC
40412b193 Merge zcash#774: tests: Abort if malloc() fails during context cloning tests
2e1b9e045 tests: Abort if malloc() fails during context cloning tests
67a429f31 Suppress a harmless variable-time optimization by clang in _int_cmov
5b196338f Remove redundant "? 1 : 0" after comparisons in scalar code
3e5cfc5c7 Merge zcash#741: Remove unnecessary sign variable from wnaf_const
66bb9320c Merge zcash#773: Fix some compile problems on weird/old compilers.
1309c03c4 Fix some compile problems on weird/old compilers.
2309c7dd4 Merge zcash#769: Undef HAVE___INT128 in basic-config.h to fix gen_context compilation
22e578bb1 Undef HAVE___INT128 in basic-config.h to fix gen_context compilation
3f4a5a10e Merge zcash#765: remove dead store in ecdsa_signature_parse_der_lax
f00d6575c remove dead store in ecdsa_signature_parse_der_lax
dbd41db16 Merge zcash#759: Fix uninitialized variables in ecmult_multi test
2e7fc5b53 Fix uninitialized variables in ecmult_multi test
2ed54da18 Merge zcash#755: Recovery signing: add to constant time test, and eliminate non ct operators
28609507e Add tests for the cmov implementations
73596a85a Add ecdsa_sign_recoverable to the ctime tests
2876af4f8 Split ecdsa_sign logic into a new function and use it from ecdsa_sign and recovery
5e1c885ef Merge zcash#754: Fix uninit values passed into cmov
f79a7adcf Add valgrind uninit check to cmovs output
05d315aff Merge zcash#752: autoconf: Use ":" instead of "dnl" as a noop
a39c2b09d Fixed UB(arithmetics on uninit values) in cmovs
3a6fd7f63 Merge zcash#750: Add macOS to the CI
5e8747ae2 autoconf: Use ":" instead of "dnl" as a noop
71757da5c Explictly pass SECP256K1_BENCH_ITERS to the benchmarks in travis.sh
99bd661d7 Replace travis_wait with a loop printing "\a" to stdout every minute
bc818b160 Bump travis Ubuntu from xenial(16.04) to bionic(18.04)
0c5ff9066 Add macOS support to travis
b6807d91d Move travis script into a standalone sh file
f39f99be0 Merge zcash#701: Make ec_ arithmetic more consistent and add documentation
37dba329c Remove unnecessary sign variable from wnaf_const
6bb0b77e1 Fix test_constant_wnaf for -1 and add a test for it.
39198a03e Merge zcash#732: Retry if r is zero during signing
59a8de8f6 Merge zcash#742: Fix typo in ecmult_const_impl.h
4e284655d Fix typo in ecmult_const_impl.h
f862b4ca1 Merge zcash#740: Make recovery/main_impl.h non-executable
ffef45c98 Make recovery/main_impl.h non-executable
2361b3719 Merge zcash#735: build: fix OpenSSL EC detection on macOS
3b7d26b23 build: add SECP_TEST_INCLUDES to bench_verify CPPFLAGS
84b5fc5bc build: fix OpenSSL EC detection on macOS
37ed51a7e Make ecdsa_sig_sign constant-time again after reverting 25e3cfb
93d343bfc Revert "ecdsa_impl: replace scalar if-checks with VERIFY_CHECKs in ecdsa_sig_sign"
7e3952ae8 Clarify documentation of tweak functions.
89853a0f2 Make tweak function documentation more consistent.
41fc78560 Make ec_privkey functions aliases for ec_seckey_negate, ec_seckey_tweak_add and ec_seckey_mul
22911ee6d Rename private key to secret key in public API (with the exception of function names)
5a73f14d6 Mention that value is unspecified for In/Out parameters if the function returns 0
f03df0e6d Define valid ECDSA keys in the documentation of seckey_verify
5894e1f1d Return 0 if the given seckey is invalid in privkey_negate, privkey_tweak_add and privkey_tweak_mul
8f814cddb Add test for boundary conditions of scalar_set_b32 with respect to overflows
3fec98260 Use scalar_set_b32_seckey in ecdsa_sign, pubkey_create and seckey_verify
9ab2cbe0e Add scalar_set_b32_seckey which does the same as scalar_set_b32 and also returns whether it's a valid secret key
4f27e344c Merge zcash#728: Suppress a harmless variable-time optimization by clang in memczero
01993878b Add test for memczero()
52a03512c Suppress a harmless variable-time optimization by clang in memczero
8f78e208a Merge zcash#722: Context isn't freed in the ECDH benchmark
ed1b91171 Merge zcash#700: Allow overriding default flags
85b35afa7 Add running benchmarks regularly and under valgrind in travis
ca4906b02 Pass num of iters to benchmarks as variable, and define envvar
02dd5f1bb free the ctx at the end of bench_ecdh
e9fccd4de Merge zcash#708: Constant-time behaviour test using valgrind memtest.
08fb6c492 Run valgrind_ctime_test in travis
3d2302257 Constant-time behaviour test using valgrind memtest.
96d8ccbd1 Merge zcash#710: Eliminate harmless non-constant time operations on secret data.
0585b8b2e Merge zcash#718: Clarify that a secp256k1_ecdh_hash_function must return 0 or 1
7b50483ad Adds a declassify operation to aid constant-time analysis.
34a67c773 Eliminate harmless non-constant time operations on secret data.
ca739cba2 Compile with optimization flag -O2 by default instead of -O3
eb45ef338 Clarify that a secp256k1_ecdh_hash_function must return 0 or 1
856a01d6a Merge zcash#714: doc: document the length requirements of output parameter.
d72b9e248 Merge zcash#682: Remove Java Native Interface
4b48a4310 doc: document the length requirements of output parameter.
1b4d256e2 Merge zcash#713: Docstrings
dabfea7e2 field: extend docstring of secp256k1_fe_normalize
dc7d8fd9e scalar: extend docstring of secp256k1_scalar_set_b32
074ab582d Merge zcash#704: README: add a section for test coverage
acb7f97eb README: add a section for test coverage
227a4f2d0 Merge zcash#709: Remove secret-dependant non-constant time operation in ecmult_const.
d567b779f Clarify comments about use of rzr on ge functions and abs function.
2241ae6d1 Remove secret-dependant non-constant time operation in ecmult_const.
642cd062b Remove Java Native Interface
83fb1bcef Remove -O2 from default CFLAGS because this would override the -O3 flag (see AC_PROG_CC in the Autoconf manual)
ecba8138e Append instead of Prepend user-CFLAGS to default CFLAGS allowing the user to override default variables
613c34cd8 Remove test in configure.ac because it doesn't have an effect
f45d89710 Merge zcash#703: Overhaul README.md
2e759ec75 Overhaul README.md
d644dda5c Merge zcash#689: Remove "except in benchmarks" exception for fp math
bde2a3228 Convert bench.h to fixed-point math
47a7b8382 Clear field elements when writing infinity
61d1ecb02 Added test with additions resulting in infinity
387d723c3 Merge zcash#679: Add SECURITY.md
0db61d25c Merge zcash#685: Fix issue where travis does not show the ./tests seed…
a0771d15e Explicitly disable buffering for stderr in tests
fb424fbba Make travis show the ./tests seed by removing stdout buffering and always cat tests.log after a travis run.
22a603118 Merge zcash#690: Add valgrind check to travis
544002c00 Merge zcash#678: Preventing compiler optimizations in benchmarks without a memory fence
dd98cc988 travis: Added a valgrind test without endro and enabled recovery+ecdh
b4c1382a8 Add valgrind check to travis
0c774d89e Merge zcash#688: Fix ASM setting in travis
5c5f71eea Fix ASM setting in travis
e2625f8a9 Merge zcash#684: Make no-float policy explicit
bae1bea3c Make no-float policy explicit
78c383634 Add SECURITY.md
362bb2560 Modified bench_scalar_split so it won't get optimized out
73a30c6b5 Added accumulators and checks on benchmarks so they won't get optimized out
770b3dcd6 Merge zcash#677: Remove note about heap allocation in secp256k1_ecmult_odd_multiples_table_storage_var
b76142ff2 Remove note about heap allocation in secp256k1_ecmult_odd_multiples_table_storage_var which was removed in 47045270fa90f81205d989f7107769bce1e71c4d
137d304a6 Merge zcash#647: Increase robustness against UB in secp256k1_scalar_cadd_bit
0d9540b13 Merge zcash#664: Remove mention of ec_privkey_export because it doesn't exist
59782c68b Remove mention of ec_privkey_export because it doesn't exist
96cd94e38 Merge zcash#337: variable sized precomputed table for signing
dcb2e3b3f variable signing precompute table
b4bff9902 Merge zcash#661: Make ./configure string consistent
a467047e1 Make ./configure string consistent
e729cc7f5 Merge zcash#657: Fix a nit in the recovery tests
b64a2e259 Fix a nit in the recovery tests
e028aa33d Merge zcash#650: secp256k1/src/tests.c:  Properly handle sscanf return value
f1e11d363 Merge zcash#654: Fix typo (∞)
ef83281c3 Merge pull request zcash#656 from real-or-random/patch-1
556caad2c Fix typo in docs for _context_set_illegal_callback
0d82732a9 Improve VERIFY_CHECK of overflow in secp256k1_scalar_cadd_bit. This added check ensures that any curve order overflow doesn't go undetected due a uint32_t overflow.
786dfb49f Merge zcash#583: JNI: fix use sig array
e95f8ab09 Merge zcash#644: Avoid optimizing out a verify_check
384f55606 Merge zcash#652: README.md: update instruction to run tests
ee56accd4 Merge zcash#651: Fix typo in secp256k1_preallocated.h
7b9b11723 Merge zcash#640: scalar_impl.h: fix includes
d99bec2e2 Merge zcash#655: jni: Use only Guava for hex encoding and decoding
2abcf951a jni: Use only Guava for hex encoding and decoding
271582b3b Fix typo
60f7f2de5 Don't assume that ALIGNMENT > 1 in tests
ada6361de Use ROUND_TO_ALIGN in scratch_create
8ecc6ce50 Add check preventing rounding to alignment from wrapping around in scratch_alloc
4edaf06fb Add check preventing integer multiplication wrapping around in scratch_max_allocation
ce6d43826 README.md: update instruction to run tests
b1e68cb8e Fix typo in secp256k1_preallocated.h
a11c76c59 secp256k1/src/tests.c:  Properly handle sscanf return value
8fe63e565 Increase robustness against UB. Thanks to elichai2 who noted that the literal '1' is a signed integer, and that shifting a signed 32-bit integer by 31 bits causes an overflow and yields undefined behaviour. While 'scalar_low_impl''s 'secp256k1_scalar_cadd_bit' is only used for testing purposes and currently the 'bit' parameter is only 0 or 1, it is better to avoid undefined behaviour in case the used domain of 'secp256k1_scalar_cadd_bit' expands.
94ae7cbf8 Moved a dereference so the null check will be before the dereferencing
2cb73b106 scalar_impl.h: fix includes
fa3301713 Merge zcash#634: Add a descriptive comment for secp256k1_ecmult_const.
ee9e68cd3 Add a descriptive comment for secp256k1_ecmult_const.
d0d738d32 Merge zcash#631: typo in comment for secp256k1_ec_pubkey_tweak_mul ()
6914c2527 typo in comment for secp256k1_ec_pubkey_tweak_mul ()
e541a90ef Merge zcash#629: Avoid calling _is_zero when _set_b32 fails.
f34b0c3f3 Merge zcash#630: Note intention of timing sidechannel freeness.
8d1563b0f Note intention of timing sidechannel freeness.
1669bb286 Merge zcash#628: Fix ability to compile tests without -DVERIFY.
ecc94abcc Merge zcash#627: Guard memcmp in tests against mixed size inputs.
544435fc9 Merge zcash#578: Avoid implementation-defined and undefined behavior when dealing with sizes
143dc6e9e Merge zcash#595: Allow to use external default callbacks
e49f7991c Add missing #(un)defines to base-config.h
77defd2c3 Add secp256k1_ prefix to default callback functions
908bdce64 Include stdio.h and stdlib.h explicitly in secp256k1.c
5db782e65 Allow usage of external default callbacks
6095a863f Replace CHECKs for no_precomp ctx by ARG_CHECKs without a return
cd473e02c Avoid calling secp256k1_*_is_zero when secp256k1_*_set_b32 fails.
6c36de7a3 Merge zcash#600: scratch space: use single allocation
98836b11f scratch: replace frames with "checkpoint" system
7623cf2b9 scratch: save a couple bytes of unnecessarily-allocated memory
a7a164f2c scratch: rename `max_size` to `size`, document that extra will actually be allocated
5a4bc0bb9 scratch: unify allocations
c2b028a28 scratch space: thread `error_callback` into all scratch space functions
0be1a4ae6 scratch: add magic bytes to beginning of structure
92a48a764 scratch space: use single allocation
40839e21b Merge zcash#592: Use trivial algorithm in ecmult_multi if scratch space is small
dcf392027 Fix ability to compile tests without -DVERIFY.
a484e0008 Merge zcash#566: Enable context creation in preallocated memory
0522caac8 Explain caller's obligations for preallocated memory
238305fdb Move _preallocated functions to separate header
695feb6fb Export _preallocated functions
814cc78d7 Add tests for contexts in preallocated memory
ba12dd08d Check arguments of _preallocated functions
5feadde46 Support cloning a context into preallocated memory
c4fd5dab4 Switch to a single malloc call
ef020de16 Add size constants for preallocated memory
1bf7c056b Prepare for manual memory management in preallocated memory
248bffb05 Guard memcmp in tests against mixed size inputs.
36698dcfe Merge zcash#596: Make WINDOW_G configurable
a61a93ff5 Clean up ./configure help strings
2842dc523 Make WINDOW_G configurable
1a02d6ce5 Merge zcash#626: Revert "Merge zcash#620: Install headers automatically"
662918cb2 Revert "Merge zcash#620: Install headers automatically"
14c7dbd44 Simplify control flow in DER parsing
ec8f20bab Avoid out-of-bound pointers and integer overflows in size comparisons
01ee1b3b3 Parse DER-enconded length into a size_t instead of an int
912680ed8 Merge zcash#561: Respect LDFLAGS and #undef STATIC_PRECOMPUTATION if using basic config
91fae3ace Merge zcash#620: Install headers automatically
5df77a0ed Merge zcash#533: Make sure we're not using an uninitialized variable in secp256k1_wnaf_const(...)
975e51e0d Merge zcash#617: Pass scalar by reference in secp256k1_wnaf_const()
735fbde04 Merge zcash#619: Clear a copied secret key after negation
16e86150d Install headers automatically
069870d92 Clear a copied secret key after negation
8979ec0d9 Pass scalar by reference in secp256k1_wnaf_const()
84a808598 Merge zcash#612: Allow field_10x26_arm.s to compile for ARMv7 architecture
d4d270a59 Allow field_10x26_arm.s to compile for ARMv7 architecture
b19c00006 Merge zcash#607: Use size_t shifts when computing a size_t
4d01bc2d9 Merge zcash#606: travis: Remove unused sudo:false
e6d01e934 Use size_t shifts when computing a size_t
7667532bd travis: Remove unused sudo:false
248f04661 Make sure we're not using an uninitialized variable in secp256k1_wnaf_const(...)
9ab96f7b1 Use trivial algorithm in ecmult_multi if scratch space is small
ee99f12f3 Merge zcash#599: Switch x86_64 asm to use "i" instead of "n" for immediate values.
d58bc93f2 Switch x86_64 asm to use "i" instead of "n" for immediate values.
05362ee04 Merge zcash#597: Add $(COMMON_LIB) to exhaustive tests to fix ARM asm build
83483869a Add $(COMMON_LIB) to exhaustive tests to fix ARM asm build
aa15154a4 Merge zcash#568: Fix integer overflow in ecmult_multi_var when n is large
2277af5ff Fix integer overflow in ecmult_multi_var when n is large
dbed75d96 Undefine `STATIC_PRECOMPUTATION` if using the basic config
310111e09 Keep LDFLAGS if `--coverage`
85d0e1bcc Merge zcash#591: Make bench_internal obey secp256k1_fe_sqrt's contract wrt aliasing.
14196379e Merge zcash#580: Add trivial ecmult_multi algorithm which does not require a scratch space
a697d82da Add trivial ecmult_multi to the benchmark tool
bade61741 Add trivial ecmult_multi algorithm. It is selected when no scratch space is given and just multiplies and adds the points.
5545e13de Merge zcash#584: configure: Use CFLAGS_FOR_BUILD when checking native compiler
20c5869df Merge zcash#516: improvements to random seed in src/tests.c
b76e45d5d Make bench_internal obey secp256k1_fe_sqrt's contract wrt aliasing.
870a97764 Merge zcash#562: Make use of TAG_PUBKEY constants in secp256k1_eckey_pubkey_parse
be40c4d0b Fixup for C90 mixed declarations.
c71dd2c08 Merge zcash#509: Fix algorithm selection in bench_ecmult
6492bf88c Merge zcash#518: Summarize build options after running configure
0e9ada194 Merge zcash#567: Correct order of libs returned on pkg-config --libs --static libsecp2…
e96901a4b Merge zcash#587: Make randomization of a non-signing context a noop
58df8d03a Merge zcash#511: Portability fix for the configure scripts generated
2ebdad772 Merge zcash#552: Make constants static:
1c131affd Merge zcash#551: secp256k1_fe_sqrt: Verify that the arguments don't alias.
ba698f883 Merge zcash#539: Assorted minor corrections
949e85b00 Merge zcash#550: Optimize secp256k1_fe_normalize_weak calls.
a34bcaadf Actually pass CFLAGS_FOR_BUILD and LDFLAGS_FOR_BUILD to linker
2d5f4cebd configure: Use CFLAGS_FOR_BUILD when checking native compiler
b408c6a8b Merge zcash#579: Use __GNUC_PREREQ for detecting __builtin_expect
619837521 Make randomization of a non-signing context a noop
74e2dbd68 JNI: fix use sig array
c663397f4 Use __GNUC_PREREQ for detecting __builtin_expect
3cb057f84 Fix possible integer overflow in DER parsing
e34ceb333 Merge zcash#557: Eliminate scratch memory used when generating contexts
b3bf5f99a ecmult_impl: expand comment to explain how effective affine interacts with everything
efa783f8f Store z-ratios in the 'x' coord they'll recover
ffd3b346f add `secp256k1_ge_set_all_gej_var` test which deals with many infinite points
84740acd2 ecmult_impl: save one fe_inv_var
47045270f ecmult_impl: eliminate scratch memory used when generating context
7f7a2ed3a ecmult_gen_impl: eliminate scratch memory used when generating context
314a61d72 Merge zcash#553: add static context object which has no capabilities
89a20a894 Correct order of libs returned on pkg-config --libs --static libsecp256k1 call.
1086fda4c Merge zcash#354: [ECDH API change] Support custom hash function
d3cb1f95e Make use of TAG_PUBKEY constants in secp256k1_eckey_pubkey_parse
40fde611b prevent attempts to modify `secp256k1_context_no_precomp`
ed7c08417 add static context object which has no capabilities
496c5b43b Make constants static: static const secp256k1_ge secp256k1_ge_const_g; static const int CURVE_B;
bf8b86cc0 secp256k1_fe_sqrt: Verify that the arguments don't alias.
9bd89c836 Optimize secp256k1_fe_normalize_weak calls. Move secp256k1_fe_normalize_weak calls out of ECMULT_TABLE_GET_GE and ECMULT_TABLE_GET_GE_STORAGE and into secp256k1_ge_globalz_set_table_gej instead.
52ab96fed clean dependendies in field_*_impl.h
deff5edd4 Correct math typos in field_*.h
4efb3f8dd Add check that restrict pointers don't alias with all parameters.
1e6f1f5ad Merge zcash#529: fix tests.c in the count == 0 case
c8fbc3c39 [ECDH API change] Allow pass arbitrary data to hash function
b00be6505 [ECDH API change] Support custom hash function
95e99f196 fix tests.c in the count == 0 case
452d8e4d2 Merge zcash#523: scratch: add stack frame support
6fe50439a scratch: add stack frame support
9bc2e2650 Merge zcash#522: parameterize ecmult_const over input size
7c1b91ba4 parameterize ecmult_const over input size
dbc3ddd5e Merge zcash#513: Increase sparsity of pippenger fixed window naf representation
3965027c8 Summarize build options in configure script
0f0517369 Fix algorithm selection in bench_ecmult
fb9271dcf Merge zcash#510: add a couple missing `const`s to ecmult_pippenger_wnaf
cd5f6028e Merge zcash#515: Fix typo
09146ae85 Merge zcash#512: secp256k1_ec_privkey_negate - fix documentation
ec0a7b3ae Don't touch leading zeros in wnaf_fixed.
9e36d1bfe Fix bug in wnaf_fixed where the wnaf array is not completely zeroed when given a 0 scalar.
96f68a0af Don't invert scalar in wnaf_fixed when it is even because a caller might intentionally give a scalar with many leading zeros.
8b3841c91 fix bug in fread() failure check
cddef0c0b tests: add warning message when /dev/urandom fails
9b7c47a21 Fix typo
6dbb00786 Increase sparsity of pippenger fixed window naf representation
1646ace4d secp256k1_ec_privkey_negate - fix documentation
270f6c80d Portability fix for the configure scripts generated
9b3ff0309 add a couple missing `const`s to ecmult_pippenger_wnaf
cd329dbc3 Merge zcash#460: [build] Update ax_jni_include_dir.m4 macro
7f9c1a156 Merge zcash#498: tests: Avoid calling fclose(...) with an invalid argument
f99aa8d4d Merge zcash#499: tests: Make sure we get the requested number of bytes from /dev/urandom
b549d3d5f Merge zcash#472: [build] Set --enable-jni to no by default instead of auto.
d33352151 Merge zcash#494: Support OpenSSL versions >= 1.1 for ENABLE_OPENSSL_TESTS
2ef8ea5d2 Merge zcash#495: Add bench_ecmult to .gitignore
82a96e458 tests: Make sure we get the requested number of bytes from /dev/urandom
5aae5b5bb Avoid calling fclose(...) with an invalid argument
cb32940df Add bench_ecmult to .gitignore
31abd3ab8 Support OpenSSL versions >= 1.1 for ENABLE_OPENSSL_TESTS
c95f6f136 Merge zcash#487: fix tests typo, s/changed/unchanged
fb46c8388 Merge zcash#463: Reduce usage of hardcoded size constants
02f5001df Merge zcash#490: Disambiguate bench functions and types
1f46d6089 Disambiguate bench functions and types
f54c6c508 Merge zcash#480: Enable benchmark building by default
c77fc0859 Merge zcash#486: Add pippenger_wnaf for multi-multiplication
d2f9c6b5d Use more precise pippenger bucket windows
4c950bbea Save some additions per window in _pippenger_wnaf
a58f543f5 Add flags for choosing algorithm in ecmult_multi benchmark
36b22c933 Use scratch space dependent batching in ecmult_multi
355a38f11 Add pippenger_wnaf ecmult_multi
bc65aa794 Add bench_ecmult
dba5471b6 Add ecmult_multi tests
8c1c831bd Generalize Strauss to support multiple points
548de42ec add resizeable scratch space API
0e96cdc6b fix typo, s/changed/unchanged
c7680e570 Reduce usage of hardcoded size constants
7a78f6059 Print whether we're building benchmarks
4afec9f1a Build benchmarks by default
57752d28b [build] Set --enable-jni to no by default instead of auto.
e7daa9b3c [build] Tweak JNI macro to warn instead of error for JNI not found.
5b2297792 [build] Update ax_jni_include_dir.m4 macro to deal with recent versions of macOS

git-subtree-dir: src/secp256k1
git-subtree-split: 8ab24e8dad9d43fc6661842149899e3cc9213b24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.