- `secp256k1_scalar_set_int` in scalar_low uses input mod EXHAUSTIVE_TEST_ORDER
- directly store s in sig64 without reducing it mod the group order for testing
When configured with `--disable-module-ecdh --enable-module-recovery`, then
`./tests 64 81af32fd7ab8c9cbc2e62a689f642106` fails with
```
src/modules/ellswift/tests_impl.h:396: test condition failed: secp256k1_memcmp_var(share32_bad, share32a, 32) != 0
```
This tests verifies that changing the `party` bit of the
`secp256k1_ellswift_xdh` function results in a different share. However, that's
not the case when the secret keys of both parties are the same and this is
actually what happens in the observed test failure. The keys can be equal in
this test case because they are created by the `random_scalar_order_test`
function whose output is not uniformly random (it's biased towards 0).
This commit restores the assummption that the secret keys differ.
The scheme implemented is described below, and largely follows the paper
"SwiftEC: Shallue–van de Woestijne Indifferentiable Function To Elliptic Curves",
by Chavez-Saab, Rodriguez-Henriquez, and Tibouchi
(https://eprint.iacr.org/2022/759).
A new 64-byte public key format is introduced, with the property that *every*
64-byte array is an encoding for a non-infinite curve point. Each curve point
has roughly 2^256 distinct encodings. This permits disguising public keys as
uniformly random bytes.
The new API functions:
* secp256k1_ellswift_encode: convert a normal public key to an ellswift 64-byte
public key, using additional entropy to pick among the many possible
encodings.
* secp256k1_ellswift_decode: convert an ellswift 64-byte public key to a normal
public key.
* secp256k1_ellswift_create: a faster and safer equivalent to calling
secp256k1_ec_pubkey_create + secp256k1_ellswift_encode.
* secp256k1_ellswift_xdh: x-only ECDH directly on ellswift 64-byte public keys,
where the key encodings are fed to the hash function.
The scheme itself is documented in secp256k1_ellswift.h.
f3126fdfec norm arg: remove prove edge tests which are now covered by vectors (Jonas Nick)
847ed9ecb2 norm arg: add verification to prove vectors (Jonas Nick)
cf797ed2a4 norm arg: add prove test vectors (Jonas Nick)
095c1e749c norm arg: add prove_const to tests (Jonas Nick)
bf7bf8a64f norm arg: split norm_arg_zero into prove_edge and verify_zero_len (Jonas Nick)
a70c4d4a8a norm arg: add test vector for |n| = 0 (Jonas Nick)
f5e4b16f0f norm arg: add test vector for sign bit malleability (Jonas Nick)
c0de361fc5 norm arg: allow X and R to be the point at infinity (Jonas Nick)
f22834f202 norm arg: add verify vector for n = [0], l = [0] (Jonas Nick)
d8e7f3763b musig: move ge_{serialize,parse}_ext to module-independent file (Jonas Nick)
Pull request description:
ACKs for top commit:
Liam-Eagen:
ACK f3126fd
Tree-SHA512: 1aad86521fce74435beabe7690c7fcc38ad9ae7a884ddcab69ef825b573433f700723a7672d29df1b4465bc33d5957b6a46f657f988cfd2cc73fa94a3472357d
8e142ca410 Move `SECP256K1_INLINE` macro definition out from `include/secp256k1.h` (Hennadii Stepanov)
77445898a5 Remove `SECP256K1_INLINE` usage from examples (Hennadii Stepanov)
Pull request description:
From [IRC](https://gnusha.org/secp256k1/2023-01-31.log):
> 06:29 \< hebasto\> What are reasons to define the `SECP256K1_INLINE` macro in user's `include/secp256k1.h` header, while it is used internally only?
> 06:32 \< hebasto\> I mean, any other (or a new dedicated) header in `src` looks more appropriate, no?
> 06:35 \< sipa\> I think it may just predate any "utility" internal headers.
> 06:42 \< sipa\> I think it makes sense to move it to util.h
Pros:
- it is a step in direction to better organized headers (in context of #924, #1039)
Cons:
- code duplication for `SECP256K1_GNUC_PREREQ` macro
ACKs for top commit:
sipa:
utACK 8e142ca410
real-or-random:
utACK 8e142ca410
Tree-SHA512: 180e0ba7c2ef242b765f20698b67d06c492b7b70866c21db27c18d8b2e85c3e11f86c6cb99ffa88bbd23891ce3ee8a24bc528f2c91167ec2fddc167463f78eac
b43dd83b43 musig: add missing static keyword to function (Jonas Nick)
068e6a036a musig: add test vectors from BIP MuSig (Jonas Nick)
36621d13be musig: update to BIP v1.0.0-rc.2 "Add ''pk'' arg to ''NonceGen''" (Jonas Nick)
d717a4980b musig: update to BIP v0.8 "Switch from X-only to plain pk inputs." (Jonas Nick)
304f1bc96d extrakeys: add pubkey_sort test vectors from BIP MuSig2 (Jonas Nick)
ae89051547 extrakeys: replace xonly_sort with pubkey_sort (Jonas Nick)
98242fcdd9 extrakeys: add secp256k1_pubkey_cmp (Jonas Nick)
73d5b6654d musig: update to BIP v0.7.0 (NonceGen) (Jonas Nick)
060887e9d7 musig: update to BIP v0.5.1 "Rename ordinary tweaking to plain" (Jonas Nick)
cbe2815633 musig: update to BIP v0.4 "Allow the output of NonceAgg to be inf" (Jonas Nick)
206017d67d musig: update to BIP v0.3 (NonceGen) (Jonas Nick)
d800dd55db musig: remove test vectors (Jonas Nick)
Pull request description:
Version 1.0.0-rc.3 of BIP MuSig2 can be found [here](https://github.com/jonasnick/bips/pull/75). This PR does _not_ implement the following optional features that have been added to BIP MuSig2:
- variable length messages
- deterministic signing
- identifiable aborts
The PR also does _not_ yet change the `secnonce` structure to also contain the signer's public key (which would also imply changing the seckey argument in `sign` to a keypair). Additionally, we may want to rename some things in the future to be more consistent with the BIP (e.g. keyagg_cache vs. keyagg_ctx, applytweak vs. tweak_add).
ACKs for top commit:
ariard:
Light Code Review ACK b43dd83b, mostly looks on how the user API will make sense for Lightning, thanks for the answers!
real-or-random:
ACK b43dd83b43
Tree-SHA512: 9b1410951b55a1b0e6590b8c302052996d1fb6d9771765498b4282ff68b44ab0d6add8144c9330217b682ec5a93508b5546099db9a1f2c865f99253010dd76f4
