Closed mratsim closed 4 years ago
Bench
Warmup: 0.9007 s, result 224 (displayed to avoid compiler optimizing warmup away)
Compiled with GCC
Optimization level => no optimization: false | release: true | danger: true
Using Milagro with 64-bit limbs
Running on Intel(R) Core(TM) i9-9980XE CPU @ 3.00GHz
⚠️ Cycles measurements are approximate and use the CPU nominal clock: Turbo-Boost and overclocking will skew them.
i.e. a 20% overclock will be about 20% off (assuming no dynamic frequency scaling)
=================================================================================================================
Scalar multiplication G1 2845.306 ops/s 351456 ns/op 1054382 cycles
Scalar multiplication G2 1006.136 ops/s 993901 ns/op 2981739 cycles
EC add G1 947867.299 ops/s 1055 ns/op 3167 cycles
EC add G2 312597.687 ops/s 3199 ns/op 9597 cycles
Pairing (Milagro builtin double pairing) 429.163 ops/s 2330118 ns/op 6990453 cycles
Pairing (Multi-Pairing with delayed Miller and Exp) 436.978 ops/s 2288443 ns/op 6865427 cycles
⚠️ Warning: using draft v5 of IETF Hash-To-Curve (HKDF-based).
This is an outdated draft.
Hash to G2 (Draft #5) 1069.780 ops/s 934772 ns/op 2804354 cycles
Old was: https://github.com/status-im/nim-blscurve/issues/47
This switches the backend from apache/amcl (which now points to https://github.com/apache/incubator-milagro-crypto-c) to miracl/core which recently changed to Apache license.
Backends and their differences are highlighted here: https://notes.status.im/nim-bls-curve-backends
In particular:
sqrt
function is constant-time as required by the IETF Hash-to-curve draftChanges:
setx
procedure used in fromHex/fromBytes serialization had to be changed to the new sqrt API. On G1 in particular, the QR procedure is preferred over the jacobi symbol to test if a field element is square so that we can benefit from the fast sqrt hint.Not done: