paulmillr/noble-curves
paulmillr/noble-curves — a security tool — sits at 935 GitHub stars in the Security space. Audited & minimal JS implementation of elliptic curve cryptography.
Snapshot summary built from the project's own GitHub metadata — there's no written TopGit review yet. The page will update automatically when a full review is published.
TopGit writes full reviews for the most-starred, most-requested repositories. This page is a snapshot until then — see the READ ME tab for the original README in full.
Snapshot
Top contributors
Show top contributors
noble-curves
Audited & minimal JS implementation of elliptic curve cryptography.
- 🔒 Audited by independent security firms
- 🪶 Minimal: 15KB (gzipped) secp256k1, unused code is excluded from your builds
- 🏎 Fast: hand-optimized for caveats of JS engines
- 🔍 Reliable: cross-library / wycheproof tests ensure correctness
- ➰ Weierstrass, Edwards curves; ECDSA, EdDSA, Schnorr, BLS signatures
- ✍️ ECDH, hash-to-curve, OPRF, FROST, Poseidon hash, FFT
- 🔖 Non-repudiation (SUF-CMA, SBS) & consensus-friendliness (ZIP215) in ed25519, ed448
- 🥈 Wrapper with identical API over native WebCrypto
Curves have 5kb sister projects secp256k1 & ed25519. They have smaller attack surface, but less features.
This library belongs to noble cryptography
noble cryptography — high-security, easily auditable set of contained cryptographic libraries and tools.
- Zero or minimal dependencies
- Highly readable TypeScript / JS code
- PGP-signed releases and transparent NPM builds
- All libraries: ciphers, curves, hashes, post-quantum, 5kb secp256k1 / ed25519
- WASM version: awasm-noble
- Check out the homepage for reading resources, documentation, and apps built with noble
Usage
npm install @noble/curves
deno add jsr:@noble/curves
We support all major platforms and runtimes. For React Native, you may need a polyfill for getRandomValues. A standalone file noble-curves.js is also available.
// import * from '@noble/curves'; // Error: use sub-imports, to ensure small app size
import { secp256k1, schnorr } from '@noble/curves/secp256k1.js';
import { ed25519, ed25519ph, ed25519ctx, x25519, ristretto255 } from '@noble/curves/ed25519.js';
import { ed448, ed448ph, x448, decaf448 } from '@noble/curves/ed448.js';
import { p256, p384, p521 } from '@noble/curves/nist.js';
import { bls12_381 } from '@noble/curves/bls12-381.js';
import { bn254 } from '@noble/curves/bn254.js';
import { jubjub, babyjubjub, brainpoolP256r1, brainpoolP384r1, brainpoolP512r1 } from '@noble/curves/misc.js';
// hash-to-curve
import { secp256k1_hasher } from '@noble/curves/secp256k1.js';
import { p256_hasher, p384_hasher, p521_hasher } from '@noble/curves/nist.js';
import { ristretto255_hasher } from '@noble/curves/ed25519.js';
import { decaf448_hasher } from '@noble/curves/ed448.js';
// OPRFs
import { p256_oprf, p384_oprf, p521_oprf } from '@noble/curves/nist.js';
import { ristretto255_oprf } from '@noble/curves/ed25519.js';
import { decaf448_oprf } from '@noble/curves/ed448.js';
// utils
import { bytesToHex, hexToBytes, concatBytes } from '@noble/curves/utils.js';
import { Field } from '@noble/curves/abstract/modular.js';
import { weierstrass, ecdsa } from '@noble/curves/abstract/weierstrass.js';
import { edwards, eddsa } from '@noble/curves/abstract/edwards.js';
import { poseidon, poseidonSponge } from '@noble/curves/abstract/poseidon.js';
import { FFT, poly } from '@noble/curves/abstract/fft.js';
- Examples
- ECDSA, EdDSA, Schnorr signatures
- secp256k1, p256, p384, p521, ed25519, ed448, brainpool
- ristretto255, decaf448
- Prehashed signing
- Recovering public keys from signatures
- Hedged ECDSA with noise
- Consensus-friendliness vs e-voting
- ECDH: Diffie-Hellman shared secrets
- webcrypto: Friendly wrapper
- BLS signatures, bls12-381, bn254 aka alt_bn128
- Hashing to curve points
- OPRFs
- FROST threshold signatures
- Poseidon hash
- Fast Fourier Transform
- utils
- ECDSA, EdDSA, Schnorr signatures
- Internals
- Elliptic curve Point math
- modular: Modular arithmetics & finite fields
- weierstrass: Custom Weierstrass curve
- edwards: Custom Edwards curve
- Custom ECDSA instance
- Security
- Speed
- Upgrading
ECDSA, EdDSA, Schnorr signatures
secp256k1, p256, p384, p521, ed25519, ed448, brainpool
import { secp256k1, schnorr } from '@noble/curves/secp256k1.js';
import { p256, p384, p521 } from '@noble/curves/nist.js';
import { ed25519 } from '@noble/curves/ed25519.js';
import { ed448 } from '@noble/curves/ed448.js';
import { brainpoolP256r1, brainpoolP384r1, brainpoolP512r1 } from '@noble/curves/misc.js';
for (const curve of [
secp256k1, schnorr,
p256, p384, p521,
ed25519, ed448,
brainpoolP256r1, brainpoolP384r1, brainpoolP512r1
]) {
const { secretKey, publicKey } = curve.keygen();
const msg = new TextEncoder().encode('hello noble');
const sig = curve.sign(msg, secretKey);
const isValid = curve.verify(sig, msg, publicKey);
console.log(curve, secretKey, publicKey, sig, isValid);
}
// Specific private key
import { hexToBytes } from '@noble/curves/utils.js';
const secret2 = hexToBytes('46c930bc7bb4db7f55da20798697421b98c4175a52c630294d75a84b9c126236');
const pub2 = secp256k1.getPublicKey(secret2);
Messages are always hashed first. Hashing can be disabled using prehash: false.
ECDSA signatures use deterministic k, conforming to RFC 6979. EdDSA conforms to RFC 8032. Schnorr (secp256k1-only) conforms to BIP 340.
MuSig2 signature scheme and BIP324 ElligatorSwift mapping for secp256k1 are available in a separate package.
ristretto255, decaf448
import { ristretto255, ristretto255_hasher, ristretto255_oprf } from '@noble/curves/ed25519.js';
import { decaf448, decaf448_hasher, decaf448_oprf } from '@noble/curves/ed448.js';
console.log(ristretto255.Point, decaf448.Point);
Check out RFC 9496 more info on ristretto255 & decaf448. Check out separate documentation for Point, hasher and oprf.
Prehashed signing
import { secp256k1 } from '@noble/curves/secp256k1.js';
import { keccak_256 } from '@noble/hashes/sha3.js';
const { secretKey } = secp256k1.keygen();
const msg = new TextEncoder().encode('hello noble');
// prehash: true (default) - hash using secp256k1.hash (sha256)
const sig = secp256k1.sign(msg, secretKey);
// prehash: false - hash using custom hash
const sigKeccak = secp256k1.sign(keccak_256(msg), secretKey, { prehash: false });
Default sign() and verify() behavior (prehash: true) applies built-in hash function to message first.
For secp256k1 that's sha256, for p521 that's sha512.
Providing prehash: false allows user to specify their own hash function (e.g. use secp256k1 + keccak_256).
[!NOTE] Previously, in noble-curves v1,
prehash: falsewas the default. Some other libraries (like libsecp256k1) have no prehashing.
Recovering public keys from signatures
import { secp256k1 } from '@noble/curves/secp256k1.js';
const { secretKey, publicKey } = secp256k1.keygen();
const msg = new TextEncoder().encode('hello noble');
const sigRec = secp256k1.sign(msg, secretKey, { format: 'recovered' });
const publicKey_ = secp256k1.recoverPublicKey(sigRec, msg); // == publicKey
// recovered sig is compact sig with an extra byte
const sigNoRec = secp256k1.sign(msg, secretKey, { format: 'compact' });
// sigNoRec == sigRec.slice(1)
// Signature instance
const sigInstance = secp256k1.Signature.fromBytes(sigRec, 'recovered');
Public key recovery - only supported with ECDSA.
[!NOTE] Key recovery is a simple math operation. There are no guarantees the signing was actually done. It's possible to forge signature and msg hash (r, s, h), which would recover into a random public key, but it's not feasible to find m which would lead to this specific forged h.
Hedged ECDSA with noise
import { secp256k1 } from '@noble/curves/secp256k1.js';
const { secretKey } = secp256k1.keygen();
const msg = new TextEncoder().encode('hello noble');
// extraEntropy: false - default, hedging disabled
const sigNoisy = secp256k1.sign(msg, secretKey);
// extraEntropy: true - fetch 32 random bytes from CSPRNG
const sigNoisyA = secp256k1.sign(msg, secretKey, { extraEntropy: true });
// extraEntropy: bytes - specific extra entropy
const ent = Uint8Array.from([0xca, 0xfe, 0x01, 0x23]);
const sigNoisy2 = secp256k1.sign(msg, secretKey, { extraEntropy: ent });
ECDSA sign() allows providing extraEntropy, which switches sig generation to hedged mode.
By default, ECDSA signatures are generated deterministically, following RFC 6979. However, purely deterministic signatures are vulnerable to fault attacks. Newer signature schemes, such as BIP340 schnorr, switched to hedged signatures because of this. Hedging is basically incorporating some randomness into sig generation process.
For more info, check out Deterministic signatures are not your friends, RFC 6979 section 3.6, and cfrg-det-sigs-with-noise draft.
Consensus-friendliness vs e-voting
import { ed25519 } from '@noble/curves/ed25519.js';
const { secretKey, publicKey } = ed25519.keygen();
const msg = new TextEncoder().encode('hello noble');
const sig = ed25519.sign(msg, secretKey);
// zip215: true
const isValid = ed25519.verify(sig, msg, publicKey);
// SBS / e-voting / RFC8032 / FIPS 186-5
const isValidRfc = ed25519.verify(sig, msg, publicKey, { zip215: false });
[!NOTE] Most other libraries don't have SUF-CMA & SBS - less optimal choice for their security.
In ed25519, there is an ability to choose between consensus-friendliness vs e-voting mode.
zip215: true(default) uses the more permissive, consensus-friendly verification rules defined in ZIP215.zip215: falseenforces strict RFC 8032 / FIPS 186-5 verification and adds SBS-based non-repudiation, which is useful for:- Contract signing: prevents a signer from later claiming they signed a different document
- E-voting: stops voters from choosing keys that let them repudiate their vote
- Blockchains: avoids signatures valid for multiple transactions (e.g., amount X also validating amount Y)
Both modes have SUF-CMA (strong unforgeability under chosen message attacks). See Taming the many EdDSAs for more info.
ECDH: Diffie-Hellman shared secrets
import { secp256k1 } from '@noble/curves/secp256k1.js';
import { x25519 } from '@noble/curves/ed25519.js';
import { x448 } from '@noble/curves/ed448.js';
import { p256, p384, p521 } from '@noble/curves/nist.js';
for (const curve of [secp256k1, x25519, x448, p256, p384, p521]) {
const alice = curve.keygen();
const bob = curve.keygen();
const sharedKey = curve.getSharedSecret(alice.secretKey, bob.publicKey);
console.log('alice', alice, 'bob', bob, 'shared', sharedKey);
}
// x25519 & x448 specific methods
import { ed25519 } from '@noble/curves/ed25519.js';
const alice = ed25519.keygen();
const bob = ed25519.keygen();
const aliceSecX = ed25519.utils.toMontgomerySecret(alice.secretKey);
const bobPubX = ed25519.utils.toMontgomery(bob.publicKey);
const sharedKey = x25519.getSharedSecret(aliceSecX, bobPubX);
We provide ECDH over all Weierstrass curves, and over 2 Montgomery curves X25519 (Curve25519) & X448 (Curve448), conforming to RFC 7748.
In Weierstrass curves, shared secrets:
- Include y-parity bytes: use
key.slice(1)to strip it - Are not hashed: use hashing or KDF on top, like
sha256(shared)orhkdf(shared)
webcrypto: Friendly wrapper
[!NOTE] Webcrypto methods are always async.
webcrypto signatures
import { ed25519, ed448, p256, p384, p521 } from '@noble/curves/webcrypto.js';
(async () => {
for (let [name, curve] of Object.entries({ p256, p384, p521, ed25519, ed448 })) {
console.log('curve', name);
if (!await curve.isSupported()) {
console.log('is not supported, skipping');
continue;
}
const keys = await curve.keygen();
const msg = new TextEncoder().encode('hello noble');
const sig = await curve.sign(msg, keys.secretKey);
const isValid = await curve.verify(sig, msg, keys.publicKey);
console.log({
keys, msg, sig, isValid
});
}
})();
webcrypto ecdh
import { p256, p384, p521, x25519, x448 } from '@noble/curves/webcrypto.js';
(async () => {
for (let [name, curve] of Object.entries({ p256, p384, p521, x25519, x448 })) {
console.log('curve', name);
if (!await curve.isSupported()) {
console.log('is not supported, skipping');
continue;
}
const alice = await curve.keygen();
const bob = await curve.keygen();
const shared = await curve.getSharedSecret(alice.secretKey, bob.publicKey);
const shared2 = await curve.getSharedSecret(bob.secretKey, alice.publicKey);
console.log({shared});
}
})();
Key conversion from noble to webcrypto and back
import { p256 as p256n } from '@noble/curves/nist.js';
import { p256 } from '@noble/curves/webcrypto.js';
(async () => {
const nobleKeys = p256n.keygen();
// convert noble keys to webcrypto
const webKeys = {
secretKey: await p256.utils.convertSecretKey(nobleKeys.secretKey, 'raw', 'pkcs8'),
publicKey: await p256.utils.convertPublicKey(nobleKeys.publicKey, 'raw', 'spki')
};
// convert webcrypto keys to noble
const nobleKeys2 = {
secretKey: await p256.utils.convertSecretKey(webKeys.secretKey, 'pkcs8', 'raw'),
publicKey: await p256.utils.convertPublicKey(webKeys.publicKey, 'spki', 'raw')
};
})();
Check out micro-key-producer for pure JS key conversion utils.
BLS signatures, bls12-381, bn254 aka alt_bn128
import { bls12_381 } from '@noble/curves/bls12-381.js';
// G1 pubkeys, G2 sigs
const blsl = bls12_381.longSignatures;
const { secretKey, publicKey } = blsl.keygen();
// const publicKey = blsl.getPublicKey(secretKey);
const msg = new TextEncoder().encode('hello noble');
// default DST
const msgp = blsl.hash(msg);
// custom DST (Ethereum)
const msgpd = blsl.hash(msg, 'BLS_SIG_BLS12381G2_XMD:SHA-256_SSWU_RO_POP_');
const signature = blsl.sign(msgp, secretKey);
const isValid = blsl.verify(signature, msgp, publicKey);
console.log('long', { publicKey, signature, isValid });
// G1 sigs, G2 pubkeys
const blss = bls12_381.shortSignatures;
const publicKey2 = blss.getPublicKey(secretKey);
const msgp2 = blss.hash(msg, 'BLS_SIG_BLS12381G1_XMD:SHA-256_SSWU_RO_NUL_');
const signature2 = blss.sign(msgp2, secretKey);
const isValid2 = blss.verify(signature2, msgp2, publicKey2);
console.log({ publicKey2, signature2, isValid2 });
// Aggregation
const aggregatedKey = bls12_381.longSignatures.aggregatePublicKeys([
blsl.getPublicKey(bls12_381.utils.randomSecretKey()),
blsl.getPublicKey(bls12_381.utils.randomSecretKey()),
]);
// const aggregatedSig = bls.aggregateSignatures(sigs)
// Pairings, with and without final exponentiation
// bls.pairing(PointG1, PointG2);
// bls.pairing(PointG1, PointG2, false);
// bls.fields.Fp12.finalExponentiate(bls.fields.Fp12.mul(PointG1, PointG2));
// Others
// bls.G1.Point.BASE, bls.G2.Point.BASE;
// bls.fields.Fp, bls.fields.Fp2, bls.fields.Fp12, bls.fields.Fr;
See abstract/bls. For example usage, check out the implementation of BLS EVM precompiles.
The BN254 API mirrors BLS. The curve was previously called alt_bn128. The implementation is compatible with EIP-196 and EIP-197.
For BN254 usage, check out the implementation of bn254 EVM precompiles. We don't implement Point methods toBytes. To work around this limitation, has to initialize points on their own from BigInts. Reason it's not implemented is because there is no standard. Points of divergence:
- Endianness: LE vs BE (byte-swapped)
- Flags as first hex bits (similar to BLS) vs no-flags
- Imaginary part last in G2 vs first (c0, c1 vs c1, c0)
hash-to-curve: hashing to curve points
import { bls12_381 } from '@noble/curves/bls12-381.js';
import { ed25519_hasher, ristretto255_hasher } from '@noble/curves/ed25519.js';
import { decaf448_hasher, ed448_hasher } from '@noble/curves/ed448.js';
import { p256_hasher, p384_hasher, p521_hasher } from '@noble/curves/nist.js';
import { secp256k1_hasher } from '@noble/curves/secp256k1.js';
const h = {
secp256k1_hasher,
p256_hasher, p384_hasher, p521_hasher,
ed25519_hasher,
ed448_hasher,
ristretto255_hasher,
decaf448_hasher,
bls_G1: bls12_381.G1,
bls_G2: bls12_381.G2
};
const msg = Uint8Array.from([0xca, 0xfe, 0x01, 0x23]);
console.log('msg', msg);
for (let [name, c] of Object.entries(h)) {
const hashToCurve = c.hashToCurve(msg).toHex();
const hashToCurve_customDST = c.hashToCurve(msg, { DST: 'hello noble' }).toHex();
const encodeToCurve = 'encodeToCurve' in c ? c.encodeToCurve(msg).toHex() : undefined;
// ristretto255, decaf448 only
const deriveToCurve = 'deriveToCurve' in c ?
c.deriveToCurve!(new Uint8Array(c.Point.Fp.BYTES * 2)).toHex() : undefined;
const hashToScalar = c.hashToScalar(msg);
console.log({
name, hashToCurve, hashToCurve_customDST, encodeToCurve, deriveToCurve, hashToScalar
});
}
// abstract methods
import { expand_message_xmd, expand_message_xof, hash_to_field } from '@noble/curves/abstract/hash-to-curve.js';
The module allows to hash arbitrary strings to elliptic curve points. Implements RFC 9380.
[!NOTE] Why is
p256_hasherseparate fromp256? The methods reside in separate _hasher namespace for tree-shaking: this way users who don't need hash-to-curve, won't have it in their builds.
OPRFs
import { p256_oprf, p384_oprf, p521_oprf } from '@noble/curves/nist.js';
import { ristretto255_oprf } from '@noble/curves/ed25519.js';
import { decaf448_oprf } from '@noble/curves/ed448.js';
We provide OPRFs (oblivious pseudorandom functions), conforming to RFC 9497.
OPRF allows to interactively create an Output = PRF(Input, serverSecretKey):
- Server cannot calculate Output by itself: it doesn't know Input
- Client cannot calculate Output by itself: it doesn't know server secretKey
- An attacker interception the communication can't restore Input/Output/serverSecretKey and can't link Input to some value.
FROST threshold signatures
FROST implements RFC 9591 threshold Schnorr signing.
It is similar to multisig from the application point of view: any min of max participants
can jointly produce one Schnorr signature under a shared public key.
Supported ciphersuites are p256_FROST, ed25519_FROST, ed448_FROST, ristretto255_FROST,
secp256k1_FROST, and schnorr_FROST (Taproot-compatible secp256k1).
Signing has two rounds: selected signers commit first, then produce signature shares.
import { p256_FROST } from '@noble/curves/nist.js';
const signers = { min: 2, max: 3 };
const alice = p256_FROST.Identifier.derive('[email protected]');
const bob = p256_FROST.Identifier.derive('[email protected]');
const carol = p256_FROST.Identifier.derive('[email protected]');
// trusted dealer
const deal = p256_FROST.trustedDealer(signers, [alice, bob, carol]);
for (const id of [alice, bob, carol]) p256_FROST.validateSecret(deal.secretShares[id], deal.public);
const msg = new TextEncoder().encode('hello threshold');
// round 1: selected signers commit
const aliceRound1 = p256_FROST.commit(deal.secretShares[alice]);
const bobRound1 = p256_FROST.commit(deal.secretShares[bob]);
const commitmentList = [aliceRound1.commitments, bobRound1.commitments];
// round 2: signers produce signature shares
const sigShares = {
[alice]: p256_FROST.signShare(
deal.secretShares[alice],
deal.public,
aliceRound1.nonces,
commitmentList,
msg
),
[bob]: p256_FROST.signShare(
deal.secretShares[bob],
deal.public,
bobRound1.nonces,
commitmentList,
msg
),
};
const sig = p256_FROST.aggregate(deal.public, commitmentList, msg, sigShares);
const isValid = p256_FROST.verify(sig, msg, deal.public.commitments[0]);
Key generation can be done with a trusted dealer or with DKG. DKG has three rounds: participants commit to key generation, exchange private shares, then derive final participant keys.
import { p256_FROST } from '@noble/curves/nist.js';
const signers = { min: 2, max: 3 };
const alice = p256_FROST.DKG.round1(p256_FROST.Identifier.fromNumber(1), signers);
const bob = p256_FROST.DKG.round1(p256_FROST.Identifier.fromNumber(2), signers);
const carol = p256_FROST.DKG.round1(p256_FROST.Identifier.fromNumber(3), signers);
// round 1: participants commit to key generation
const aliceRound2 = p256_FROST.DKG.round2(alice.secret, [bob.public, carol.public]);
const bobRound2 = p256_FROST.DKG.round2(bob.secret, [alice.public, carol.public]);
const carolRound2 = p256_FROST.DKG.round2(carol.secret, [alice.public, bob.public]);
// round 2: private shares for each recipient
const aliceKey = p256_FROST.DKG.round3(alice.secret, [bob.public, carol.public], [
bobRound2[p256_FROST.Identifier.fromNumber(1)],
carolRound2[p256_FROST.Identifier.fromNumber(1)],
]);
// round 3: final participant key package
DKG helpers are intended for interoperable testing and practical key generation. The library implements the cryptographic steps, not the surrounding application protocol: callers still need authenticated communication, coordination, retries, session handling, and policy.
poseidon: Poseidon hash
Implements Poseidon ZK-friendly hash: permutation and sponge.
There are many poseidon variants with different constants. We don't provide them: you should construct them manually. Check out scure-starknet package for a proper example.
import { bn254 } from '@noble/curves/bn254.js';
import { grainGenConstants, poseidon, poseidonSponge } from '@noble/curves/abstract/poseidon.js';
const rate = 2;
const capacity = 1;
const Fp = bn254.fields.Fr;
const { mds, roundConstants } = grainGenConstants({
Fp,
t: rate + capacity,
roundsFull: 8,
roundsPartial: 31,
});
const opts = {
Fp,
rate,
capacity,
sboxPower: 17,
mds,
roundConstants,
roundsFull: 8,
roundsPartial: 31,
};
const permutation = poseidon({ ...opts, t: rate + capacity });
const sponge = poseidonSponge(opts); // use carefully, not specced
fft: Fast Fourier Transform
import * as fft from '@noble/curves/abstract/fft.js';
import { bls12_381 } from '@noble/curves/bls12-381.js';
const Fr = bls12_381.fields.Fr;
const roots = fft.rootsOfUnity(Fr, 7n);
const fftFr = fft.FFT(roots, Fr);
NTT / FFT (Fast Fourier Transform) over finite fields.
utils: byte shuffling, conversion
import { bytesToHex, concatBytes, equalBytes, hexToBytes } from '@noble/curves/utils.js';
bytesToHex(Uint8Array.from([0xca, 0xfe, 0x01, 0x23]));
hexToBytes('cafe0123');
concatBytes(Uint8Array.from([0xca, 0xfe]), Uint8Array.from([0x01, 0x23]));
equalBytes(Uint8Array.of(0xca), Uint8Array.of(0xca));
Internals
Elliptic curve Point math
import { pippenger } from '@noble/curves/abstract/curve.js';
import { secp256k1, schnorr } from '@noble/curves/secp256k1.js';
import { p256, p384, p521 } from '@noble/curves/nist.js';
import { ed25519, ristretto255 } from '@noble/curves/ed25519.js';
import { ed448, decaf448 } from '@noble/curves/ed448.js';
import { bls12_381 } from '@noble/curves/bls12-381.js';
import { bn254 } from '@noble/curves/bn254.js';
import { jubjub, babyjubjub } from '@noble/curves/misc.js';
const curves = [
secp256k1, schnorr, p256, p384, p521, ed25519, ed448,
ristretto255, decaf448,
bls12_381.G1, bls12_381.G2, bn254.G1,
jubjub, babyjubjub
];
for (const curve of curves) {
const { Point } = curve;
const { BASE, ZERO, Fp, Fn } = Point;
const info = Point.CURVE?.();
const p = BASE.multiply(2n);
// Initialization
if (info?.type === 'weierstrass') {
// projective (homogeneous) coordinates: (X, Y, Z) ∋ (x=X/Z, y=Y/Z)
const p_ = new Point(BASE.X, BASE.Y, BASE.Z);
} else if (info?.type === 'edwards') {
// extended coordinates: (X, Y, Z, T) ∋ (x=X/Z, y=Y/Z)
const p_ = new Point(BASE.X, BASE.Y, BASE.Z, BASE.T);
}
// Math
const p1 = p.add(p);
const p2 = p.double();
const p3 = p.subtract(p);
const p4 = p.negate();
const p5 = p.multiply(451n);
// MSM (multi-scalar multiplication)
const pa = [BASE, BASE.multiply(2n), BASE.multiply(4n), BASE.multiply(8n)];
const p6 = pippenger(Point, pa, [3n, 5n, 7n, 11n]);
const _true3 = p6.equals(BASE.multiply(129n)); // 129*G
const pcl = p.clearCofactor();
const isTorsionFree = p.isTorsionFree();
const r1 = p.toBytes();
const r1_ = Point.fromBytes(r1);
const r2 = p.toAffine();
const { x, y } = r2;
const r2_ = Point.fromAffine(r2);
}
modular: Modular arithmetics & finite fields
import { mod, invert, Field } from '@noble/curves/abstract/modular.js';
// Finite Field utils
const fp = Field(2n ** 255n - 19n); // Finite field over 2^255-19
fp.mul(591n, 932n); // multiplication
fp.pow(481n, 11024858120n); // exponentiation
fp.div(5n, 17n); // division: 5/17 mod 2^255-19 == 5 * invert(17)
fp.inv(5n); // modular inverse
fp.sqrt(4n); // square root
// Non-Field generic utils are also available
mod(21n, 10n); // 21 mod 10 == 1n; fixed version of 21 % 10
invert(17n, 10n); // invert(17) mod 10; modular multiplicative inverse
All arithmetics is done with JS bigints over finite fields,
which is defined from modular sub-module.
Field operations are not constant-time: see security.
The fact is mostly irrelevant, but the important method to keep in mind is pow,
which may leak exponent bits, when used naïvely.
weierstrass: Custom Weierstrass curve
import { weierstrass } from '@noble/curves/abstract/weierstrass.js';
// NIST secp192r1 aka p192. https://www.secg.org/sec2-v2.pdf
const p192_CURVE = {
p: 0xfffffffffffffffffffffffffffffffeffffffffffffffffn,
n: 0xffffffffffffffffffffffff99def836146bc9b1b4d22831n,
h: 1n,
a: 0xfffffffffffffffffffffffffffffffefffffffffffffffcn,
b: 0x64210519e59c80e70fa7e9ab72243049feb8deecc146b9b1n,
Gx: 0x188da80eb03090f67cbf20eb43a18800f4ff0afd82ff1012n,
Gy: 0x07192b95ffc8da78631011ed6b24cdd573f977a11e794811n,
};
const p192_Point = weierstrass(p192_CURVE);
Short Weierstrass curve's formula is y² = x³ + ax + b. weierstrass
expects arguments a, b, field characteristic p, curve order n,
cofactor h and coordinates Gx, Gy of generator point.
edwards: Custom Edwards curve
import { edwards } from '@noble/curves/abstract/edwards.js';
const ed25519_CURVE = {
p: 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffedn,
n: 0x1000000000000000000000000000000014def9dea2f79cd65812631a5cf5d3edn,
h: 8n,
a: 0x7fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffecn,
d: 0x52036cee2b6ffe738cc740797779e89800700a4d4141d8ab75eb4dca135978a3n,
Gx: 0x216936d3cd6e53fec0a4e231fdd6dc5c692cc7609525a7b2c9562d608f25d51an,
Gy: 0x6666666666666666666666666666666666666666666666666666666666666658n,
};
const ed25519_Point = edwards(ed25519_CURVE);
Twisted Edwards curve's formula is ax² + y² = 1 + dx²y².
You must specify a, d, field characteristic p, curve order n (sometimes named as L),
cofactor h and coordinates Gx, Gy of generator point.
Custom ECDSA instance
import { weierstrass, ecdsa } from '@noble/curves/abstract/weierstrass.js';
import { sha224, sha256 } from '@noble/hashes/sha2.js';
const p192_CURVE = {
p: 0xfffffffffffffffffffffffffffffffeffffffffffffffffn,
n: 0xffffffffffffffffffffffff99def836146bc9b1b4d22831n,
h: 1n,
a: 0xfffffffffffffffffffffffffffffffefffffffffffffffcn,
b: 0x64210519e59c80e70fa7e9ab72243049feb8deecc146b9b1n,
Gx: 0x188da80eb03090f67cbf20eb43a18800f4ff0afd82ff1012n,
Gy: 0x07192b95ffc8da78631011ed6b24cdd573f977a11e794811n,
};
const p192_Point = weierstrass(p192_CURVE);
const p192_sha256 = ecdsa(p192_Point, sha256);
// or
const p192_sha224 = ecdsa(p192_Point, sha224);
const keys = p192_sha256.keygen();
const msg = new TextEncoder().encode('custom curve');
const sig = p192_sha256.sign(msg, keys.secretKey);
const isValid = p192_sha256.verify(sig, msg, keys.publicKey);
Security
The library has been audited:
- at version 2.2.0, in Apr 2026, by ourselves (self-audited)
- Scope: everything
- Changes since audit
- at version 1.6.0, in Sep 2024, independently, by Cure53
- PDFs: website, in-repo
- Changes since audit
- Scope: ed25519, ed448, their add-ons, bls12-381, bn254, hash-to-curve, low-level primitives bls, tower, edwards, montgomery.
- The audit has been funded by OpenSats
- at version 1.2.0, in Sep 2023, independently, by Kudelski Security
- PDFs: in-repo
- Changes since audit
- Scope: scure-starknet and its related
abstract modules of noble-curves:
curve,modular,poseidon,weierstrass - The audit has been funded by Starkware
- at version 0.7.3, in Feb 2023, independently, by Trail of Bits
- PDFs: website, in-repo
- Changes since audit
- Scope: abstract modules
curve,hash-to-curve,modular,poseidon,utils,weierstrassand top-level modules_shortw_utilsandsecp256k1 - The audit has been funded by Ryan Shea
It is tested against property-based, cross-library and Wycheproof vectors, and is being fuzzed in the separate repo.
If you see anything unusual: investigate and report.
Constant-timeness
We're targetting algorithmic constant time. JIT-compiler and Garbage Collector make "constant time" extremely hard to achieve timing attack resistance in a scripting language. Which means any other JS library can't have constant-timeness. Even statically typed Rust, a language without GC, makes it harder to achieve constant-time for some cases. If your goal is absolute security, don't use any JS lib — including bindings to native ones. Use low-level libraries & languages.
Within those limits, secret-scalar multiplication provides specific, measurable properties:
- Fixed operation sequence:
multiply()uses signed fixed-window tables with data-oblivious table scans — the number and order of point operations is independent of the scalar value. - Scalar blinding: secret scalars are additionally masked as
s + r·nwith a random 128-bitrbefore multiplication. This applies to all multiplications on cofactor-1 curves (p256, p384, p521, secp256k1), and to base-point multiplications everywhere. - Statistical validation: a dudect-style Welch t-test harness (
benchmark/ct.ts) compares timing across adversarial scalar classes (sparse vs dense, low vs high bits, near-order, bit patterns). Base-point multiplication shows no distinguishable timing on any curve, and random-point multiplication shows none on the Weierstrass curves (max |t| ≤ 2.8 at 1000 samples; threshold 4.5).
Known limitation: on cofactored Edwards curves (ed25519, ed448), multiplying a non-base point by a secret scalar is not blinded. The same harness detects this reliably. EdDSA signing is unaffected (it only multiplies the blinded base point), and X25519/X448 use a separate Montgomery-ladder implementation (also unaffected). It matters for protocols that multiply arbitrary Edwards/Ristretto points by long-lived secret scalars; prefer scalars that are full-width by construction there. Note that detectability in an isolated harness does not imply practical exploitability: we attempted scalar extraction in a realistic cross-tenant / in-browser setting and were unable to recover Edwards scalars even with 100,000 timing samples.
Memory dumping
Use low-level languages instead of JS / WASM if your goal is absolute security.
The library mostly uses Uint8Arrays and bigints.
- Uint8Arrays have
.fill(0)which instructs to fill content with zeroes but there are no guarantees in JS - bigints are immutable and don't have a method to zeroize their content: a user needs to wait until the next garbage collection cycle
- hex strings are also immutable: there is no way to zeroize them
await fn()will write all internal variables to memory. With async functions there are no guarantees when the code chunk would be executed. Which means attacker can have plenty of time to read data from memory.
This means some secrets could stay in memory longer than anticipated. However, if an attacker can read application memory, it's doomed anyway: there is no way to guarantee anything about zeroizing sensitive data without complex tests-suite which will dump process memory and verify that there is no sensitive data left. For JS it means testing all browsers (including mobile). And, of course, it will be useless without using the same test-suite in the actual application that consumes the library.
Supply chain security
- Commits are signed with PGP keys to prevent forgery. Be sure to verify the commit signatures
- Releases are made transparently through token-less GitHub CI and Trusted Publishing. Be sure to verify the provenance logs for authenticity.
- Rare releasing is practiced to minimize the need for re-audits by end-users.
- Dependencies are minimized and strictly pinned to reduce supply-chain risk.
- We use as few dependencies as possible.
- Version ranges are locked, and changes are checked with npm-diff.
- Dev dependencies are excluded from end-user installs; they’re only used for development and build steps.
For this package, there is 1 dependency; and a few dev dependencies:
- noble-hashes provides cryptographic hashing functionality
- jsbt is used for benchmarking / testing / build tooling and developed by the same author
- prettier, fast-check and typescript are used for code quality / test generation / ts compilation
Randomness
We rely on the built-in
crypto.getRandomValues,
which is considered a cryptographically secure PRNG.
Browsers have had weaknesses in the past - and could again - but implementing a userspace CSPRNG is even worse, as there’s no reliable userspace source of high-quality entropy.
Quantum computers
Cryptographically relevant quantum computer, if built, will allow to break elliptic curve cryptography (both ECDSA / EdDSA & ECDH) using Shor's algorithm.
Consider switching to newer / hybrid algorithms, such as SPHINCS+. They are available in noble-post-quantum.
NIST prohibits classical cryptography (RSA, DSA, ECDSA, ECDH) after 2035. Australian ASD prohibits it after 2030.
Speed
npm run benchmark
noble-curves spends 10+ ms to generate 20MB+ of base point precomputes. This is done one-time per curve.
The generation is deferred until any method (pubkey, sign, verify) is called.
User can force precompute generation by manually calling Point.BASE.precompute(windowSize, false).
Check out the source code.
Benchmark results on Apple M4:
# secp256k1
init 11ms
getPublicKey x 4,909 ops/sec @ 203μs/op
sign x 4,319 ops/sec @ 231μs/op
verify x 1,391 ops/sec @ 718μs/op
recoverPublicKey x 1,377 ops/sec @ 725μs/op
getSharedSecret x 793 ops/sec @ 1ms/op
schnorr.sign x 895 ops/sec @ 1ms/op
schnorr.verify x 1,418 ops/sec @ 704μs/op
# ed25519
init 9ms
getPublicKey x 7,161 ops/sec @ 139μs/op
sign x 3,541 ops/sec @ 282μs/op
verify x 1,483 ops/sec @ 674μs/op
# ed448
init 19ms
getPublicKey x 3,125 ops/sec @ 319μs/op
sign x 1,549 ops/sec @ 645μs/op
verify x 518 ops/sec @ 1ms/op ± 6.59% (1ms..15ms)
# p256
init 9ms
getPublicKey x 4,799 ops/sec @ 208μs/op
sign x 4,262 ops/sec @ 234μs/op
verify x 943 ops/sec @ 1ms/op
# p384
init 20ms
getPublicKey x 2,208 ops/sec @ 452μs/op
sign x 1,949 ops/sec @ 512μs/op
verify x 371 ops/sec @ 2ms/op
# p521
init 37ms
getPublicKey x 1,215 ops/sec @ 822μs/op
sign x 1,116 ops/sec @ 895μs/op
verify x 186 ops/sec @ 5ms/op
# ristretto255
add x 719,424 ops/sec @ 1μs/op
multiply x 7,214 ops/sec @ 138μs/op
encode x 21,337 ops/sec @ 46μs/op
decode x 20,682 ops/sec @ 48μs/op
# decaf448
add x 467,945 ops/sec @ 2μs/op
multiply x 682 ops/sec @ 1ms/op
encode x 8,279 ops/sec @ 120μs/op
decode x 8,044 ops/sec @ 124μs/op
# ECDH
x25519 x 1,631 ops/sec @ 612μs/op
x448 x 584 ops/sec @ 1ms/op
secp256k1 x 791 ops/sec @ 1ms/op
p256 x 757 ops/sec @ 1ms/op
p384 x 329 ops/sec @ 3ms/op
p521 x 175 ops/sec @ 5ms/op
# hash-to-curve
hashToScalar x 212,404 ops/sec @ 4μs/op
hash_to_field x 239,578 ops/sec @ 4μs/op
hashToCurve secp256k1 x 5,101 ops/sec @ 196μs/op
hashToCurve p256 x 7,651 ops/sec @ 130μs/op
hashToCurve p384 x 3,275 ops/sec @ 305μs/op
hashToCurve p521 x 1,642 ops/sec @ 608μs/op
hashToCurve ed25519 x 6,679 ops/sec @ 149μs/op
hashToCurve ed448 x 2,911 ops/sec @ 343μs/op
hash_to_ristretto255 x 9,284 ops/sec @ 107μs/op
hash_to_decaf448 x 3,764 ops/sec @ 265μs/op
# modular over secp256k1 P field
invert a x 868,809 ops/sec @ 1μs/op
invert b x 662,251 ops/sec @ 1μs/op
sqrt p = 3 mod 4 x 24,440 ops/sec @ 40μs/op
sqrt tonneli-shanks x 803 ops/sec @ 1ms/op
# bls12-381
init 90ms
getPublicKey x 2,315 ops/sec @ 431μs/op
sign x 222 ops/sec @ 4ms/op
verify x 113 ops/sec @ 8ms/op
pairing x 160 ops/sec @ 6ms/op
pairing10 x 42 ops/sec @ 23ms/op ± 7.14% (22ms..36ms)
MSM 4096 scalars x points 564ms
aggregatePublicKeys/8 x 1,862 ops/sec @ 536μs/op
aggregatePublicKeys/32 x 1,589 ops/sec @ 629μs/op
aggregatePublicKeys/128 x 988 ops/sec @ 1ms/op
aggregatePublicKeys/512 x 396 ops/sec @ 2ms/op
aggregatePublicKeys/2048 x 115 ops/sec @ 8ms/op
aggregateSignatures/8 x 87 ops/sec @ 11ms/op
aggregateSignatures/32 x 23 ops/sec @ 43ms/op
aggregateSignatures/128 x 5 ops/sec @ 170ms/op
aggregateSignatures/512 x 1 ops/sec @ 680ms/op
aggregateSignatures/2048 x 0 ops/sec @ 2737ms/op
Upgrading
Supported node.js versions:
- v2 (2025-08): v20.19+ (ESM-only)
- v1 (2023-04): v14.21+ (ESM & CJS)
v1 to v2
v2 massively simplifies internals, improves security, reduces bundle size and lays path for the future. We tried to keep v2 as much backwards-compatible as possible.
Upgrade path: upgrade to curves v1.9.x first. Fix the deprecation warnings, then switch to v2.
Modules:
- The package is now ESM-only. ESM can finally be loaded from common.js on node v20.19+
.jsextension is now required:@noble/curves/ed25519=>@noble/curves/ed25519.js. This enables native browser usage, without transpilersp256,p384,p521were moved intonist;jubjubwas moved intomiscpastaandbn254_weierstrass(NOT pairing-based bn254) curves were removed
New features:
- webcrypto: friendly noble-like wrapper over built-in WebCrypto
- oprf: RFC 9497 OPRFs (oblivious pseudorandom functions) for p256, p384, p521, ristretto255 and decaf448
- weierstrass, edwards: new
isValidSecretKey,isValidPublicKeymethods - misc: Brainpool curves brainpoolP256r1, brainpoolP384r1, brainpoolP512r1
- Massively improved, more descriptive error messages
Breaking changes:
- Most methods now only accept Uint8Array; string hex inputs are prohibited.
This simplifies reasoning, improves security and reduces malleability.
Point.fromHexis now string-only: usePoint.fromBytesfor Uint8Array - ECDSA (secp256k1, p256, p384...) sign & verify:
- Prehashed messages: methods now expect the unhashed message
instead of messageHash. Old behavior:
{prehash: false} - lowS signatures by default. secp256k1 is unaffected: it has used
lowS since the beginning. Old behavior:
{lowS: false} - Uint8Array signatures (format: 'compact') by default
- verify: der format must be explicitly specified in
{format: 'der'}. This reduces malleability - verify: Signature instances are prohibited: call
signature.toBytes()first
- Prehashed messages: methods now expect the unhashed message
instead of messageHash. Old behavior:
- BLS signatures (bls12-381, bn254):
- getPublicKey, sign, verify, signShortSignature etc were moved into two new namespaces:
longSignatures(G1 pubkeys, G2 sigs) andshortSignatures(G1 sigs, G2 pubkeys) - verifyBatch now expects array of inputs
{message: ..., publicKey: ...}[]
- getPublicKey, sign, verify, signShortSignature etc were moved into two new namespaces:
- Custom curves:
- Curve creation was massively simplified and split into point creation &
sig generator creation:
weierstrass() + ecdsa()/edwards() + eddsa(). weierstrass / edwards expect simplified curve params (Fp became p); ecdsa / eddsa expect Point class and hash - pippenger: removed unnecessary Fn argument
- Field#fromBytes() now validates elements to be in 0..order-1 range
- Curve creation was massively simplified and split into point creation &
sig generator creation:
Renamings (curves v1.9 highlights old names as deprecated):
- Points
- ExtendedPoint, ProjectivePoint => Point
- Point coordinates px/ex, py/ey, pz/ez, et => X, Y, Z, T
- toRawBytes, fromRawBytes => toBytes, fromBytes
- Point.normalizeZ, Point.msm => separate methods in
abstract/curve.jssubmodule - Point.fromPrivateKey(key) =>
Point.BASE.multiply(Point.Fn.fromBytes(key)) CURVEproperty with all kinds of random stuff => Point.CURVE(), which only provides curve parameters- RistrettoPoint => ristretto255.Point, DecafPoint => decaf448.Point
- ECDSA Signatures
- toCompactRawBytes, toDERRawBytes => toBytes('compact'), toBytes('der')
- toCompactHex, toDERHex => toHex('compact'), toHex('der')
- fromCompact, fromDER => fromBytes(bytes, format), fromHex(hex, format)
- utils
- randomPrivateKey => randomSecretKey
- normPrivateKeyToScalar => Point.Fn.fromBytes
- utils.precompute, Point#_setWindowSize => Point#precompute
- edwardsToMontgomery, edwardsToMontgomeryPriv => utils.toMontgomery, utils.toMontgomerySecret
- Curve-specific hash-to-curve methods =>
*curve*_hasher. Example:secp256k1.hashToCurve=>secp256k1_hasher.hashToCurve() - Massive type renamings and improvements
Removed features: Point#multiplyAndAddUnsafe, Point#hasEvenY, Field.MASK
License
The MIT License (MIT)
Copyright (c) 2022 Paul Miller (https://paulmillr.com)
See LICENSE file.
Related repositories
Algorithms and Data Structures implemented in JavaScript for beginners, following best practices.
General purpose TLS and crypto library
OpenZeppelin Contracts is a library for secure smart contract development.
⚡ Automatically decrypt encryptions without knowing the key or cipher, decode encodings, and crack hashes ⚡
Quick answers
How active is development on paulmillr/noble-curves?
The most recent commit recorded on paulmillr/noble-curves was 9 days ago, based on the GitHub push timestamp. The repository has 98 forks — one of the better signals of community interest.
How does paulmillr/noble-curves compare to other Security projects?
paulmillr/noble-curves is tracked by TopGit in the Security category, with 935 GitHub stars and written in TypeScript. Browse the Security topic page on TopGit to compare it against similar projects by stars and activity.
How many stars does paulmillr/noble-curves have?
paulmillr/noble-curves has 935 GitHub stars — refresh the page for the live number, or check github.com/paulmillr/noble-curves. TopGit mirrors GitHub's count but does not claim minute-by-minute accuracy.
Is paulmillr/noble-curves open source?
Yes — paulmillr/noble-curves ships under the MIT license, which makes its source code freely readable (and, depending on license terms, forkable and reusable). Source: github.com/paulmillr/noble-curves.
What is paulmillr/noble-curves?
paulmillr/noble-curves (paulmillr/noble-curves) is a TypeScript project on GitHub. From the project's own README: Audited & minimal JS implementation of elliptic curve cryptography.
Where do I read more about paulmillr/noble-curves?
This TopGit page is a snapshot — the READ ME tab shows the project's own README content (links stripped, images preserved). The GitHub repository at github.com/paulmillr/noble-curves is the definitive source.
Read full README in the tab above.
Curious whether noble-curves is right for you?
Let ChatGPT, Claude, or Perplexity look into it — click below and see what AI actually says about noble-curves.