security consideration with timing attacks on bn.js use

[pravi]

As reported here https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861639#10

As with the other pure JS crypto package ITP here recently [1]: has
this library been designed with timing attacks in mind? In contrast
to the first example, where upstream says that it's so slow that
nobody is probably going to use it in real life anyway [2], this
library claims to be quite fast - in which case the chance of the
library being used in actual real-life applications is higher. And
it uses the same bignum library that the other package is also
using, which doesn't appear to have been designed with timing
considerations in mind. (Which is fine for a bignum library not
intended for crypto purposes.)

As with the previous package, the README of the project and the
other documentation does not discuss timing attacks at all, which
doesn't give me confidence that the author of the library has
thought about these issues.

A couple of pointers:

• For curves that are not Edwards curves there is a very trivial
  timing attack, which is really hard to mitigate, where it is
  trivially possible to extract the private key through a side
  channel near-instantaneously.

  The library supports all sorts of types of curves, and while I
  haven't tested it, I'd be extremely surprised if it wasn't
  susceptible to this type of attack for non-Edwards curves.

• For curves that are Edwards curves, the trivial timing attacks
  described above are mitigated. However, I don't have any
  confidence (especially since this is pure Javascript, where
  I imagine mitigating this to be extremely difficult) that the
  code doesn't contain any other side channels. Again, I didn't
  test that, but there is no documentation even mentioning side
  channels, and no comment in the code either. (If you grep
  through e.g. OpenSSL's source code, you'll see lots of
  comments discussing side channels and timing attacks. And even
  OpenSSL has advisories on side channel attacks every now and
  then, because someone comes up with something very clever that
  they didn't think of. [3])

I understand you're probably packaging this because it's a
dependency of something else, but I'm seriously concerned about
any package that uses this library for real-world applications
other than generating key pairs.

Regards,
Christian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860771#10
[2] browserify/diffie-hellman#22 (comment)
[3] Look at CVE-2013-4576 to see how creative these side channel
attacks can become.

This is similar to browserify/diffie-hellman#22

[indutny]

Thanks for opening this. I'm always trying to keep security in mind, but it doesn't look like there is a way to mitigate timing attacks in this library without sacrificing the performance. JS implementation is about 10x-20x times slower than C already, and I don't want to make it even slower than this.