ECDSA Key Pair Generator — P-256 / P-384 / P-521, PEM & JWK

What is ECDSA Key Generator?

An ECDSA Key Generator produces elliptic curve key pairs used for signing (JWT ES256/384/512, SSH keys, TLS 1.3 certificates, cryptocurrency wallets). ECDSA gives the same security as much larger RSA keys: P-256 ≈ RSA-3072 in strength while being ~10x faster to sign and producing ~8x smaller signatures. That's why every modern spec — WebAuthn, TLS 1.3, JWS — prefers EC keys over RSA.

How to generate an ECDSA key pair

1. 1Choose a curve. P-256 (also called `prime256v1` / `secp256r1`) is the default — the same curve used by TLS 1.3 and WebAuthn.
2. 2P-384 for higher-security workloads (equivalent to RSA-7680). P-521 for maximum strength (equivalent to RSA-15360). P-256 is enough for 99% of use cases.
3. 3Click Generate. Signing runs in-browser via `crypto.subtle.generateKey`, so private keys never leave your machine.
4. 4Export the private key as SEC1 (`-----BEGIN EC PRIVATE KEY-----`) or PKCS#8 (`-----BEGIN PRIVATE KEY-----`) PEM.
5. 5Export the public key as SPKI PEM (`-----BEGIN PUBLIC KEY-----`) or JWK — this is the safe half to publish, e.g. in your JWKS.

Use Cases

Code Examples

# Generate a P-256 private key
openssl ecparam -name prime256v1 -genkey -noout -out ec-private.pem

# Extract the public key
openssl ec -in ec-private.pem -pubout -out ec-public.pem

import { generateKeyPair } from "node:crypto";
import { promisify } from "node:util";

const { publicKey, privateKey } = await promisify(generateKeyPair)("ec", {
  namedCurve: "P-256",
  publicKeyEncoding: { type: "spki", format: "pem" },
  privateKeyEncoding: { type: "pkcs8", format: "pem" },
});

from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import serialization

key = ec.generate_private_key(ec.SECP256R1())
pem = key.private_bytes(
    encoding=serialization.Encoding.PEM,
    format=serialization.PrivateFormat.PKCS8,
    encryption_algorithm=serialization.NoEncryption(),
)

import (
    "crypto/ecdsa"
    "crypto/elliptic"
    "crypto/rand"
)

key, err := ecdsa.GenerateKey(elliptic.P256(), rand.Reader)

Key Concepts

P-256 / P-384 / P-521

NIST-standardized curves. Also known as prime256v1 / secp256r1, secp384r1, and secp521r1. The number is the bit-length of the underlying prime field, not the security level. Security level is roughly half: P-256 gives ~128-bit security.

ECDSA vs. EdDSA (Ed25519)

Ed25519 uses a different curve family (Edwards curves) and is generally preferred where supported — deterministic signatures (no RNG-failure risk), constant-time by design, smaller keys (32 bytes). JWT doesn't standardize Ed25519 for JWS yet (EdDSA is defined in RFC 8037 but adoption is uneven), so ECDSA remains the practical default.

SEC1 vs. PKCS#8

SEC1 (`-----BEGIN EC PRIVATE KEY-----`) is the older EC-specific format. PKCS#8 (`-----BEGIN PRIVATE KEY-----`) is the modern generic format and what Web Crypto emits. Convert with `openssl pkcs8 -topk8 -in sec1.pem -out pkcs8.pem -nocrypt`.

Curve must match algorithm

ES256 requires exactly P-256, ES384 requires P-384, ES512 requires P-521 (not P-512 — that's a common footgun). Using the wrong curve produces a valid-looking key that any verifier will reject.

Tips & Best Practices

• ▸For new work, prefer ES256 (P-256 + SHA-256) over RS256. Same security, ~8x smaller signatures, ~10x faster signing — no downsides for anyone using a modern library.
• ▸Never sign the same message with the same nonce twice. If your library exposes a `k` value, use RFC 6979 deterministic ECDSA — it removes the RNG requirement entirely.
• ▸Store the private key with `PrivateFormat.PKCS8`. If you must use SEC1 for legacy compatibility, know that PKCS#8 is a strict superset and better in every way.
• ▸When publishing to JWKS, remove `d` (the private component) — leaving it in exposes the entire private key. Our JWKS Generator strips it automatically.