We found cryptography bugs in the elliptic library using Wycheproof(blog.trailofbits.com)
blog.trailofbits.com
We found cryptography bugs in the elliptic library using Wycheproof
https://blog.trailofbits.com/2025/11/18/we-found-cryptography-bugs-in-the-elliptic-library-using-wycheproof/
14 comments
It's very hard to get stuff right with the secp curves. That's one of the reasons for the move to curve25519 and similar. The book "Guide to Elliptic Curve Cryptography" by Hankerson, Menezes, and Vanstone is mostly very careful step by step instruction of how to do secp* arithmetic properly. It would still be useful to have some formal verification to help the assurance of of any particular implementation.
There are complete formulae for all prime-order Weierstrass curves. The work for secure implementation of prime-order curves is now simpler than for Edwards elliptic curves.
25519 just brings in a different set of problems though, see for example https://hdevalence.ca/blog/2020-10-04-its-25519am, and @mmsc's post above which barely scratches the surface.
FYI: two vulnerabilities in elliptic, a widely used JavaScript library for elliptic curve cryptography
The maintainer seems to have abandoned it: https://github.com/indutny/elliptic/issues
I wrote a shim library and posted it on their issue tracker: https://github.com/indutny/elliptic/issues/343
Unfortunately, adoption seems slow. I'm talking with a few people about how to move the ecosystem to something more secure like noble-curves, but it's tricky.
I wrote a shim library and posted it on their issue tracker: https://github.com/indutny/elliptic/issues/343
Unfortunately, adoption seems slow. I'm talking with a few people about how to move the ecosystem to something more secure like noble-curves, but it's tricky.
If you really feel like helping the ecosystem update, you could file issues/PRs for all of the downstream NPM modules to switch to your shim library.
Remember to tell them what the problem is and how your library solves it.
Remember to tell them what the problem is and how your library solves it.
If you click "Show more" you'll see this: https://imgur.com/a/KLI8cjL
> One vulnerability is still not fixed after a 90-day disclosure window that ended in October 2024. It remains unaddressed as of this publication.
curious why now. should they public it last year after 90-day disclosure window ended?
curious why now. should they public it last year after 90-day disclosure window ended?
They can publish it whenever they want. There's no actual rules about this stuff. The 90 window is a courtesy.
Specifically, there are responsible disclosure guidelines that came about to deal with the problem of people dropping 0day on a vendor with no prior warning. So the 90 days is a commonly-accepted amount of time to give a vendor to produce a fix. If the vendor needs more time they can request that the submitter give them an extension, although in this case it appears the vendor never responded, thus the repeated entries in the timeline saying "tried to contact vendor, no response" to show they tried to do the right thing.
No there aren't. "Responsible disclosure" is an Orwellian term invented by vendors to create the idea that publishing independent research without vendor permission is "irresponsible". It is absolutely not the case that researchers owe anybody 90 days, or are obligated to honor requests for extensions. Project Zero, which invented the 90-day-plus-extension system, does that as a courtesy.
The 90-day disclosure window is an arbitrary courtesy, not a binding contract about the behavior of either party. They probably had other things to do.
There are other vulnerabilities in that library too. I reported some (with some PRs) https://github.com/indutny/elliptic/pull/338, https://github.com/indutny/elliptic/pull/337, https://github.com/indutny/elliptic/issues/339 but I assume they'll never get fixed.
The library is dead and should be marked as vulnerable on npmjs tbh.