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
cd54ac7c1cca509404b62e626a6291f434af88e8 schnorrsig: Improve docs of schnorrsig_sign_custom (Tim Ruffing)
28687b03128fbdd23a3f901297f523dfae2f82e3 schnorrsig: Add BIP340 varlen test vectors (Tim Ruffing)
97a98bed1ed479b1a23d8ae788020d8a6e081cf0 schnorrsig: Refactor test vector code to allow varlen messages (Tim Ruffing)
Pull request description:
ACKs for top commit:
sipa:
ACK cd54ac7c1cca509404b62e626a6291f434af88e8. I didn't verify the included test vectors match the BIP.
jonasnick:
ACK cd54ac7c1cca509404b62e626a6291f434af88e8
Tree-SHA512: 268140e239b703aaf79825de2263675a8c31bef999f013ea532b0cd7b80f2d600d78f3872209a93774ba4dbc0a046108e87d151fc4604882c5636876026a0816
17fa21733aae97bf671fede3ce528c7a3b2f5f14 ct: Be cautious and use volatile trick in more "conditional" paths (Tim Ruffing)
5fb336f9ce7d287015ada5d1d6be35d63469c9a4 ct: Use volatile trick in scalar_cond_negate (Tim Ruffing)
Pull request description:
ACKs for top commit:
sipa:
ACK 17fa21733aae97bf671fede3ce528c7a3b2f5f14
jonasnick:
ACK 17fa21733aae97bf671fede3ce528c7a3b2f5f14
Tree-SHA512: 4a0fbee7b1cce4f4647bff697c0e645d93aa8fb49777feef5eb1e1eadce2116bafdcc6175c066ee4fe4bf1340047311e2d7d2c48bb288867a837ecd6c8687121
712e7f8722eba5dec2bc6b37d75aadeb6f6e633b Remove unused scratch space from API (Jonas Nick)
Pull request description:
Not sure if we want the typedef and `secp256k1_scratch_space_{create,destroy}` but if we don't keep them then this PR will be a rather large diff.
ACKs for top commit:
sipa:
ACK 712e7f8722eba5dec2bc6b37d75aadeb6f6e633b
real-or-random:
utACK 712e7f8722eba5dec2bc6b37d75aadeb6f6e633b
Tree-SHA512: b3a8feb0fe4639d5e48b708ccbf355bca5da658a291f63899086d2bbeb6d0ab33e3dcd55d8984ec7fa803f757b7d02e71bcb7e7eeecaab52ffc70ae85dce8c44
- 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).
97c63b90390b0b11a5d3530b03855ec9cc0de343 Avoid normalize conditional on VERIFY (Pieter Wuille)
Pull request description:
In the old code, `secp256k1_gej_rescale` requires a normalized input in VERIFY mode, but not otherwise. Its requirements shouldn't depend on this mode being enabled or not.
ACKs for top commit:
real-or-random:
utACK 97c63b90390b0b11a5d3530b03855ec9cc0de343 I've also verified that the loop in secp256k1_ecmult_strauss_wnaf holds up the invariant that the magnitude of Z is 1, even with the normalization removed
jonasnick:
ACK 97c63b90390b0b11a5d3530b03855ec9cc0de343
Tree-SHA512: 9598c133c6f4e488c74512089dabe0508529f20ca782be1c8fbeae9d7f132da9d570a061053acd3d245a9a187abf1f2581207441ce6aac8d0f8972cf357a349f
