indutny
commented
7 years ago 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.
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] https://github.com/crypto-browserify/diffie-hellman/issues/22#issuecomment-296645560 [3] Look at CVE-2013-4576 to see how creative these side channel attacks can become.
This is similar to https://github.com/crypto-browserify/diffie-hellman/issues/22