ECC encryption vs RSA: elliptic curves explained
Why elliptic curves match RSA with far smaller keys: ECDH, ECDSA and Ed25519, choosing P-256 or X25519, measured speeds side by side, and the quantum risk.
On this page 13 sections
- What an elliptic curve is, in plain terms
- Why smaller keys are enough
- ECDH, ECDSA and EdDSA
- ECDH: agreeing on a key
- ECDSA: signatures on NIST curves
- EdDSA and Ed25519
- So what is "ECC encryption"?
- Curve choices: P-256, X25519 and Ed25519
- ECC vs RSA side by side
- Quantum computers and ECC
- Where ECC meets a course app
- Key takeaways
- Frequently asked questions
Elliptic-curve cryptography (ECC) is a family of asymmetric algorithms that match RSA's security with much smaller keys: NIST rates a 256-bit elliptic-curve key about as strong as a 3,072-bit RSA key. Despite the common phrase "ECC encryption", ECC is mostly used for key exchange (ECDH, X25519) and digital signatures (ECDSA, Ed25519) rather than for encrypting data directly. Its small keys make it faster at signing and cheaper to send, which is why every TLS 1.3 implementation must support it.
What an elliptic curve is, in plain terms
An elliptic curve, for cryptography, is the set of points that satisfy an equation of the form y² = x³ + ax + b, with all the arithmetic done modulo a large prime so that every value is a whole number. The points come with a rule for "adding" two of them to get a third point on the curve.
Adding a starting point G to itself k times gives a point written k × G. Even when k is a 256-bit number, a computer can do this almost instantly by repeatedly doubling, much as RSA uses repeated squaring. Going backwards is the hard part: given G and the result, find k. This is the elliptic-curve discrete logarithm problem, and on well-chosen curves the best known attacks need roughly the square root of the number of possibilities, about 2 to the power 128 steps for a 256-bit curve.
That asymmetry is the whole key pair:
- the private key is a random 256-bit number k;
- the public key is the point k × G.
Think of an enormous clock face with points instead of hours. Jumping k steps from G is quick with doubling tricks, but seeing where you landed tells you nothing useful about how many jumps you made.
Why smaller keys are enough
The difference comes from the attacks. RSA's hard problem, factoring, has sub-exponential algorithms such as the general number field sieve, so RSA keys must grow sharply for each extra bit of security. The best general attacks on well-chosen elliptic curves are exponential, so a curve only needs to be about twice as many bits as the security you want. NIST's key-management guidance puts the equivalence like this (NIST SP 800-57):
| Security strength | Elliptic-curve key | RSA key | Symmetric equivalent |
|---|---|---|---|
| 112 bits | 224 to 255 bits | 2,048 bits | 3DES (retired) |
| 128 bits | 256 to 383 bits | 3,072 bits | AES-128 |
| 192 bits | 384 to 511 bits | 7,680 bits | AES-192 |
| 256 bits | 512 bits or more | 15,360 bits | AES-256 |
Smaller keys mean smaller certificates and handshakes, faster key generation and signing, and less work for phones, all at the same level of security. That is the improvement ECC brings.
ECDH, ECDSA and EdDSA
ECDH: agreeing on a key
In elliptic-curve Diffie-Hellman, each side multiplies the other's public point by its own private number. Both arrive at the same shared point, which is turned into symmetric keys, while an eavesdropper who sees only the public points can't. X25519, defined in RFC 7748, is a widely used version, with 32-byte keys. TLS 1.3 uses fresh (ephemeral) ECDH keys for every connection, which gives forward secrecy. Our explainer on Diffie-Hellman key exchange shows the idea with small numbers.
ECDSA: signatures on NIST curves
ECDSA signs with the private key and verifies with the public key, usually on the P-256 curve. It has one sharp edge: every signature needs a fresh secret random number. RFC 6979 warns that even slight biases in generating it can be turned into attacks, and reusing it outright reveals the private key. RFC 6979's fix is deterministic ECDSA, which derives that number from the private key and the message (RFC 6979).
EdDSA and Ed25519
Ed25519, defined in RFC 8032, was designed to avoid ECDSA's pitfalls. Its signatures are deterministic, so they don't depend on a good random number at signing time, it is built to resist timing side channels, and it has 32-byte public keys and 64-byte signatures (RFC 8032). NIST approved EdDSA in its signature standard, FIPS 186-5, in 2023.
So what is "ECC encryption"?
Elliptic curves don't encrypt files or messages directly. Schemes described as ECC encryption, such as ECIES, are hybrids: the sender does an ECDH exchange with the recipient's public key to derive a one-time symmetric key, then encrypts the data with AES-GCM or a similar cipher. The curve protects the key, and the symmetric cipher protects the data, as in every design covered in symmetric vs asymmetric encryption.
Curve choices: P-256, X25519 and Ed25519
| Curve | Defined in | Used for | Where you meet it |
|---|---|---|---|
| P-256 (also called secp256r1 or prime256v1) | NIST standards | ECDH and ECDSA | Mandatory in TLS 1.3; Apple's Secure Enclave stores P-256 keys; Android app signing; ECDSA-256 signed URLs on Amazon CloudFront |
| X25519 | RFC 7748 | Key exchange only | Recommended in TLS 1.3; combined with ML-KEM in the hybrid post-quantum key exchange Chrome uses by default |
| Ed25519 | RFC 8032 | Signatures only | SSH keys, software and package signing; approved in FIPS 186-5 |
| P-384 | NIST standards | ECDH and ECDSA at 192-bit strength | Government and high-assurance systems |
A reasonable default for new designs is X25519 for key exchange and Ed25519 for signatures, with P-256 where a standard, a hardware keystore or a compliance rule requires NIST curves.
ECC vs RSA side by side
The speed figures below come from one Apple M3 Max laptop running OpenSSL 3.6 on a single core (September 2026). They are for comparison only and will differ on other machines.
| Aspect | ECC (P-256 or Curve25519) | RSA |
|---|---|---|
| Hard problem | Elliptic-curve discrete logarithm | Factoring |
| Key size for 128-bit security | 256 bits | 3,072 bits |
| Public key | 32 bytes (X25519, Ed25519); 33 or 65 bytes (P-256) | 384 bytes (RSA-3072) |
| Signature | 64 bytes | 384 bytes (RSA-3072); 256 bytes (RSA-2048) |
| Signatures per second | About 72,500 (ECDSA P-256) | About 790 (RSA-3072); about 2,250 (RSA-2048) |
| Verifications per second | About 25,000 (ECDSA P-256) | About 40,000 (RSA-3072); about 87,000 (RSA-2048) |
| Key generation | Almost instant | Tens to hundreds of milliseconds |
| Randomness at signing time | Critical for ECDSA; not needed for Ed25519 | Less fragile |
| Encrypting data directly | No; ECDH plus a symmetric cipher | Possible for tiny inputs, rarely done |
| Large quantum computer | Broken | Broken |
The lopsided speeds explain real deployments. RSA verification is very cheap, so RSA certificates cost browsers little to check. ECC signing is far faster at equal strength (in this test, ECDSA P-256 signed about 90 times faster than RSA-3072), which matters to a server completing thousands of handshakes a second, or a phone signing requests on battery. For how RSA itself works, see RSA encryption.
Quantum computers and ECC
Shor's algorithm breaks elliptic-curve cryptography as well as RSA. A 2017 study by Roetteler, Naehrig, Svore and Lauter estimated that a 256-bit curve could be attacked with at most about 2,330 error-corrected (logical) qubits, and concluded that ECC is an easier quantum target than RSA of comparable classical strength (arXiv). No such machine exists yet, but data recorded now could be decrypted later.
NIST's draft transition plan proposes deprecating 112-bit elliptic-curve and RSA schemes after 2030 and disallowing ECDSA, EdDSA and ECDH altogether after 2035. The migration has started with key exchange, where browsers now combine X25519 with ML-KEM, so a connection stays safe as long as either holds. Signatures will follow with ML-DSA. Our guide to post-quantum cryptography covers the timeline.
Where ECC meets a course app
- Every HTTPS request from a student's app to your LMS or CDN begins with an elliptic-curve key exchange.
- Device-bound keys. An app can create a P-256 key inside the phone's secure hardware, where it can't be exported, and sign its login or playback requests with it. A copied session token then isn't enough on another phone, which helps with stopping account sharing.
- Signing. App releases, signed video URLs and API tokens (ES256) can all use ECDSA, with smaller signatures than RSA.
Key takeaways
- ECC is asymmetric cryptography based on elliptic curves, giving RSA-level security with keys about a tenth of the size or less.
- It is used for key exchange (ECDH, X25519) and signatures (ECDSA, Ed25519), not for encrypting data directly.
- ECC signs far faster than RSA; RSA verifies faster.
- ECDSA needs a perfect random number for every signature; Ed25519 and deterministic ECDSA remove that risk.
- Quantum computers threaten ECC and RSA alike, and hybrid post-quantum key exchange is already in browsers.
Frequently asked questions
Is ECC symmetric or asymmetric?
ECC is asymmetric. Each party has a private key, a random number, and a public key, a point on the curve derived from it. The public key can be shared freely, while only the private-key holder can sign or complete a key exchange as that party. ECC is typically used to set up a shared symmetric key, and a symmetric cipher such as AES then encrypts the actual data.
What is elliptic curve cryptography used for?
ECC is used mainly for key exchange and digital signatures. HTTPS uses elliptic-curve Diffie-Hellman (often X25519 or P-256) at the start of almost every connection, and ECDSA or Ed25519 to sign certificates, apps, software packages, SSH logins and API tokens. Phones also keep elliptic-curve keys in secure hardware to prove device identity. Encryption of files and video is left to symmetric ciphers.
What improvement does elliptic curve cryptography make?
ECC provides the same security as RSA with much smaller keys: 256 bits instead of 3,072 for 128-bit security. That means smaller certificates and signatures, faster key generation, much faster signing and less data in every handshake, which helps phones and busy servers alike. Modern curves such as X25519 and Ed25519 were also designed to be easier to implement safely, with resistance to timing attacks.
Is ECC more secure than RSA?
At equal security levels, neither is more secure against today's computers: a 256-bit curve and 3,072-bit RSA are both rated at 128 bits. ECC achieves it more efficiently, and modern curves reduce implementation mistakes, although ECDSA is unforgiving about signing randomness. Against a future quantum computer both would fall, and published estimates suggest ECC might fall first, which is why both are being replaced by post-quantum algorithms.