Switch to more secure & faster secp256k1 library, shave-off 90kb
paulmillr opened this issue · comments
Hi! I've created noble-secp256k1 one year ago. The goal was to create an extremely simple zero-dependency library. With all the optimizations, even though it's just <1kloc, it's actually faster than elliptic — which you're using right now:
noble#sign x 3,952 ops/sec
elliptic#sign x 1,808 ops/sec
noble#verify x 851 ops/sec
elliptic#verify x 812 ops/sec
The reasoning behind the creation was that more and more dependencies are used in all kinds of projects, and there is a huge need in reducing the number — because any dep could get hacked, and it becomes complex to verify the source code by hand. Check out the blog post: https://paulmillr.com/posts/noble-secp256k1-fast-ecc/
- noble secp is 10kb minified, while your current elliptic + bn.js is ~100kb, you'll save 90kb — which is a lot
- noble was audited by Cure53. Elliptic was not audited, so noble should be considered more secure
- elliptic does not seem to be maintained. Elliptic recently had terrible private key leak (CVE-2020-28498)
- you'll receive faster signatures and verification
I strongly recommend switching to noble. I can prepare a pull request.
Hello guys! Thank you for your amazing work.
@alcuadrado could you please elaborate on this issue?
I was looking into this library and the fact that the issue described by the @paulmillr is not addressed makes me worry.
Sorry for the super late answer.
Unfortunately, we can't migrate this project to native bigints yet, as one of its goals is to support other, mostly legacy, libraries.
We can evaluate if a new major version using it would make sense. Me, personally, would love to see that, and I'm a fan of @paulmillr's work here, but we need to make sure if consumers of this project are interested in it.
How can consumers of the project be not interested in improving the security by reducing deps & using audited library? 🤭
What needs to be done to evaluate this?
What needs to be done to evaluate this?
Asking a the maintainers of the major packages listed here: https://www.npmjs.com/browse/depended/ethereum-cryptography
If we release a new major, and they don't adopt it, it wouldn't make much of an impact in the ecosystem.
@alcuadrado that seems like a backwards direction. Why ask anyone?
- Bigints are supported in all major browsers
- Node.js versions without bigints are officially unmaintained
- Those who want to support legacy clients will use older lib, others won't
- Browsers without native bigints won't likely interact with eth. E.g there won't be metamask
Again, this is important for security and readability.
I've did a backwards-incompatible change for a much more used package (chokidar). I never asked users whether they want to upgrade or not.
I guess it depends on the cost of the change. Originally we had to be pretty conservative on that front here, as the cost of auditing this package and sending prs to all the projects that could benefit from it was really high, but that's probably not the case anymore. Now this library is more established, so improving it without buy-in is not as risky as creating it without it would have been.
I've always wanted to make a v2 without BN.js, Buffer, nor any other node.js specific dependency. This could be a good start. Also, would you be interested in working on this project? I know you have other noble-* libraries.
Of course. This is awesome project
Hi there, totally not that much of an in-depth cryptography expert, but just wanted to drop here: this article states that BigInt wouldn't be suitable for crytography needs because operations are not constant times which would provide a substantial security risk.
Is this obsolete or not relevant for whatever reasons or was this alternatively considered when creating the noble-* libraries?
@holgerd77 I have described this issue in-depth in README: https://github.com/paulmillr/noble-secp256k1/blob/master/README.md#security
Any JS code is unsuitable for cryptography, especially bn.js etc.
@paulmillr ah, thanks for pointing out, that's a much more differentiated take on that, makes sense. Appreciate that!