Is ECDSA quantum-safe?

Why ECDSA breaks

Elliptic-curve cryptography replaced the "factoring" hard problem with the elliptic-curve discrete logarithm problem (ECDLP). It's more efficient than RSA for the same classical security — which is why it's everywhere. But ECDLP is exactly the kind of problem Shor's algorithm dismantles. A quantum attacker recovers the signing key from the public key, and can then forge signatures at will.

Curve choice doesn't save you: P-256, secp256k1, P-384 — all rely on ECDLP, all fall to Shor. A larger curve raises the classical bar and does nothing against quantum.

Why this one is everywhere

ECDSA is the signature primitive behind:

• The majority of modern TLS certificates and handshakes
• Nearly every blockchain wallet (Bitcoin, Ethereum and most others use secp256k1 ECDSA)
• JWT signing with ES256 / ES384 / ES512
• SSH keys, code signing, and document signing
• Libraries: elliptic, @noble/curves, Python ecdsa/cryptography, Go crypto/ecdsa, the Rust ecdsa/k256 crates

What about Ed25519?

Same story. Ed25519 (EdDSA) is also built on an elliptic-curve discrete-log problem, so it is also quantum-vulnerable despite its modern reputation. "Newer curve" is not "post-quantum." See Is X25519 quantum-safe? for the key-exchange cousin.

What to migrate to

• ML-DSA (FIPS 204) — NIST's primary lattice-based signature standard.
• SLH-DSA (FIPS 205) — stateless hash-based signatures, a conservative choice for long-lived roots of trust.

Signatures don't carry harvest-now-decrypt-later risk (forgery needs a working quantum computer), so they trail key exchange in priority — but move firmware, CA, and code-signing keys early, since they must outlive the threat.