8e142ca4102ade1b90dcb06d6c78405ef3220599 Move `SECP256K1_INLINE` macro definition out from `include/secp256k1.h` (Hennadii Stepanov)
77445898a5852ecd38ab95cfb329333a82673115 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 8e142ca4102ade1b90dcb06d6c78405ef3220599
real-or-random:
utACK 8e142ca410
Tree-SHA512: 180e0ba7c2ef242b765f20698b67d06c492b7b70866c21db27c18d8b2e85c3e11f86c6cb99ffa88bbd23891ce3ee8a24bc528f2c91167ec2fddc167463f78eac
1ecb94ebe9800900c7dd3a4f9883c600e25eecf7 build: Make `SECP_VALGRIND_CHECK` preserve `CPPFLAGS` (Hennadii Stepanov)
Pull request description:
It was overlooked in #862 and #1027.
ACKs for top commit:
real-or-random:
utACK 1ecb94ebe9800900c7dd3a4f9883c600e25eecf7
Tree-SHA512: 263fc600ce9743e4aad767150f706bf7d4325dabb9c363ed57f08fe38faea94d7d1999804947cffeacbe698bb6d959ee6de3f6e50400050a390ecc0db957e426
35ada3b954ccc6c54628fb3bcc0365d176297019 tests: lint wycheproof's python script (RandomLattice)
Pull request description:
This PR lints tests_wycheproof_generate.py according to bitcoin's python linting scripts. This is a follow-up to PR #1245.
ACKs for top commit:
sipa:
utACK 35ada3b954ccc6c54628fb3bcc0365d176297019
real-or-random:
utACK 35ada3b954ccc6c54628fb3bcc0365d176297019
Tree-SHA512: ea405060d2e73ff3543626687de5bc5282be923b914bd5c8c53e65df8dca9bea0000c416603095efff29bc7ae43c2081454c4e506db0f6805443d023fbffaf4c
ef49a11d29601e09e94134975c968e92c0214102 build: allow static or shared but not both (Cory Fields)
36b0adf1b90139a41fdcb94390d0bb06e9224795 build: remove warning until it's reproducible (Cory Fields)
Pull request description:
Continuing from here: https://github.com/bitcoin-core/secp256k1/issues/1224#issuecomment-1460438227
Unfortunately it wasn't really possible to keep a clean diff here because of the nature of the change. I suggest reviewing the lib creation stuff in its entirety, sorry about that :\
Rather than allowing for shared and static libs to be built at the same time like autotools, this PR switches to the CMake convention of allowing only 1.
A new `BUILD_SHARED_LIBS` option is added to match CMake convention, as well as a `SECP256K1_DISABLE_SHARED` option which overrides it. That way even projects which have `BUILD_SHARED_LIBS=1` can opt-into a static libsecp in particular.
Details:
Two object libraries are created: `secp256k1_asm` and `secp256k1_precomputed_objs`. Some tests/benchmarks use the object libraries directly, some link against the real lib: `secp256k1`.
Because the objs don't know what they're going to be linked into, they need to be told how to deal with PIC.
The `DEFINE_SYMBOL` property sets the `DLL_EXPORT` define as necessary (when building a shared lib)
ACKs for top commit:
hebasto:
re-ACK ef49a11d29601e09e94134975c968e92c0214102, only [suggested](https://github.com/bitcoin-core/secp256k1/pull/1230#pullrequestreview-1388191165) changes since my recent [review](https://github.com/bitcoin-core/secp256k1/pull/1230#pullrequestreview-1352125381).
real-or-random:
ACK ef49a11d29601e09e94134975c968e92c0214102
Tree-SHA512: 8870de305176fdb677caff0fdfc6f8c59c0e906489cb72bc9980e551002812685e59e20d731f2a82e33628bdfbb7261eafd6f228038cad3ec83bd74335959600
a575339c0282ba49a4f46c9c660a4cc3b6bfc703 Remove bits argument from secp256k1_wnaf_const (always 256) (Pieter Wuille)
Pull request description:
There is little reason for having the number of bits in the scalar as a parameter, as I don't think there are any (current) use cases for non-256-bit scalars.
ACKs for top commit:
jonasnick:
ACK a575339c0282ba49a4f46c9c660a4cc3b6bfc703
real-or-random:
utACK a575339c0282ba49a4f46c9c660a4cc3b6bfc703
Tree-SHA512: 994b1f19b4c513f6d070ed259a5d6f221a0c2450271ec824c5eba1cd0ecace276de391c170285bfeae96aaf8f1e0f7fe6260966ded0336c75c522ab6c56d182c
13c438cdeed358a20b1f0324ee36a6cadfaf0016 sync-upstream: Use --autostash to handle uncommitted changes (Tim Ruffing)
Pull request description:
This makes it possible to use sync-upstream with uncommitted changes. (This is in particular helpful when working on the script itself.)
Without this commit, git pull will fail due to the uncommitted changes.
ACKs for top commit:
apoelstra:
utACK 13c438cdeed358a20b1f0324ee36a6cadfaf0016
Tree-SHA512: c3a2fce68382bf4e769c64bbdc5666a8f4d9cf6f387e7d8af408e9c3e07b4a875205b7cdae9f647b7127128c13ee58effc0045ac5faf5fba2851b38af40439e8
This PR lints tests_wycheproof_generate.py according to pylint.
This is a follow-up to PR #1245.
Co-authored-by: Sean Andersen <6730974+andozw@users.noreply.github.com>
06c67dea9f6d46d3e24e810900fbb03045eae641 autotools: Don't regenerate Wycheproof header automatically (Tim Ruffing)
Pull request description:
This is a hot fix for https://github.com/bitcoin/bitcoin/pull/27445 .
---
Pregenerated files that we distribute should not have dependencies in Makefile.am. For rationale, see the comments about the precomputed table files.
See also https://github.com/bitcoin/bitcoin/pull/27445#issuecomment-1502994264 .
ACKs for top commit:
hebasto:
ACK 06c67dea9f6d46d3e24e810900fbb03045eae641
RandomLattice:
ACK 06c67dea9f
Tree-SHA512: fa7f44eaa1c7e42ecba5829ac1b8ae8b5826d1a1551e01c3caf37af780bd5c102c8f54e88520723937f7016d93c67b62a334c7a28b96c4f422a38fcf8e6a1984
This makes it possible to use sync-upstream with uncommitted changes. (This
is in particular helpful when working on the script itself.)
Without this commit, git pull will fail due to the uncommitted changes.
96f48538503ff40bf0017652c4b4f3a42cd3fa94 ct: Use volatile "trick" in all fe/scalar cmov implementations (Tim Ruffing)
Pull request description:
ACKs for top commit:
jonasnick:
ACK 96f48538503ff40bf0017652c4b4f3a42cd3fa94
Tree-SHA512: b3524a817ad8787a19dd28fc38523ab0ee2ddb72c5d88dfef566a9baa849b8d6a12df93030ecf97251e078128ec8203478bf98f3e8d9b28cc595ea5e8579c762
Apparently clang 15 is able to compile our cmov code into a branch,
at least for fe_cmov and fe_storage_cmov. This commit makes the
condition volatile in all cmov implementations (except ge but that
one only calls into the fe impls).
This is just a quick fix. We should still look into other methods,
e.g., asm and #457. We should also consider not caring about
constant-time in scalar_low_impl.h
We should also consider testing on very new compilers in nightly CI,
see https://github.com/bitcoin-core/secp256k1/pull/864#issuecomment-769211867
6a37b2a5ea9075c5dff14b3067c61114a334a2ba changelog: Fix link (Tim Ruffing)
Pull request description:
Top commit has no ACKs.
Tree-SHA512: 70d50c8fe958a197eb527e51c6f8120609e3166d93bfc1bbec75a3cb565c406d5ba0e6d088a724dcfda422b6594abf53f507211946a0533515df371d5d2a91bf
e5de45460953c8ae16521b1928ac14de218998a3 tests: Add Wycheproof ECDSA vectors (RandomLattice)
Pull request description:
This PR adds a test using the Wycheproof vectors as outlined in #1106. We add all 463 ECDSA test vectors. These vectors cover:
- edge cases in arithmetic operations
- signatures with special values for (r,s) that should be rejected
- special cases of public keys
The vectors are pulled from the Wycheproof project using a python script to emit C code.
All the new ECDSA Wycheproof vectors pass.
ACKs for top commit:
sipa:
ACK e5de45460953c8ae16521b1928ac14de218998a3
real-or-random:
ACK e5de45460953c8ae16521b1928ac14de218998a3
Tree-SHA512: e9684f14ff3f5225a4a4949b490e07527d559c28aa61ed03c03bc52ea64785f0b80b9e1b1628665eacf24006526271ea0fb108629c9c3c1d758e52d214a056f1
0f8642079b0f2e4874393792f5854e3c33742cbd Add exhaustive tests for ecmult_const_xonly (Pieter Wuille)
4485926ace489d87929be5218ae1ff3aa8591006 Add x-only ecmult_const version for x=n/d (Pieter Wuille)
Pull request description:
This implements a generalization of Peter Dettman's sqrt-less x-only random-base multiplication algorithm from #262, using the Jacobi symbol algorithm from #979. The generalization is to permit the X coordinate of the base point to be specified as a fraction $n/d$:
To compute $x(q \cdot P)$, where $x(P) = n/d$:
* Compute $g=n^3 + 7d^3$.
* Let $P' = (ng, g^2, 1)$ (the Jacobian coordinates of $P$ mapped to the isomorphic curve $y^2 = x^3 + 7(dg)^3$).
* Compute the Jacobian coordinates $(X',Y',Z') = q \cdot P'$ on the isomorphic curve.
* Return $X'/(dgZ'^2)$, which is the affine x coordinate on the isomorphic curve $X/Z'^2$ mapped back to secp256k1.
This ability to specify the X coordinate as a fraction is useful in the context of x-only [Elligator Swift](https://eprint.iacr.org/2022/759), which can decode to X coordinates on the curve without inversions this way.
ACKs for top commit:
jonasnick:
ACK 0f8642079b0f2e4874393792f5854e3c33742cbd
real-or-random:
ACK 0f8642079b0f2e4874393792f5854e3c33742cbd
Tree-SHA512: eeedb3045bfabcb4bcaf3a1738067c83a5ea9a79b150b8fd1c00dc3f68505d34c19654885a90e2292ae40ddf40a58dfb27197d98eebcf5d6d9e25897e07ae595
Adds a test using the Wycheproof vectors as outlined in #1106. The
vectors are taken from the Wycheproof repo. We use a python script
to convert the JSON-formatted vectors into C code.
Co-authored-by: Sean Andersen <6730974+andozw@users.noreply.github.com>
3d1f430f9f32d45885b0a10b448c0f15386c423d Make position of * in pointer declarations in include/ consistent (Jonas Nick)
Pull request description:
ACKs for top commit:
sipa:
utACK 3d1f430f9f32d45885b0a10b448c0f15386c423d. I have not verified these are the only instances where changes would need to be made.
apoelstra:
utACK 3d1f430 from me too. I also value consistency more than either specific choice.'
real-or-random:
utACK 3d1f430f9f
Tree-SHA512: 6361880f4a47e58c83623f094dd121882752fa805e275033cd638d1e8d3477ade9037e5d9e34a57ae46013848648bd7ab764cad326133f2d3435c9a70a0c841b
4a496a36fb07d6cc8c99e591994f4ce0c3b1174c ct: Use volatile "trick" in all fe/scalar cmov implementations (Tim Ruffing)
Pull request description:
Apparently clang 15 is able to compile our cmov code into a branch, at least for fe_cmov and fe_storage_cmov. This commit makes the condition volatile in all cmov implementations (except ge but that one only calls into the fe impls).
This is just a quick fix. We should still look into other methods, e.g., asm and #457. We should also consider not caring about constant-time in scalar_low_impl.h
We should also consider testing on very new compilers in nightly CI, see https://github.com/bitcoin-core/secp256k1/pull/864#issuecomment-769211867
ACKs for top commit:
jonasnick:
ACK 4a496a36fb07d6cc8c99e591994f4ce0c3b1174c
Tree-SHA512: a6010f9d752e45f01f88b804a9b27e77caf5ddf133ddcbc4235b94698bda41c9276bf588c93710e538250d1a96844bcec198ec5459e675f166ceaaa42da921d5
Apparently clang 15 is able to compile our cmov code into a branch,
at least for fe_cmov and fe_storage_cmov. This commit makes the
condition volatile in all cmov implementations (except ge but that
one only calls into the fe impls).
This is just a quick fix. We should still look into other methods,
e.g., asm and #457. We should also consider not caring about
constant-time in scalar_low_impl.h
We should also consider testing on very new compilers in nightly CI,
see https://github.com/bitcoin-core/secp256k1/pull/864#issuecomment-769211867
