Almost every HTTPS connection you make today uses elliptic curve cryptography. It won because it does the same job as RSA with far smaller keys, which matters when a busy server is doing thousands of handshakes a second. It loses to a quantum computer for the same reason RSA does, only sooner.
The same trick, a harder-to-reverse operation
RSA rests on multiplying being easy and factoring being hard. Elliptic curve cryptography rests on a different lopsided operation, and the shape of the idea is identical.
Picture a curve with a rule for adding two points on it together to land on a third point, also on the curve. Start at a fixed point and apply that rule to itself some number of times. Doing it is fast, even for enormous counts. Recovering the count from where you ended up is the hard part, and that count is your private key. Where you landed is your public key.
Why the keys are so much smaller
The best known attack on factoring gets meaningfully faster as clever people improve it, so RSA keys had to keep growing. The best known attack on elliptic curves has barely moved, so key sizes did not need to. A 256-bit curve gives roughly the same classical security as a 3072-bit RSA key: a twelvefold difference for the same protection.
ECDH and ECDSA are not the same thing
Two algorithms sit on top of the same curves, and mixing them up causes real confusion when people plan a migration.
- ECDH is key agreement. Two parties each have a key pair, they exchange public halves, and each combines their own private half with the other's public one. Both arrive at the same shared secret, and an eavesdropper who saw both public halves cannot. That secret then keys a symmetric cipher, which does the actual encrypting.
- ECDSA is signing. You sign with the private key, anyone verifies with the public one. Same curves, entirely different job.
That ECDH pattern matters more than it looks. Notice that ECDH does not encrypt your message either: it agrees a secret, and something else encrypts. That is precisely how ML-KEM works, which makes ECDH the better mental model for the post-quantum transition than RSA is.
Which curve
| Curve | Private key | Classical security | Where you see it |
|---|---|---|---|
| P-256 (secp256r1) | 32 bytes | ~128 bits | TLS, most certificates, the common default |
| P-384 (secp384r1) | 48 bytes | ~192 bits | CNSA 1.0 systems, higher assurance |
| P-521 (secp521r1) | 66 bytes | ~260 bits | Rare, mostly where policy demands it |
| Curve25519 | 32 bytes | ~128 bits | Signal, SSH, WireGuard, modern non-NIST stacks |
| secp256k1 | 32 bytes | ~128 bits | Bitcoin, Ethereum, Nostr |
If you have no constraint pushing you elsewhere, P-256 is the answer, and Curve25519 is the answer where NIST curves are not required. Both are fine. Neither survives a quantum computer.
Why ECC falls first
This surprises people who assume the smaller key is the weaker one and the bigger key buys time. Against a classical attacker that intuition holds. Against a quantum one it inverts.
Shor's algorithm solves both factoring and the elliptic curve problem, and the quantum resources it needs scale with the size of the numbers involved. A 256-bit curve involves far smaller numbers than a 2048-bit RSA modulus, so a quantum computer capable of breaking P-256 is smaller than one capable of breaking RSA-2048. The efficiency that made ECC attractive is what puts it first in line.
This applies to your signing keys too
Harvest now, decrypt later is about confidentiality, so people reason that signatures are safe because a signature verified today cannot be retroactively forged. That is true for the signature, and false for the key. Any long-lived ECDSA key, a code-signing root or a certificate authority, is a key an attacker can forge with once the machine exists. Long-lived signing keys need the same plan as encryption keys.
Generate a key and look at it
Generate a P-256 key with OpenSSL and inspect it. The private key is 32 bytes: that is the whole secret, a single large number. Compare that with the structure inside an RSA private key, which carries both primes and several precomputed values.
You can also derive an elliptic curve key from a seed phrase in the key generator, which RSA cannot do. A curve private key is just a number in a range, so hashing a phrase down to the right width produces one. That is exactly how a crypto wallet turns twelve words into an address.
What replaces it
| What ECC did | The replacement | Size change |
|---|---|---|
| ECDH key agreement | ML-KEM | Public key 65 bytes to 1,184 |
| ECDSA signatures | ML-DSA | Signature 64 bytes to ~3,300 |
Those numbers are the migration. Everything hard about moving off elliptic curve is a consequence of that table: packets that no longer fit, certificate chains that grow, embedded devices with no room. The practical sequencing is in migrating RSA and ECDH to ML-KEM, and the interim answer most of the internet is using is hybrid key exchange.