Remove all dependencies

[paulmillr]

Every dependency is a potential security vulnerability. Consider three cases:

• Reputable developer giving project rights to a rogue developer in a good faith (happened before). https://medium.com/intrinsic/compromised-npm-package-event-stream-d47d08605502
• Reputable developer getting hacked and having a bad package published.
• Rogue developer creating new project, waiting for it to become popular and pushing a bad version after that (happened before). https://blog.npmjs.org/post/185397814280/plot-to-steal-cryptocurrency-foiled-by-the-npm

I think it's very bad for such an important library to rely on tons of dependencies. Auditing bn.js, for example, is terrible.

I suggest:

• Bumping elliptic to v7 to identify breaking change
• Bumping minimum node.js requirement to v10 because v10 supports bigints
• Replacing bn.js with native bigints
• Integrating all other dependencies. Maybe make an exception for hash.js etc, keeping a few up.

I can open a pull request if you want to improve security.

[indutny]

Thank you for feedback. I'm not sure if there are any plans of active development of this library at the moment.

I wouldn't mind if someone would fork and experiment with elliptic. Surely it would be interesting to see it ported from bn.js to BigInts and to compare the resulting performance!

Since it is unlikely that maintainers of this library will partake in such activity - I'm closing this issue.

[paulmillr]

@indutny are you open to adding any new maintainers to elliptic, instead of deprecating it? I maintain a node library which is twice as popular as elliptic in terms of yearly downloads and I am willing to improve cryptography ecosystem in node.

In particular, I already maintain stuff like bls12-381, ed25519 & secp256k1.

[paulmillr]

@indutny ping?

[indutny]

@paulmillr I don't mind adding new maintainer(s) to elliptic. The plan that you suggested does not align with the vision of the project that I had initially. As you pointed out, the landscape of JavaScript has changed significantly in recent years (addition of BigInts and other features) and this library haven't been revised to adapt some of these technologies. However, I don't think that moving this library away from bn.js and/or other dependencies (except forinherits which is indeed is no longer necessary) is the course that maintainers should take.

As glorious as BigInts are - one would have to reimplement good part of bn.js in order to not compromise the performance of elliptic. Just for the starters BigInt does not have efficient modular division for primes like secp256k1 or ed25519 have. There are way more cases that would show up in the benchmarks and might not be trivial to fix.

[paulmillr]

Performance is very important. We must not compromise on it. I totally agree with you!

I will try to test those and report back.

[paulmillr]

@indutny i've benchmarked my noble-secp256k1. The results tell for themselves.

noble#sign x 2,620 ops/sec
elliptic#sign x 1,326 ops/sec
sjcl#sign x 185 ops/sec
openssl#sign x 1,926 ops/sec
ecdsa#sign x 69.32 ops/sec

noble#verify x 558 ops/sec
elliptic#verify x 575 ops/sec
sjcl#verify x 155 ops/sec
openssl#verify x 2,392 ops/sec
ecdsa#verify x 45.64 ops/sec

noble#gen x 4,017 ops/sec
elliptic#gen x 1,434 ops/sec
sjcl#gen x 194 ops/sec

noble#ecdh x 435 ops/sec
elliptic#ecdh x 704 ops/sec

[paulmillr]

@indutny ping? All major browsers support bigint today.