elliptic

elliptic is a pure JavaScript implementation of elliptic curve cryptography, providing ECDSA signing and verification, EdDSA (Ed25519) signatures, and ECDH key exchange without any native bindings. It ships preset support for widely used curves including secp256k1 (the curve behind Bitcoin and Ethereum), the NIST P-192/P-224/P-256/P-384/P-521 family, Curve25519, and Ed25519, spanning Short Weierstrass, Montgomery, Edwards, and Twisted Edwards curve forms.

Because it has no native dependencies, elliptic runs identically in Node.js and in the browser, which is why it became a foundational building block for the JavaScript cryptocurrency and Web3 ecosystem — used directly or transitively by wallet libraries, signing SDKs, and blockchain clients that need deterministic ECDSA (RFC 6979) or Ed25519 signatures in a browser-safe package.

What You Get

• An EC context for ECDSA signing, verification, key generation, and public-key recovery over any preset or custom curve
• Deterministic ECDSA nonces per RFC 6979 via the bundled hmac-drbg dependency, removing the class of bugs caused by reused or weak nonces
• An EdDSA context for Ed25519 signing and verification
• ECDH key exchange (key.derive()) usable with two or more parties on Montgomery curves such as curve25519
• Eight preset curves out of the box: secp256k1, p192, p224, p256, p384, p521, curve25519, and ed25519
• A pluggable point/curve architecture (curve/base.js, curve/short.js, curve/mont.js, curve/edwards.js) for adding custom curves

Common Use Cases

• Signing and verifying Bitcoin, Ethereum, or other secp256k1-based blockchain transactions in JavaScript
• Implementing Ed25519 signatures for SSH keys, Signal-style protocols, or other Ed25519-based auth schemes
• Deriving shared secrets via ECDH for end-to-end encrypted messaging or key-agreement protocols
• Building wallet SDKs and browser extensions that need curve cryptography without native/WASM dependencies

Under The Hood

Architecture: elliptic splits along two protocol namespaces — lib/elliptic/ec/index.js for ECDSA/ECDH and lib/elliptic/eddsa/index.js for EdDSA — both sitting on top of a shared curve abstraction in lib/elliptic/curve/ (base.js defines the common point interface; short.js, mont.js, and edwards.js implement Short Weierstrass, Montgomery, and (Twisted) Edwards curve math respectively, with short.js at 938 lines carrying the bulk of the windowed-NAF and Jacobian-coordinate multiplication logic). curves.js wires up the eight preset curves (secp256k1, the NIST P-family, curve25519, ed25519) as PresetCurve instances, and precomputed/secp256k1.js ships a large precomputed point table specifically to speed up secp256k1 base-point multiplication, the curve used for Bitcoin/Ethereum signing. Both EC.sign/EC.verify and EDDSA.sign/EDDSA.verify funnel through this shared curve layer, so the same point-multiplication code path serves all three protocols.

Tech Stack: the library is dependency-light and deliberately native-free — bn.js (arbitrary-precision integers), hash.js (pure-JS hash implementations), hmac-drbg (deterministic RFC 6979 nonce generation), brorand (randomness), inherits, and two minimalistic-* helpers for assertions and hex/array conversion. There is no build step for consumption (main points straight at lib/elliptic.js); a dist/ bundle and Grunt/Browserify pipeline exist only for the browser test harness, not for the published npm package’s runtime code.

Code Quality: the test/ directory covers the public surface with mocha specs across api-test.js, curve-test.js, ecdh-test.js, ecdsa-test.js, and ed25519-test.js, run via istanbul for coverage and gated behind ESLint (eslint:recommended plus a 2-space/single-quote style config) in the npm test script. Code is written in pre-ES6 CommonJS style (var, prototype-based classes, no TypeScript types), which keeps the dependency surface minimal but means there is no static type checking — correctness for the crypto-critical paths (nonce generation, point validation, signature malleability handling via the canonical option) relies on the test fixtures rather than the type system. The project has been effectively unmaintained since its last commit in November 2024, so any newly discovered issues go unpatched.

API Design: the public API is small and pragmatic — new EC('secp256k1'), ec.genKeyPair(), key.sign(msgHash), key.verify(msgHash, sig) for ECDSA, and the mirrored EdDSA('ed25519') shape for EdDSA — with flexible input coercion (hex strings, byte arrays, or BN instances accepted interchangeably for messages and keys). This flexibility is also the API’s main rough edge: several input shapes are accepted for the same parameter (e.g. a public key can be a hex string, an {x, y} object, or a Buffer-backed object), which keeps call sites terse for common cases but pushes correctness questions about which encoding was actually used onto the caller. Documentation is limited to the README’s runnable code samples for ECDSA/EdDSA/ECDH — there is no generated API reference, so understanding edge-case behavior (e.g. recovery-param semantics, canonical-signature normalization) requires reading source.