Cryptography Explained
RSA vs ECC vs Post-Quantum: What Your TLS Certificates Reveal About Quantum Risk
Why RSA and ECC TLS certificates are both quantum-vulnerable, how NIST PQC standards (ML-KEM/ML-DSA/SLH-DSA) compare, and how to read your own.
RSA vs ECC vs Post-Quantum: What Your TLS Certificates Reveal About Quantum Risk
Almost every public TLS certificate on the internet today is keyed and signed with one of two algorithms: RSA or ECC. Both are battle-tested over decades — and both are broken by Shor's algorithm once a cryptographically relevant quantum computer (CRQC) exists. The Global Risk Institute's 2025 expert survey puts the median CRQC estimate around 2029–2032, with roughly a 34% probability by 2030. That makes the algorithm names buried in your certificates a direct readout of your quantum exposure.
This post explains what RSA and ECC are, why bigger keys don't save them, what the NIST post-quantum standards replace them with, and how to read the hybrid post-quantum TLS already shipping in your browser. The practical takeaway: the first move in any migration is knowing which algorithms your certificates use — something an external scan reveals in minutes.
RSA: the workhorse of public-key crypto
RSA (Rivest–Shamir–Adleman) is the algorithm most people picture when they think "encryption." Its security rests on a simple fact: multiplying two large prime numbers is easy, but factoring the resulting product back into those primes is hard for a classical computer. A 2048-bit RSA key would take a conventional machine far longer than the age of the universe to factor by brute force.
RSA authenticates servers (the signature on a TLS certificate) and historically exchanged session keys. It's everywhere — web servers, email, code signing, VPNs, document signatures. When you see a certificate with a 2048-bit or 4096-bit key, that's RSA.
The catch: factoring is only hard for classical computers. Shor's algorithm, designed to run on a quantum computer, solves integer factorization in polynomial time. A sufficiently large CRQC doesn't grind through RSA — it sidesteps the hard problem entirely.
ECC: smaller keys, same fatal weakness
Elliptic Curve Cryptography (ECC) does the same jobs as RSA — key exchange and signatures — but uses the mathematics of elliptic curves instead of prime factorization. Its security rests on the elliptic-curve discrete logarithm problem, which is even harder per bit than factoring. That efficiency is why ECC won so much ground: a 256-bit ECC key (curves like P-256 or Curve25519) offers security roughly comparable to a 3072-bit RSA key, with smaller certificates and faster handshakes. Modern certificates increasingly use ECDSA signatures and X25519 key exchange for this reason.
Here's the part that trips people up: ECC is not a quantum-safe upgrade over RSA. Shor's algorithm solves the discrete logarithm problem just as efficiently as it solves factoring, so a CRQC breaks ECC and RSA alike. Choosing elliptic curves over RSA is a performance decision, not a quantum-readiness one.
Why "just use a bigger key" doesn't work
The instinct to answer a cryptographic threat by doubling the key size is reasonable — it's worked before. Against quantum attacks on RSA and ECC, it doesn't.
Shor's algorithm scales polynomially with key size, not exponentially. Classical attackers face exponential cost as keys grow, which is what makes 2048-bit RSA safe today; a quantum attacker running Shor's does not. Doubling an RSA key from 2048 to 4096 bits, or moving from a 256-bit to a 521-bit curve, makes the quantum attack modestly more expensive — but does not move the problem out of reach. There is no key size at which RSA or ECC becomes quantum-resistant. The math itself is the vulnerability, so the only durable fix is different math.
Post-quantum cryptography: new math, new standards
Post-quantum cryptography (PQC) replaces the factoring- and discrete-log-based algorithms with problems that have no known efficient solution on either classical or quantum computers — primarily structured-lattice and hash-based problems. On August 13, 2024, NIST finalized the first three standards:
- FIPS 203 — ML-KEM (Module-Lattice Key-Encapsulation Mechanism, derived from Kyber). This is the replacement for RSA and ECC key exchange — establishing the shared session key that protects a TLS connection.
- FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm, derived from Dilithium). The primary post-quantum signature standard — the replacement for RSA and ECDSA signatures on certificates.
- FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, derived from SPHINCS+). A second, hash-based signature standard whose security rests on different assumptions, valuable as a conservative backup to lattice signatures.
The work continues: FIPS 206 (FN-DSA, derived from Falcon) is in progress in 2026, and NIST selected HQC in March 2025 as a backup key-encapsulation mechanism built on different mathematics from ML-KEM. The diversification is deliberate — relying on a single assumption is precisely what PQC is meant to escape.
RSA vs ECC vs PQC: the comparison
| | RSA | ECC | Post-Quantum (PQC) | |---|---|---|---| | How it works | Hard to factor the product of two large primes | Hard to solve the elliptic-curve discrete logarithm | Hard lattice problems (ML-KEM, ML-DSA) and hash-based constructions (SLH-DSA) | | Quantum-vulnerable? | Yes — broken by Shor's algorithm on a CRQC | Yes — broken by Shor's algorithm on a CRQC | No known efficient quantum attack; the basis for the NIST standards | | Where used | TLS certificate signatures, key exchange, code signing, email | TLS certificate signatures (ECDSA), key exchange (X25519/P-256), faster handshakes | FIPS 203 (key exchange), FIPS 204 + FIPS 205 (signatures); rolling out in TLS, VPNs, signing | | Migration note | Larger keys do not fix it — plan to replace | More efficient than RSA but equally quantum-vulnerable — not an upgrade | The destination — adopt via crypto-agility, often hybrid first |
The pattern is clear: RSA and ECC sit in the same "quantum-vulnerable" column for the same underlying reason, while the PQC standards are the genuine replacements. This is why a cryptographic inventory that flags RSA and ECC as hidden quantum risk is the natural starting point — you can't replace algorithms you haven't located.
See where your organization stands — run a free CipherReady readiness scan and get a cryptographic inventory of your public TLS, certificates, and algorithms in about 3 minutes.
Hybrid post-quantum TLS is already in your browser
You don't have to wait for a CRQC to see PQC in action — it's live in production today. The dominant approach is hybrid key exchange: combine a classical algorithm with a post-quantum one so the connection stays at least as secure as the strongest of the two. The hybrid you'll encounter most is X25519MLKEM768, which pairs the classical X25519 elliptic-curve exchange with FIPS 203's ML-KEM at the 768 parameter level.
The rollout is well underway:
- Chrome 131 enabled hybrid X25519MLKEM768 by default in November 2024.
- Firefox 135 followed in February 2025.
- OpenSSL 3.5.0 added support in April 2025.
- Apple operating systems (the v26 generation) support the hybrid as well.
The result is measurable. Cloudflare reported that by March 2025, roughly 38% of human-initiated HTTPS traffic already used hybrid post-quantum key exchange. The hybrid design directly answers the "harvest now, decrypt later" (HNDL) threat: even if an adversary records this traffic today and obtains a CRQC years from now, the ML-KEM component must also be broken to recover the session — and it isn't vulnerable to Shor's.
One nuance: this hybrid protects key exchange (the confidentiality of the session), not the signature on the certificate. Post-quantum certificate signatures (ML-DSA, SLH-DSA) are a separate, less mature track. So even on a connection negotiating X25519MLKEM768, the certificate authenticating the server is almost certainly still RSA or ECC. Knowing that difference is what separates a real migration plan from a checkbox.
From algorithm names to a migration plan
Mosca's theorem frames the urgency without hyperbole: if your data's shelf-life (Y) plus the time you need to migrate (X) is greater than the time until a CRQC arrives (Z), you are already exposed. For long-lived data — health records, financial archives, government and IP secrets — that inequality is uncomfortable today, even with the CRQC still years out. To be clear, no quantum computer has broken RSA or ECC. Google's Willow processor reached below-threshold error correction in 2025 — an important milestone, but not a break. The honest posture is "not yet, but prepare now."
Regulators have adopted the same stance. PCI DSS 4.0 Requirement 12.3.3 (in effect from March 31, 2025) mandates a documented cryptographic inventory plus a migration plan for deprecated algorithms. DORA (effective January 17, 2025) requires crypto-agility for financial entities, and NIS2 pushes "state-of-the-art" encryption with readiness to upgrade. The NSA's CNSA 2.0 timeline sets a 2033 exclusive-use target for browsers, servers, and cloud.
Every one of these mandates begins in the same place: an inventory. You cannot adopt crypto-agility — the ability to swap algorithms without re-architecting — until you know what you're running, and you can't build a cryptographic bill of materials (CBOM) without first discovering your certificates and their key algorithms. For what the new standards require, see our explainer on the NIST PQC standards FIPS 203, 204, and 205.
The first step is also the most concrete: an external, metadata-only scan of the domains you own can enumerate your public TLS certificates, the public-key algorithms behind them (RSA or ECC), your TLS versions, and your security headers — turning abstract "quantum risk" into a specific, prioritized list. That's where CipherReady comes in.
Frequently Asked Questions
Is ECC safer than RSA against quantum attacks?
No. ECC is more efficient than RSA and harder to break with classical computers at equivalent key sizes, but against a quantum attacker both fall to Shor's algorithm. ECC solves the elliptic-curve discrete logarithm problem and RSA relies on integer factorization — Shor's defeats both in polynomial time. Choosing ECC over RSA is a performance decision, not a quantum-readiness one.
Can't we just use larger RSA or ECC keys to stay safe?
No. Shor's algorithm scales polynomially with key size rather than exponentially, so doubling a key only modestly raises the cost of a quantum attack without putting it out of reach. There is no key size at which RSA or ECC becomes quantum-resistant. The durable fix is to migrate to the post-quantum standards — ML-KEM (FIPS 203) for key exchange and ML-DSA (FIPS 204) or SLH-DSA (FIPS 205) for signatures.
What is X25519MLKEM768 and is it already in use?
It's a hybrid TLS key-exchange method that combines the classical X25519 elliptic-curve exchange with the post-quantum ML-KEM (FIPS 203) at the 768 parameter level, so a connection stays secure as long as either component holds. It's enabled by default in Chrome 131 (November 2024) and Firefox 135 (February 2025), supported in OpenSSL 3.5.0 and recent Apple operating systems. Cloudflare measured roughly 38% of human HTTPS traffic using hybrid PQC by March 2025. Note that it protects key exchange, not the certificate's signature.
How do I find out which algorithms my certificates actually use?
The reliable way is to inventory them. A safe, external, metadata-only scan can enumerate your public TLS certificates and identify whether each uses an RSA or ECC public key, along with your TLS versions and security headers — without credentials or intrusive testing. CipherReady produces exactly this inventory plus a readiness score and an executive report, so you can see your quantum-vulnerable algorithms before planning a migration.
See your certificates' quantum exposure today
You can't migrate what you can't see, and the most useful starting fact is which algorithms your certificates actually use. CipherReady runs a safe, external, metadata-only readiness scan of the domains you own — inventorying your public TLS certificates, TLS versions, DNS exposure, RSA/ECC public-key algorithms, and HTTP security headers — then delivers a CipherReady Readiness Score, an executive PDF report, AI-assisted summaries, and scheduled monitoring.
Run your free CipherReady readiness scan (3 scans a month on the free plan) and turn abstract quantum risk into a concrete inventory. When you're ready to expand coverage across your environment, explore the options on our pricing page. CipherReady is the first step — visibility into your cryptography — so your post-quantum migration starts from facts, not guesswork.