ecmult_gen: add variable-time generator point multiplication (no API behaviour changes yet) #1883

The PR is a rebased subset of #1843: it adds a variable-time variant for generator point multiplication, with the idea of enabling potential performance gains for use cases where the scalar isn't treated as secret. The implementation is essentially a copy of the existing secp256k1_ecmult_gen_gej function, but with all side-channel mitigations (i.e., constant-time code, random scalar blinding, and memory clearing) removed. The EC point operation calls (addition, doubling) are replaced with their faster variable-time equivalents.

The first commit moves the calculation of the ecmult_gen_scalar_diff constant (scalar (2^COMB_BITS - 1) / 2) from run-time to compile-time, in order to avoid needing a context object and thus enable computing the result statelessly.

On my arm64 machine, the variable-time variant is ~86% faster than the constant-time variant (with the default build table size, i.e. ECMULT_GEN_KB=86):

$ ./build/bin/bench_ecmult
Benchmark                     ,    Min(us)    ,    Avg(us)    ,    Max(us)

ecmult_gen                    ,     9.32      ,     9.35      ,     9.60
ecmult_gen_var                ,     5.02      ,     5.02      ,     5.02
.....

Note that in contrast to #1843, this PR doesn't take use of the new functions in any user-facing code (API functions) yet, to keep discussions about potential behavior changes w.r.t. constant-timing guarantees separated. The only visible change for users after merging this PR would be that the library is a tiny bit larger, as the generated tables now also contain the ecmult_gen_scalar_diff constant. On my arm64 machine, this leads to an increase of 56 bytes for the .so file (1392672 bytes master vs. 1392728 bytes PR on a default release build), which I think we can treat as negligible.

One relatively obvious scenario where using the variable-time variant would make sense is for verifying P2TR script-paths spends in Bitcoin Core via secp256k1_xonly_pubkey_tweak_add_check (see #1843 (comment)). However, whether to change the behavior of the existing API function or adding a new one (e.g. with _var suffix) still has to be decided and might be a topic for a different PR (see #1843 (comment)). Another scenario could be scanning of Silent Payments, though in this case it has to be carefully evaluated whether it's safe to treat the tweak t_k as non-secret.

This was discussed in yesterday's IRC meeting. Mild conclusion:It's reasonable to offer two variants in the public API (but I think this can still be done in a PR on top of this one to keep PRs small).

08:17 < sipa> You did convince me earlier that the situation isn't as black and white. 08:18 < sipa> What is your suggestion? Just expose both vartime and consttime variants in the API, for cases where it is ambiguous? 08:18 < sipa> I like the simplicity of it being essentially defined by the protocol/scheme/construction implemented, but maybe that's insufficient. 08:19 < real_or_random> Not sure. That would certainly not hurt. It seems wrong to push the decision to users but if we don't know the application, there's no other way (except us just picking one) 08:20 < real_or_random> sipa: I think your comment applies mostly to the tweaking functions, right? 08:20 < sipa> Yeah, that's where it got complicated. But maybe that's because tweaking is sort of a mid-level operation, not really a high-level one (like "derive BIP32 pubkey" would be or so). 08:21 < real_or_random> I'm not sure if we can have a good policy that fits all cases. If not, it may still be good to arrive at a decision for SP scanning because this is the probably the only case where performance actually matters. 08:22 < real_or_random> Indeed, yes, it's mid-level. And we can't always expose high-level functionality (though we probably could when it comes to tweaking -- but that's a lot of work). Even ECDH is mid-level, and we certainly don't want to expose LN channel establishment ^^ 08:24 < theStack> one other case where a performance gain might be noticeable is secp256k1_xonly_pubkey_tweak_add_check for checking P2TR script-path spends. iirc there was a discussion whether it's worth it to introduce two variants in one of the earlier speedup PRs 08:25 < real_or_random> For tweaking, I think we should either expose both or simply assume the worst case and make everything constant-time. Both seem reasonable. Maybe make the "normal" function safe and then have one with a more "explicit" warning name that at least makes people read the docs 08:26 < real_or_random> theStack: right, when processing the chain. That's a valid use case and performance matters. And everything is public

53ca31a76bf0e841ee2f7a2fb2b4621784a76979 needs rebase

Rebased on master (necessary due to merge conflicts caused by #1911).