We found cryptography bugs in the elliptic library using Wycheproof
106 points
7 days ago
| 4 comments
| blog.trailofbits.com
| HN
mmsc
20 hours ago
[-]
(2024).

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.

reply
throwaway81523
21 hours ago
[-]
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.
reply
pseudohadamard
19 hours ago
[-]
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.
reply
Ar-Curunir
11 hours ago
[-]
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.
reply
binkHN
1 day ago
[-]
FYI: two vulnerabilities in elliptic, a widely used JavaScript library for elliptic curve cryptography
reply
some_furry
1 day ago
[-]
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.

reply
thephyber
1 day ago
[-]
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.

reply
some_furry
1 day ago
[-]
If you click "Show more" you'll see this: https://imgur.com/a/KLI8cjL
reply
tuananh
1 day ago
[-]
> 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?

reply
tptacek
1 day ago
[-]
They can publish it whenever they want. There's no actual rules about this stuff. The 90 window is a courtesy.
reply
pseudohadamard
19 hours ago
[-]
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.
reply
tptacek
10 hours ago
[-]
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.
reply
dadrian
8 hours ago
[-]
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.
reply