ECDSA Key Generator
Generate ECDSA public/private key pairs in PEM format using your browser's Web Crypto API — keys never leave your device.
What is ECDSA?
ECDSA (Elliptic Curve Digital Signature Algorithm) is a public-key cryptography standard used to create digital signatures. It is widely used in TLS certificates, code signing, and cryptocurrencies. Compared to RSA, ECDSA produces smaller keys and signatures while offering equivalent security — a P-256 key provides roughly the same security as a 3072-bit RSA key. P-256, P-384, and P-521 refer to the prime modulus size of the underlying NIST curves. Keys are exported in standard SPKI (public) and PKCS#8 (private) formats and PEM-encoded, making them compatible with OpenSSL, Node.js, and most TLS stacks. All computation happens inside your browser via the Web Crypto API; nothing is sent to any server.
Built and maintained by Meet Shah · Last updated
What this tool is used for
- Producing an elliptic-curve key pair for signing where RSA would be unnecessarily large.
- Generating a test key for a signature verification path.
- Producing a key to sign JWTs with an ES algorithm.
- Creating a PEM pair to load into a library while checking its parsing.
- Comparing curve sizes and their key lengths before choosing one.
Frequently Asked Questions
- Which curves are offered and what do they mean?
- P-256, P-384 and P-521 — the NIST prime curves, also called secp256r1, secp384r1 and secp521r1. The number is the field size in bits, giving roughly 128, 192 and 256 bits of security respectively. P-256 is the near-universal default.
- Why is an ECDSA key so much smaller than RSA?
- Because the underlying problem is harder per bit. A 256-bit elliptic curve key gives comparable security to a 3072-bit RSA key, so signatures and handshakes are dramatically smaller and faster — which is why TLS moved to elliptic curves for key exchange.
- What is the danger with the nonce?
- ECDSA needs a fresh random value per signature, and reusing one across two signatures reveals the private key algebraically. That is not theoretical — it is how the PlayStation 3 signing key was recovered in 2010. Deterministic ECDSA (RFC 6979) exists to remove the risk.
- What is the difference between PKCS#8 and SEC1?
- Both are private key encodings. PKCS#8 is the generic `BEGIN PRIVATE KEY` wrapper that names the algorithm inside; SEC1 is the older `BEGIN EC PRIVATE KEY` form. Software that rejects your key usually wants the other one, and converting between them is a format change, not a re-generation.
- Is the key generated safely here?
- It uses the browser's Web Crypto implementation, which draws from the operating system's CSPRNG, and nothing is transmitted. For a production key, generating on the machine that will use it — and never copying the private half anywhere — remains the better practice.
Common errors and gotchas
- Sharing the wrong half of the pair, which is easy when both are PEM blocks.
- Reusing a nonce when signing, which for ECDSA leaks the private key outright.
- Mismatching the curve and the hash, where P-256 pairs with SHA-256 and P-384 with SHA-384.
- Assuming PEM headers are interchangeable, when PKCS#8 and SEC1 wrap different structures.
- Using a browser-generated key for something holding real value without considering where it was made.