Security issue: Library is vulnerable to timing attacks

[paulmillr]

sjcl elliptic curve public key calculation time depends on private key bits, effectively leaking all the timings:

sjcl private key A x 7,624 ops/sec @ 131μs/op
sjcl private key B x 117 ops/sec @ 8ms/op
sjcl private key C x 56 ops/sec @ 17ms/op

Reproducible with this code:

// mkdir a && cd a && npm init -y && npm install micro-bmark sjcl-including-ecc
const bmark = require('micro-bmark');
const sjcl = require('sjcl-including-ecc');
const curve = sjcl.ecc.curves.k256;
const privA = '1000000000000000000000000000000000000000000000000000000000000000';
const privB = '0000000000000000000000000000010000000000000000000000000000000000';
const privC = '0000000000000000000000000000000000000000000000000000000000000001';
bmark.run(async () => {
  console.log(curve.G.mult(privA).isIdentity);
  await bmark.mark('sjcl private key A', 110, () => curve.G.mult(privA));
  await bmark.mark('sjcl private key B', 110, () => curve.G.mult(privB));
  await bmark.mark('sjcl private key C', 110, () => curve.G.mult(privC));
})

[bleichenbacher-daniel]

Maybe worth clarifying. The timing differences mentioned here are big enough, so that the private keys can be recovered from ECDSA signature measurements using for example the method described in the paper by Howgrave-Graham and Smart : "Lattice attacks on digital signature schemes", Designs, Codes and Cryptography 23 (3), p.283–290 (2001).