5b7bf2e9d4ee02cbec1105ad6e890c34a4da1beb Use `__shiftright128` intrinsic in `secp256k1_u128_rshift` on MSVC (Hennadii Stepanov)
Pull request description:
Closes https://github.com/bitcoin-core/secp256k1/issues/1324.
As the `__shiftright128` [docs](https://learn.microsoft.com/en-us/cpp/intrinsics/shiftright128) state:
> The `Shift` value is always modulo 64...
it is not applicable for the `n >= 64` branch.
ACKs for top commit:
sipa:
utACK 5b7bf2e9d4ee02cbec1105ad6e890c34a4da1beb
real-or-random:
ACK 5b7bf2e9d4ee02cbec1105ad6e890c34a4da1beb tested with MSVC x64
Tree-SHA512: bc4c245a9da83c783a0479e751a4bc2ec77a34b99189fcc4431033a5420c93b610f3b960d3f23c15bce2eb010beba665b3e84d468b3fdab3d5846d4f27016898
e449af6872445d33a0796224fcb733be6476ad36 Drop no longer needed `#include "../include/secp256k1.h"` (Hennadii Stepanov)
Pull request description:
The removed header includes have not been needed since https://github.com/bitcoin-core/secp256k1/pull/1231.
Test suggestions:
1. Using Autottols-based build system:
```
./autogen.sh
./configure
make clean-precomp
make
```
2. Using CMake-based build system:
```
cmake -B build -DCMAKE_C_INCLUDE_WHAT_YOU_USE="include-what-you-use"
cmake --build build --target secp256k1_precomputed
```
ACKs for top commit:
sipa:
utACK e449af6872445d33a0796224fcb733be6476ad36
real-or-random:
utACK e449af6872445d33a0796224fcb733be6476ad36
Tree-SHA512: 5aed7a88e1e03fcc2306c43817712c0652ecf6145679dd17f4719376818d372f619e4180bdaee548f2e82aaccbe6a2ff4c37203121d939af545128c8c48b933e
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.
f1652528be5a287a3c33a4fae1e5763693333c2b Normalize ge produced from secp256k1_pubkey_load (stratospher)
Pull request description:
The output `ge` in secp256k1_pubkey_load is normalized when `sizeof(secp256k1_ge_storage) = 64` but not when it's not 64. ARG_CHECK at the end of the function assumes normalization. So normalize ge in the other code path too.
context: [#1129(comment)](https://github.com/bitcoin-core/secp256k1/pull/1129/files#r1196167066)
ACKs for top commit:
sipa:
utACK f1652528be5a287a3c33a4fae1e5763693333c2b
real-or-random:
ACK f1652528be5a287a3c33a4fae1e5763693333c2b tested by changing the two `== 64` checks to `== 65`
Tree-SHA512: 0de1caad85ccdb42053f8e09576135257c88fda88455ef25e7640049c05a1e03d1e9bae1cd132d2e6fc327fd79929257a8b21fe1cc41c82374b6cd88e6744aa3
The output ge is normalized when sizeof(secp256k1_ge_storage) = 64
but not when it's not 64. ARG_CHECK at the end of the function
assumes normalization. So normalize ge in the other code path too.
ade5b367018a624ff7ca1ecbb4a64889d47b0142 tests: add checks for scalar constants `secp256k1_scalar_{zero,one}` (Sebastian Falbesoner)
654246c63585422a184121a26d42dcae792e87c6 refactor: take use of `secp256k1_scalar_{zero,one}` constants (Sebastian Falbesoner)
Pull request description:
Rather than allocating a (non-constant) scalar variable on the stack with the sole purpose of setting it to a constant value, the global constants `secp256k1_scalar_{zero,one}` (apparently introduced in 34a67c773b0871e5797c7ab506d004e80911f120, PR #710) can be directly used instead for the values 0 or 1. There is very likely not even a difference in run-time, but it leads to simpler and less code which might be nice.
ACKs for top commit:
sipa:
utACK ade5b367018a624ff7ca1ecbb4a64889d47b0142
real-or-random:
utACK ade5b367018a624ff7ca1ecbb4a64889d47b0142
Tree-SHA512: 0ff05a449c153f7117a4a56efef04b2087c2330f4692f3390a0b1d95573785ac7ae3fe689ed0ec2ecc64b575d2489d6e341d32567e75a1a4b4d458c3ecd406a1
In the field 5x52 asm for x86_64, stack variables are provided as outputs.
The existing inputs are all forcibly allocated to registers, so cannot
coincide, but mark them as early clobber anyway to make this clearer.
In the existing code, the compiler is allowed to allocate the RSI register
for outputs m0, m1, or m2, which are written to before the input in RSI is
read from. Fix this by marking them as early clobber.
Reported by ehoffman2 in https://github.com/bitcoin-core/secp256k1/issues/766
- secp256k1_scalar_cadd_bit
- secp256k1_modinvXX_normalize_YY
- secp256k1_modinvXX_divsteps_ZZ
- ECMULT_CONST_TABLE_GET_GE
Even though those code loations are not problematic right now
(with current compilers).
8c9ae37a5a26cdeb6365624fee43f41b238830e4 Add release note (Pieter Wuille)
350b4bd6e6efd3c62875820fdeb2740738937922 Mark stack variables as early clobber for technical correctness (Pieter Wuille)
0c729ba70d963f2798184b0b8524d7de2f3ced9f Bugfix: mark outputs as early clobber in scalar x86_64 asm (Pieter Wuille)
Pull request description:
ACKs for top commit:
real-or-random:
ACK 8c9ae37a5a26cdeb6365624fee43f41b238830e4
jonasnick:
ACK 8c9ae37a5a26cdeb6365624fee43f41b238830e4
Tree-SHA512: 874d01f5540d14b5188aec25f6441dbc6631f8d3980416040a3e250f1aef75150068415e7a458a9a3fb0d7cbdeb97f5c7e089b187d6d3dd79aa6e45274c241b6
c6bb29b3037c6b5264f2d2916c5a2d38de25df19 build: Rename `64bit` to `x86_64` (Hennadii Stepanov)
03246457a8f7091e13af13a50d7ae33cf42e08b5 autotools: Add `SECP_ARM32_ASM_CHECK` macro (Hennadii Stepanov)
ed4ba238e2cb2f24301c1add238cf7ff062286c3 cmake: Add `check_arm32_assembly` function (Hennadii Stepanov)
e5cf4bf3ff9aac5b5897a8a9852cfbb84da0bfb1 build: Rename `arm` to `arm32` (Hennadii Stepanov)
Pull request description:
Closes https://github.com/bitcoin-core/secp256k1/issues/1034.
Solves one item in https://github.com/bitcoin-core/secp256k1/issues/1235.
ACKs for top commit:
real-or-random:
ACK c6bb29b3037c6b5264f2d2916c5a2d38de25df19 tested on x86_64 but not on ARM
Tree-SHA512: c3615a18cfa30bb2cc53be18c09ccab08fc800b84444d8c6b333347b4db039a3981da61e7da5086dd9f4472838d7c031d554be9ddc7c435ba906852bba593982
In the field 5x52 asm for x86_64, stack variables are provided as outputs.
The existing inputs are all forcibly allocated to registers, so cannot
coincide, but mark them as early clobber anyway to make this clearer.
In the existing code, the compiler is allowed to allocate the RSI register
for outputs m0, m1, or m2, which are written to before the input in RSI is
read from. Fix this by marking them as early clobber.
Reported by ehoffman2 in https://github.com/bitcoin-core/secp256k1/issues/766
