RSA and ECC are both public-key cryptosystems — each gives you a key pair where the public half can be shared freely and the private half never has to leave your machine — but they get there through two unrelated hard math problems. RSA leans on how hard it is to factor the product of two huge primes; ECC leans on how hard it is to reverse a specific kind of multiplication on an elliptic curve. The practical difference isn't philosophical: an ECC key at 256 bits is roughly as hard to break as an RSA key at 3072 bits, while being smaller, faster to generate, and cheaper to use on every handshake. That's why TLS, SSH, and JWT signing have all been quietly defaulting to ECC for the better part of a decade, and why RSA is turning into the "still works everywhere" option rather than the first choice.
The problem both of them solve
Symmetric ciphers like AES are fast and simple, but they share one requirement that's hard to satisfy at scale: both sides need the same secret key before they can talk, and getting that key from one side to the other securely is its own unsolved problem — you can't just email it. Public-key cryptography sidesteps this with a trapdoor function: a calculation that's cheap to run forward but computationally infeasible to run backward without a piece of extra information (the private key). Anyone can use your public key to encrypt a message or verify a signature; only the private key can decrypt it or produce a signature that verifies. No secret ever crosses the wire.
RSA and ECC are the two trapdoor functions that won. Both give you that same shape of key pair; they just pick a different problem to be hard.
Two different hard problems
RSA's trapdoor is integer factorization. Multiplying two large prime numbers is trivial; given only the product, finding the original primes back out is not — there's no known efficient classical algorithm for it, and the best-known methods (the general number field sieve) scale so badly that doubling the key size doesn't just double the work, it multiplies it many times over. RSA's public and private keys are built from that product and its factors; encryption and signature verification use the public exponent, decryption and signing use a private exponent derived from the factorization.
ECC's trapdoor is the elliptic curve discrete logarithm problem (ECDLP). Pick a fixed point on a curve and "multiply" it by a private integer k using a repeated point-addition rule — that's cheap. Given only the fixed point and the result, recovering k is not, and unlike factoring, no sub-exponential attack is known against a well-chosen curve. That's the whole reason ECC keys can be so much smaller for the same security margin: the best attack against ECDLP is still roughly the brute-force square-root method (Pollard's rho), while RSA's best attack is dramatically faster than brute force.
Key size, side by side
The apples-to-apples comparison isn't "RSA-2048 vs ECC-256" as raw numbers — it's how much brute-force work each one takes to break, expressed as an equivalent symmetric key strength. NIST's key-management guidance (SP 800-57) publishes exactly this table:
| Symmetric-equivalent strength | RSA key size | ECC key size |
|---|---|---|
| 112-bit | 2048-bit | 224-bit |
| 128-bit | 3072-bit | 256-bit |
| 192-bit | 7680-bit | 384-bit |
| 256-bit | 15360-bit | 521-bit |
Read the bottom row again: matching AES-256's strength takes a 15360-bit RSA key — big enough that almost nobody actually generates one — versus a 521-bit ECC key, which a browser can generate in milliseconds. That gap is also why RSA key sizes keep getting recommended upward (2048-bit is this decade's floor, not last decade's) while ECC has stayed at 256/384-bit for ordinary use since Suite B was published in 2005: the underlying problem doesn't erode the same way as factoring does against better algorithms and more compute.
Why the industry moved
Smaller keys mean less to send on every TLS handshake, less CPU spent on every signature, and less battery drained on every mobile connection — multiplied across billions of requests a day, that's real infrastructure cost. A few concrete data points:
- ECDSA signature verification is typically 4-10x faster than RSA verification at equivalent security levels, and ECDSA key generation is dramatically faster than RSA key generation (RSA has to find two large primes and verify they're prime; ECC just needs a random integer).
- TLS 1.3 (RFC 8446) dropped static RSA key exchange entirely — every cipher suite now requires (EC)DHE for forward secrecy, and ECDHE is the common case because it's cheap enough to do on every single connection.
- OpenSSH has defaulted
ssh-keygen's recommendation toward Ed25519 rather than RSA for new keys, and Ed25519 keys have been fully supported since OpenSSH 6.5 (2014). - Signal, WireGuard, and most modern VPN and messaging protocols are built on Curve25519 (X25519 for key exchange, Ed25519 for signatures) specifically because it's fast enough to do per-message without users noticing.
RSA hasn't gone anywhere — it's still what most PGP keys, most legacy TLS certificates, and a large share of enterprise PKI run on — but "smaller, faster, and at least as secure" is a hard combination to argue against for anything new.
Where each one actually shows up
| System | What it typically uses today |
|---|---|
| TLS certificates | RSA-2048 still common; ECDSA (P-256) increasingly the default for new issuance — see our SSL/TLS certificate breakdown |
| SSH host/user keys | Ed25519 as the modern default, RSA-4096 for legacy compatibility — covered in depth in our SSH key types and SSH config posts |
| JWT signing | RS256 (RSA + SHA-256) and ES256 (ECDSA P-256 + SHA-256) for asymmetric signing, EdDSA for Ed25519 — distinct from the HS256 HMAC family covered in our webhook HMAC piece |
| PGP / code signing | RSA-4096 historically dominant; Curve25519 now the default OpenPGP.js and current GnuPG recommend |
| Cryptocurrency wallets | ECDSA over secp256k1 for Bitcoin and Ethereum — the same public-key math, a different curve than TLS's P-256, sitting downstream of the seed phrase in our BIP-39 article |
If you need to actually generate a key pair rather than just read about them, our RSA Key Generator and ECDSA / Ed25519 Key Generator both run entirely in your browser — nothing you generate is ever transmitted anywhere.
Common mistakes
Assuming JWT's alg header can be trusted blindly
In 2015, security researcher Tim McLean disclosed a class of vulnerability in libraries that verify JWTs: a server configured to verify RS256 tokens using an RSA public key can sometimes be tricked into treating that same public key as an HS256 HMAC secret instead — because an attacker who knows the public key (which, by design, isn't secret) can forge an HMAC-signed token that the library accepts as if it were RSA-signed. The fix isn't a smarter JWT format; it's that a verifier must pin the expected algorithm itself and reject anything else, never read alg off the token and trust it. It's exactly why our JWT Encoder always overwrites the alg claim to match the algorithm you actually selected — a token's header claim should never be allowed to disagree with how it was really signed.
Reusing an ECDSA nonce
ECDSA signing needs a fresh, unpredictable random value (k, the nonce) for every single signature. Reuse the same k across two different messages signed with the same key, and simple algebra recovers the private key outright — no factoring, no brute force, just two equations and one unknown. This isn't theoretical: it's the exact bug that let researchers extract Sony's PS3 signing key in 2010 (a fixed k instead of a random one), and the same class of bug has repeatedly leaked private keys from cryptocurrency wallets with weak or predictable random number generators. RFC 6979 exists specifically to remove this footgun by deriving k deterministically from the message and private key instead of relying on a random source at all.
Treating "ECC is smaller" as "ECC is weaker"
The intuition that a 256-bit key must be less secure than a 2048-bit key is backwards here — it's comparing key size across two different math problems with wildly different attack costs, not comparing two instances of the same problem. A 256-bit ECC key and a 3072-bit RSA key sit at roughly the same security level; the ECC key is just smaller because ECDLP doesn't have a sub-exponential attack the way factoring does.
Calling either one "quantum-safe"
Neither is. Shor's algorithm, run on a sufficiently large fault-tolerant quantum computer, breaks both integer factorization and the elliptic curve discrete log problem in polynomial time — RSA and ECC fall to the same theoretical attack, just at different key sizes needed to demonstrate it. That's the entire reason NIST ran a multi-year post-quantum cryptography competition and standardized lattice-based algorithms like ML-KEM and ML-DSA in 2024: neither RSA nor ECC scaling up key sizes further will help once large quantum computers exist. Today's systems are secure against every attacker without one, which is still what matters for anything you're deploying now.
FAQ
Can I convert an RSA key into an ECC key, or vice versa?
No. They're not two encodings of the same underlying secret — they're built on entirely different math, so there's no conversion. Migrating means generating a brand-new ECC key pair and reissuing certificates, re-adding SSH keys, or re-registering signing keys against it, then retiring the old RSA key once every consumer has switched over.
Which curve should I actually pick for a new ECC key?
Ed25519 for anything that doesn't have to interoperate with an older system that only understands NIST curves — it's faster, has no history of nonce-reuse footguns thanks to deterministic signing, and is what modern SSH, PGP, and messaging protocols default to. Reach for P-256 (ES256) specifically when a spec or library requires it, which is common in JWT and X.509 tooling.
Does RSA vs ECC affect encryption, signing, or both?
Both, but not in the same package. RSA does encryption and signing with the same key pair (different padding schemes for each). Ed25519 is signing-only — you'd use X25519, its Diffie-Hellman counterpart on the same underlying curve, for key exchange instead. That split is one more reason "just use Ed25519 for everything" isn't always literally true depending on what the system needs.
Is a 2048-bit RSA key still safe to use today?
Yes, for now — it's the floor most standards and CAs still accept, and no practical attack breaks it. But it's a floor with a shrinking margin: NIST's own guidance has RSA-2048 phasing toward deprecated status later this decade for federal use, which is a signal worth taking seriously if you're setting a policy for new systems rather than just keeping something already deployed.
Cover photo via Pexels.