perf: skip some intermediate % in Weierstrass add

[ChALkeR]

In field arithmetics, every operation comes with a division step (%)
Removing it for intermediate steps can speed up things

This gives a ~10% perf improvement on my machine according to benchmark/secp256k1.js

Warning

Draft because not sure if this could be abused in timing attacks? Don't see how though?

Here, I touched only addition/subtraction, but perf-wise this can be even skipped on some multiplications for more speed improvements -- but I'm even less sure on how safe that is re: timing

secp256k1

Before:

Benchmarking
secp256k1
init x 74 ops/sec @ 13ms/op
getPublicKey x 7,092 ops/sec @ 140μs/op
sign x 5,683 ops/sec @ 175μs/op
verify x 975 ops/sec @ 1ms/op ± 1.54% (min: 978μs, max: 5ms)
getSharedSecret x 600 ops/sec @ 1ms/op
recoverPublicKey x 1,001 ops/sec @ 998μs/op
schnorr.sign x 767 ops/sec @ 1ms/op
schnorr.verify x 963 ops/sec @ 1ms/op

After:

Benchmarking
secp256k1
init x 78 ops/sec @ 12ms/op
getPublicKey x 7,868 ops/sec @ 127μs/op
sign x 6,162 ops/sec @ 162μs/op
verify x 1,089 ops/sec @ 918μs/op
getSharedSecret x 664 ops/sec @ 1ms/op
recoverPublicKey x 1,112 ops/sec @ 899μs/op
schnorr.sign x 855 ops/sec @ 1ms/op
schnorr.verify x 1,091 ops/sec @ 916μs/op

bls12-381

Before:

Benchmarking
bls12-381
init x 39 ops/sec @ 25ms/op
getPublicKey 1-bit x 1,123 ops/sec @ 889μs/op
getPublicKey x 1,126 ops/sec @ 888μs/op
sign x 67 ops/sec @ 14ms/op
verify x 53 ops/sec @ 18ms/op
pairing x 143 ops/sec @ 6ms/op
pairing10 x 47 ops/sec @ 21ms/op ± 23.99% (min: 18ms, max: 42ms)
MSM 4096 scalars x points x 0 ops/sec @ 3963ms/op
aggregatePublicKeys/8 x 141 ops/sec @ 7ms/op ± 5.31% (min: 6ms, max: 24ms)
aggregatePublicKeys/32 x 39 ops/sec @ 25ms/op
aggregatePublicKeys/128 x 10 ops/sec @ 99ms/op
aggregatePublicKeys/512 x 2 ops/sec @ 392ms/op
aggregatePublicKeys/2048 x 0 ops/sec @ 1565ms/op
aggregateSignatures/8 x 65 ops/sec @ 15ms/op ± 10.11% (min: 13ms, max: 74ms)
aggregateSignatures/32 x 18 ops/sec @ 53ms/op
aggregateSignatures/128 x 4 ops/sec @ 206ms/op
aggregateSignatures/512 x 1 ops/sec @ 823ms/op
aggregateSignatures/2048 x 0 ops/sec @ 3318ms/op

After:

Benchmarking
bls12-381
init x 39 ops/sec @ 25ms/op
getPublicKey 1-bit x 1,243 ops/sec @ 804μs/op
getPublicKey x 1,240 ops/sec @ 806μs/op
sign x 67 ops/sec @ 14ms/op
verify x 53 ops/sec @ 18ms/op
pairing x 144 ops/sec @ 6ms/op
pairing10 x 46 ops/sec @ 21ms/op ± 22.77% (min: 18ms, max: 41ms)
MSM 4096 scalars x points x 0 ops/sec @ 3524ms/op
aggregatePublicKeys/8 x 160 ops/sec @ 6ms/op
aggregatePublicKeys/32 x 42 ops/sec @ 23ms/op
aggregatePublicKeys/128 x 10 ops/sec @ 90ms/op
aggregatePublicKeys/512 x 2 ops/sec @ 362ms/op
aggregatePublicKeys/2048 x 0 ops/sec @ 1467ms/op ± 2.44% (min: 1440ms, max: 1526ms)
aggregateSignatures/8 x 71 ops/sec @ 13ms/op
aggregateSignatures/32 x 18 ops/sec @ 52ms/op
aggregateSignatures/128 x 4 ops/sec @ 206ms/op
aggregateSignatures/512 x 1 ops/sec @ 822ms/op
aggregateSignatures/2048 x 0 ops/sec @ 3293ms/op

[paulmillr]

Unfortunately that degrades timing resistance by a quite bit. We can't merge it.

[ChALkeR]

Oh, thanks!
Do you have a script to test that, by any chance?

[paulmillr]

Not final, I want to release it as a general-purpose testing tool soon.