[SECURITY] Timing leaks in lib/native/bn.js

[soatok]

• Branching timing leaks
  • https://github.com/bcoin-org/bcrypto/blob/b73dbc69884ecc790864e8ac513d627cdb0318d7/lib/native/bn.js#L3556
  • https://github.com/bcoin-org/bcrypto/blob/b73dbc69884ecc790864e8ac513d627cdb0318d7/lib/native/bn.js#L3435
• powm leaks the value of e
  • https://github.com/bcoin-org/bcrypto/blob/b73dbc69884ecc790864e8ac513d627cdb0318d7/lib/native/bn.js#L3869-L3897
  • https://github.com/bcoin-org/bcrypto/blob/b73dbc69884ecc790864e8ac513d627cdb0318d7/lib/native/bn.js#L3889-L3893
  • (This also breaks any modular inversion that relies on fermat())

I wrote a library that implements constant-time algorithms in TypeScript if you want to mitigate these risks.

Further reading: [1] [2]

[soatok]

Addendum: https://github.com/bcoin-org/bcrypto/blob/4db0feecde86bce71b0c33d31f7178fb14e7381f/lib/js/ecdsa.js#L471-L472

Leaking the exponent leaks the value of k (because Fermat uses k-2 as e), which in turn leaks k.

Leaking the hidden number lets you recover secret keys through simple algebra.

EDIT: I'm tired so I keep missing tripping up on trying to describe the problem, but the solution is to harden against timing leaks.

[chjj]

The javascript backend is not designed for side-channel silence. Bcrypto used to have some attempts at this, but realistically there is no way to ensure the code generated by a JS JIT is constant-time. It's hard enough to do in C, but (in my opinion) impossible to do in JS. There are a number of reasons for this:

1. Javascript is a dynamic enough language that the compiler may insert branches in unexpected and unseen locations (this even happens in C for code that is written as constant-time, but there are more effective mitigations for it).
2. To add insult to injury, every JS engine is a JIT nowdays: the compiler may optimize and de-optimize code at it pleases. Not only can this affect timing in unforeseen ways, but it makes the generated code harder to verify. Your code may or may not have branches before or after it's optimized... a now-you-see-it, now-you-don't type of situation.
3. Different JS engines can wildly differ in their design and execution, making it impossible to make guarantees about such execution.
4. There's a number of other factors as well (stop-the-world garbage collection, compiler bounds checks, etc).
5. Claiming JS code is side-channel resistant gives users a false impression of security for the above reasons.

To make my point further:

return x < 0n ? -x : x; 

How do you know that is a branch? Perhaps it's a branch initially, but perhaps it gets transformed into a cmov instruction once the optimizer kicks in. This function will no doubt be inlined due to its size and such an optimization could happen at various locations in the code if the compiler determines that the branch is sufficiently unpredictable.

I do not believe your code can mitigate these risks (nor can my own). Personally, I think it is irresponsible to make guarantees about javascript code being side-channel resistant. The effective only mitigation I see for JS crypto implementations is blinding factors, which bcrypto does make use of (for signing).

If you want side-channel silence, you should only use the native backend, which is constant-time for any function that handles secret data. This task is accomplished by libtorsion. See the ctgrind tests.

In the future, we can look into compiling libtorsion to WASM, though it still remains to be seen whether the executed code would actually be side-channel resistant.

edit: Fixed some links and typos.

[chjj]

Leaking the exponent leaks the value of k (because Fermat uses k-2 as e), which in turn leaks k.

It's not really relevant given my last post, but just pointing out that this is incorrect as well. It uses k as the base, not the exponent.

k.mul(b).fermat(n); 

That line would be computed as (k*b)^(n-2) mod n. In other words, the exponent is constant and non-secret.

The blinding factor is there to hopefully mask any future operations as well.