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
There were several places where the code was non-constant time
for invalid secret inputs. These are harmless under sane use
but get in the way of automatic const-time validation.
(Nonce overflow in signing is not addressed, nor is s==0 in
signing)
Thanks to elichai2 who noted that the literal '1' is a signed integer, and that shifting a signed 32-bit integer by 31 bits causes an overflow and yields undefined behaviour.
While 'scalar_low_impl''s 'secp256k1_scalar_cadd_bit' is only used for testing purposes and currently the 'bit' parameter is only 0 or 1, it is better to avoid undefined behaviour in case the used domain of 'secp256k1_scalar_cadd_bit' expands.
Identifiers starting with an underscore and followed immediately by a capital letter are reserved by the C++ standard.
The only header guards not fixed are those in the headers auto-generated from java.
If you compile without ./configure --enable-exhaustive-tests=no,
this will create a binary ./exhaustive_tests which will execute
every function possible on a group of small order obtained by
moving to a twist of our curve and locating a generator of small
order.
Currently defaults to order 13, though by changing some #ifdefs
you can get a couple other ones. (Currently 199, which will take
forever to run, and 14, which won't work because it's composite.)
TODO exhaustive tests for the various modules
