Every HTTPS connection you open, every SSH session you start, and every VPN tunnel your laptop builds has to solve the same problem first: two strangers need to agree on a secret number without anyone eavesdropping being able to guess it. For three decades, the cryptography world has answered that question two different ways. RSA wraps a secret in a lockbox that only the server’s private key can open. Diffie-Hellman skips the lockbox entirely and lets both sides compute the same secret independently, in public view, without ever sending it across the wire.
By September 2026, that choice has mostly already been made for you. TLS 1.3 dropped static RSA key exchange outright, and the elliptic-curve cousin of Diffie-Hellman (ECDHE) now handles the overwhelming majority of secure web traffic. But classic finite-field Diffie-Hellman (DHE) still shows up in SSH, in older VPN gateways, and in TLS 1.3 itself as the FFDHE group family defined in RFC 7919. Understanding why RSA lost the key-exchange job, why plain DHE is quietly fading too, and where each algorithm still earns its keep is the difference between a config that merely works and one that survives an audit.
What RSA and Diffie-Hellman Actually Do
RSA and Diffie-Hellman solve the same problem through opposite mechanisms, and that difference explains nearly every performance and security tradeoff discussed below.
RSA key transport works like a locked box. The client generates a random session key, encrypts it with the server’s RSA public key, and sends the ciphertext over. Only the holder of the matching RSA private key can decrypt it and recover the session key. It is fast to set up conceptually, but it has one structural flaw: if that private key is ever stolen, an attacker who recorded the handshake years earlier can decrypt every session that ever used it. There is no way around this with static RSA key transport, because the same long-term key both authenticates the server and wraps the secret.
Diffie-Hellman works differently. Each side generates a private exponent, computes a public value from it, and swaps public values in the clear. Both sides then run the same math on the other party’s public value and their own private exponent, landing on an identical shared secret that never crossed the network. Classic finite-field DH does this inside a large prime-order group (the “MODP” groups defined in RFC 3526 and RFC 7919). Its elliptic-curve sibling, ECDH, does the same trick on an elliptic curve instead, which is why ECDHE dominates modern TLS while plain DHE has become the quieter, legacy option.
The forward-secrecy property is where DH pulls ahead structurally. Because a fresh DH exponent gets generated for every session (hence “ephemeral,” or DHE/ECDHE), stealing the server’s long-term signing key later does not unlock past sessions. Static RSA key transport offers no such guarantee. That single distinction is why TLS 1.3 eliminated static RSA key exchange entirely and requires (EC)DHE for every handshake, per RFC 8446.
RSA vs Diffie-Hellman: Specs Comparison Table
| Attribute | RSA (key transport) | Finite-field Diffie-Hellman (DHE) |
|---|---|---|
| Core mechanism | Public-key encryption of a session secret | Independent computation of a shared secret |
| Forward secrecy | None (static key transport) | Yes, when ephemeral keys are used per session |
| TLS 1.3 support | Removed entirely (RFC 8446) | Supported via FFDHE groups (RFC 7919), rarely selected |
| TLS 1.2 status | Disabled by default on most modern stacks | Available as DHE_RSA / DHE_DSS cipher suites |
| Security at 2048-bit | ~112-bit (NIST SP 800-57) | ~112-bit (NIST SP 800-57, FFDHE2048) |
| Security at 3072-bit | ~128-bit | ~128-bit (FFDHE3072) |
| Typical key/parameter size on wire | 256-512 bytes (2048-4096 bit modulus) | 256-512 bytes (2048-4096 bit MODP group) |
| Known historic weakness | Bleichenbacher padding oracle (PKCS#1 v1.5) | Logjam (2015): downgrade to weak/shared groups |
| SSH usage | Host authentication (RSA/Ed25519 keys) | Key exchange (diffie-hellman-group14-sha256, legacy) |
| Modern SSH default | Ed25519 preferred for host keys | curve25519-sha256 (ECDH) preferred over group14 |
| Quantum resistance | None, broken by Shor’s algorithm | None, broken by Shor’s algorithm |
| Client-side compute cost | Very low (public-exponent encryption) | Moderate (modular exponentiation) |
| Server-side compute cost | High for decryption at large key sizes | High for key generation, scales with group size |
| Standardization | PKCS#1, NIST SP 800-56B | RFC 7919 (FFDHE), NIST SP 800-56A |
Performance Benchmarks: RSA-2048/3072/4096 vs DHE-2048/3072/4096
The performance story is asymmetric in a way that matters for real deployments. RSA’s public operation, encryption with a small exponent like 65537, is cheap. Its private operation, decryption, gets expensive fast as key size grows. DH does not have that asymmetry: both sides do roughly the same amount of modular exponentiation, and that cost climbs steeply with group size on both ends.
Benchmark data compiled from cryptographic library testing shows RSA-2048 handling on the order of 30,000 verify/encrypt operations per second on modern server hardware, dropping to roughly 15,000 ops/sec at RSA-3072 and around 9,000 ops/sec at RSA-4096. Private-key operations tell a starker story: RSA-2048 decryption runs at roughly 1,000 ops/sec, RSA-3072 drops to about 350 ops/sec, and RSA-4096 falls to around 150 ops/sec on the same class of hardware. That’s a 6-7x drop in private-key throughput moving from 2048 to 4096 bits.
Finite-field DHE scales even less gracefully. Benchmark figures for FFDHE groups put DHE-2048 key generation and key agreement at roughly 2 milliseconds each, adding up to about 4ms of handshake overhead and supporting on the order of 250 handshakes per second per core. Push the group up to DHE-4096 and key generation and agreement each climb to roughly 15ms, cutting throughput to about 33 handshakes per second per core, nearly an 8x drop in capacity for double the key size.
Older Apache-era TLS benchmarking found RSA key exchange at 1024-bit running over 3.4x faster than DHE at the same 1024-bit group size, which is part of why RSA key transport survived as long as it did before forward secrecy concerns forced it out. That same body of testing found that ECDHE with 256-bit curves delivers forward secrecy at roughly the security level of 3072-bit DHE while adding only about 26% more CPU overhead than pure RSA at 3072 bits, a gap small enough that server operators stopped treating “DHE is slow” as an excuse to skip forward secrecy altogether. For comparison, X25519 (ECDH) benchmarks at roughly 20x the throughput of DHE-2048 and around 150x the throughput of DHE-4096, with parameter sizes of just 32 bytes versus 256-512 bytes for finite-field groups. That gap is the entire reason ECDHE, not DHE, became the TLS 1.3 default.
| Operation | RSA-2048 | RSA-3072 | RSA-4096 | DHE-2048 | DHE-4096 |
|---|---|---|---|---|---|
| Key generation | ~5 keys/sec | ~1-2 keys/sec | ~0.2 keys/sec | ~2 ms/op | ~15 ms/op |
| Public/verify or key agreement | ~30,000 ops/sec | ~15,000 ops/sec | ~9,000 ops/sec | ~2 ms/op | ~15 ms/op |
| Private/decrypt | ~1,000 ops/sec | ~350 ops/sec | ~150 ops/sec | n/a (symmetric cost) | n/a (symmetric cost) |
| Handshakes/sec/core (approx.) | higher (fast public op) | moderate | lower | ~250 | ~33 |
| Wire parameter size | 256 bytes | 384 bytes | 512 bytes | 256 bytes | 512 bytes |
These figures come from cryptographic library benchmarking and VPN/TLS performance studies. Exact numbers vary by CPU, library (OpenSSL vs BoringSSL vs LibreSSL), and whether hardware acceleration for modular exponentiation is present. Treat them as directional, not as a guarantee for any specific deployment.
The Logjam Attack and Why It Still Shapes DH Deployments
In May 2015, a team of researchers published the Logjam attack, showing that TLS servers still offering “export-grade” 512-bit Diffie-Hellman groups, a relic of 1990s US export restrictions on cryptography, could be forced into using those weak groups through an active downgrade attack. Once downgraded, a well-resourced attacker with enough precomputed data could break the session key in near-real time. The researchers also showed that many servers reused a small number of standard 1024-bit DH groups, and precomputation against those shared groups was plausible for a state-level adversary, a scenario the paper explicitly connected to NSA capability estimates at the time.
The practical fallout reshaped how the industry handles finite-field DH a decade later. Browsers stopped accepting export-grade and sub-1024-bit DH groups. Server operators were pushed toward either dropping DHE for ECDHE outright or, if they kept DHE, moving to unique, sufficiently large groups rather than the shared 1024-bit defaults that made precomputation attractive. That’s part of why RFC 7919 standardized named FFDHE groups starting at 2048 bits: it gave server operators a well-vetted alternative to hand-rolled or reused DH parameters, closing off the exact class of weakness Logjam exploited.
Logjam’s legacy is really a lesson about protocol downgrade attacks more broadly, not just about DH group size. The same active-attacker downgrade pattern shows up in other TLS weaknesses from that era, and it’s part of why TLS 1.3’s handshake was redesigned to make version and parameter downgrades cryptographically detectable rather than something a man-in-the-middle can quietly force.
TLS 1.3 Cipher Suite Reality in 2026
TLS 1.3, formalized in RFC 8446, made a decision that ends most of this debate for new deployments: static RSA key transport is not an option at all. Every TLS 1.3 handshake uses (EC)DHE for key agreement. RSA’s remaining role is limited to signing the handshake for authentication, not encrypting a session key. The cipher suite names themselves (TLS_AES_128_GCM_SHA256, TLS_CHACHA20_POLY1305_SHA256, and similar) no longer even encode the key-exchange method, because there is effectively only one family left: ephemeral Diffie-Hellman, almost always on an elliptic curve.
SSL Labs telemetry through early 2025 put TLS 1.3 support around 75% among top-tier websites, with SSLv3 fallback support down under 2%. For the TLS 1.2 connections that remain in the wild, ECDHE_RSA and ECDHE_ECDSA cipher suites dominate. Plain DHE_RSA suites are seen mostly on legacy or constrained systems, and pure static RSA key-transport suites are disabled by default on virtually every current server stack, from nginx to Apache to modern load balancers.
Finite-field DHE hasn’t disappeared from TLS 1.3 entirely. RFC 7919’s FFDHE2048 through FFDHE8192 groups are valid, negotiable options. In practice, though, they are rarely chosen: clients and servers alike default to X25519 or P-256 ECDHE because the performance gap (20x to 150x depending on DHE group size, per the benchmark figures above) makes plain DHE a hard sell whenever elliptic curves are available. FFDHE mostly survives as a fallback for environments with policy restrictions on elliptic-curve cryptography.
Key Size to Security Level: How the Math Maps Out
One of the more confusing parts of comparing RSA and Diffie-Hellman is that “bigger key” doesn’t mean the same thing for both. RSA security derives from the difficulty of factoring a large composite number into its prime factors. Finite-field DH security derives from the difficulty of computing a discrete logarithm in a multiplicative group modulo a large prime. These are different math problems, but decades of cryptanalysis have shown they yield to roughly the same computational effort at matched bit lengths, which is why NIST publishes equivalent security-strength tables that treat RSA and finite-field DH moduli as interchangeable at a given bit size.
NIST SP 800-57 Part 1 Revision 5 is the reference document most auditors cite. It maps a 2048-bit RSA modulus and a 2048-bit finite-field DH modulus to roughly 112 bits of classical security, a 3072-bit modulus in either scheme to roughly 128 bits, and a 4096-bit modulus to somewhere north of 150 bits. Elliptic-curve schemes get there with far smaller keys: a 256-bit curve like P-256 or X25519 reaches the same approximate 128-bit security level as 3072-bit RSA or DH, while moving roughly a twelfth of the data on the wire during key exchange. That efficiency gap, not a security difference, is the core reason elliptic-curve variants displaced their finite-field ancestors across nearly every modern protocol.
| Approx. security level | RSA modulus | Finite-field DH modulus (FFDHE) | Elliptic curve (ECDHE) |
|---|---|---|---|
| ~80-bit (deprecated) | 1024-bit | 1024-bit | 160-bit |
| ~112-bit | 2048-bit | 2048-bit (FFDHE2048) | 224-bit |
| ~128-bit | 3072-bit | 3072-bit (FFDHE3072) | 256-bit (P-256, X25519) |
| ~150+ bit | 4096-bit | 4096-bit (FFDHE4096) | 384-bit (P-384) |
Auditors use this table in a specific, practical way: any RSA key or DH group below 2048 bits gets flagged as insufficient for new deployments, since 1024-bit and smaller moduli fall within reach of well-funded attackers using distributed factoring or discrete-log computation. 2048-bit is the accepted floor for compliance frameworks like PCI-DSS and most government guidance through 2026, with 3072-bit increasingly recommended for systems expected to stay in service past the early 2030s.
Common Misconceptions About RSA and Diffie-Hellman
A few misunderstandings about this comparison show up often enough in security reviews to be worth addressing directly.
The first is treating “RSA” and “Diffie-Hellman” as if they’re mutually exclusive in a given deployment. They usually aren’t. The common ECDHE_RSA cipher suite family uses both: RSA signs the handshake to prove server identity, while ECDHE (Diffie-Hellman’s elliptic-curve descendant) handles the actual key agreement. Removing RSA from a TLS configuration’s key-exchange role doesn’t mean removing RSA from the stack entirely. RSA certificates remain extremely common for authentication even on servers that have long since dropped RSA key transport.
The second misconception is assuming a bigger RSA or DH key automatically buys meaningfully better real-world security. Past roughly 3072 bits, the marginal security gain per added bit shrinks while the computational cost grows fast, and neither scheme gains any resistance to quantum attacks no matter how large the key gets. Organizations sometimes jump straight to RSA-4096 assuming it’s a meaningfully safer default than RSA-3072. In practice, the honest answer is that both remain classically secure for the foreseeable future, and the bigger key mostly just costs more CPU per handshake.
The third misconception is treating “supports forward secrecy” as binary rather than as a per-cipher-suite property. A server can support TLS 1.2 with both a forward-secret ECDHE_RSA suite and a non-forward-secret static RSA suite at the same time, and unless an operator has explicitly disabled the weaker option, a downgrade attack (or simply an older client) can still negotiate the non-forward-secret path. Auditing forward secrecy means checking which suites are actually disabled, not just which ones are preferred.
Pricing and Infrastructure Cost Comparison
Neither RSA nor Diffie-Hellman carries a license fee. Both are open, standardized algorithms implemented in free libraries like OpenSSL, BoringSSL, and LibreSSL. The real cost difference is compute, and it shows up as CPU-hours on TLS-terminating infrastructure, not as a line item you’ll find on an invoice.
| Cost factor | RSA key transport / signing | Finite-field DHE | ECDHE (for context) |
|---|---|---|---|
| Software licensing | Free (open standard) | Free (open standard) | Free (open standard) |
| Relative CPU cost per handshake at equivalent security | Low public-op cost, high private-op cost | High, grows steeply with group size | Low, flat-ish across supported curves |
| TLS certificate cost impact | None, cert pricing is independent of algorithm choice | None | None |
| Migration engineering cost | Low if already deprecated in config | Low-medium (config change + testing) | Already default on most modern stacks |
| Hardware acceleration availability | Common (AES-NI-class RSA/modexp acceleration) | Less common, general modexp only | Common on modern CPUs (curve-specific instructions) |
At scale, the difference is meaningful. A CDN or load balancer terminating millions of TLS handshakes per day pays for every extra millisecond of key-exchange compute in server count. That’s the quiet economic argument behind the industry’s wholesale move to ECDHE: it isn’t just a security upgrade, it measurably cuts the CPU budget needed to serve the same handshake volume compared to either RSA key transport at large key sizes or plain DHE at FFDHE3072/4096.
Real-World Deployment Examples
1. Public HTTPS traffic
The overwhelming majority of HTTPS connections in 2026 negotiate ECDHE_RSA or ECDHE_ECDSA: RSA (or increasingly Ed25519/ECDSA) authenticates the server certificate, while X25519 or P-256 ECDHE handles the actual key agreement. Static RSA key transport is effectively extinct on the public web.
2. OpenSSH key exchange
OpenSSH still lists diffie-hellman-group14-sha256 (a 2048-bit FFDHE-style group) as a supported key-exchange method for backward compatibility, but curve25519-sha256 has been the preferred default for new connections for several release cycles, per OpenSSH’s own release documentation. Legacy DH groups mainly persist for interoperability with older network appliances and jump hosts.
3. IPsec/IKE VPN gateways
Enterprise VPN gateways commonly still offer MODP 2048/3072 Diffie-Hellman groups (DH Group 14/15) for IKE phase negotiations, largely because of hardware and firmware that predates widespread curve support. Newer gateway software increasingly defaults to Group 19/20/21 (NIST curves) or Group 31 (X25519) where client compatibility allows.
4. Legacy TLS 1.2 enterprise systems
Internal enterprise systems that haven’t been re-certified for TLS 1.3 sometimes still carry DHE_RSA cipher suites in their configuration for compatibility with older clients. Security audits routinely flag these for removal or for confirming the DH group is at least FFDHE2048, since sub-2048-bit groups are the exact Logjam-class weakness auditors check for.
5. Certificate authentication vs key exchange split
Modern PKI deployments increasingly separate the two jobs RSA used to do alone: RSA (or Ed25519) certificates handle authentication and signing, while ECDHE handles every actual key exchange. This split is now the default assumption baked into TLS 1.3 rather than an optional hardening step, which is a meaningful shift from the TLS 1.0/1.1 era when static RSA key transport was still common.
How Major Platforms Handle Key Exchange Today
Looking at how large infrastructure providers configure their defaults is a useful sanity check on the guidance above, since these platforms terminate enough TLS traffic that a bad default becomes an expensive mistake fast.
Major CDNs and cloud load balancers have standardized on ECDHE for TLS key exchange, typically offering X25519 as the first preference and P-256 as a fallback for older clients that don’t support the newer curve. Static RSA key-transport cipher suites are absent from default configurations on current-generation load balancer and API gateway products. Enabling them, where still technically possible, usually requires an explicit legacy-compatibility flag rather than being the out-of-box behavior. Finite-field DHE groups are typically not offered at all by default on these platforms, reserved for on-request compatibility with older enterprise clients.
Managed database and message-queue services that terminate TLS internally follow the same pattern: ECDHE-first negotiation, RSA or ECDSA certificates for authentication, and DHE available but de-prioritized for compatibility edge cases. On the client side, modern browsers (Chrome, Firefox, Safari, Edge) have removed support for the weakest legacy DH groups entirely following the post-Logjam hardening push, meaning a server offering only a sub-2048-bit DH group will simply fail to negotiate a connection with an up-to-date browser rather than silently falling back to it.
The pattern across cloud, CDN, and browser vendors is consistent enough that it functions as an informal industry standard even where no single body mandates it: RSA for authentication only, ECDHE for key exchange by default, finite-field DHE as an opt-in compatibility path, and static RSA key transport treated as something to actively disable rather than something that ships enabled.
6. Email encryption and S/MIME
S/MIME, still common in enterprise and government email systems, has historically leaned on RSA for both signing and encrypting message keys, largely because store-and-forward email doesn’t have a live handshake where an ephemeral Diffie-Hellman exchange fits naturally. This is one of the few remaining mainstream contexts where RSA-based key transport persists by protocol design rather than legacy inertia, since email’s asynchronous delivery model doesn’t support a two-way ephemeral exchange the way a live TLS or SSH session does.
Post-Quantum Threat: Shor’s Algorithm Breaks Both
Here’s where the RSA-vs-DH debate becomes moot rather than resolved: neither survives a sufficiently large quantum computer. Shor’s algorithm, first described in 1994, gives an efficient quantum method for both integer factorization (breaking RSA) and the discrete logarithm problem (breaking both finite-field DH and elliptic-curve DH). Analysis of the quantum resources required shows DH-2048 needs essentially the same quantum resources to break as RSA-2048, and DH-3072 matches RSA-3072 in required resources. The two algorithms are quantum-equivalent at matched key sizes, not one more resistant than the other.
This matters today, not just hypothetically, because of “harvest now, decrypt later” attacks: an adversary can record encrypted TLS handshakes now and decrypt them once a cryptographically relevant quantum computer exists, even if that’s years away. TLS 1.3’s forward secrecy protects past sessions against future compromise of a server’s classical private key, but it offers no protection against an adversary that recorded the ephemeral DH exchange itself and later breaks the discrete-log problem with a quantum computer. Neither RSA nor DHE nor ECDHE, on their own, closes that gap.
NIST finalized its post-quantum cryptography standards in recent years, with ML-KEM (based on lattice problems, formerly known as Kyber) emerging as the leading replacement for both RSA and DH-family key exchange. Current best practice for organizations worried about harvest-now-decrypt-later exposure is hybrid key exchange: run classical ECDHE alongside ML-KEM in the same handshake, so an attacker has to break both the discrete-log problem and the lattice problem to recover the session key. Browsers and major cloud providers have been rolling out hybrid ECDHE+ML-KEM support in TLS 1.3 progressively.
Security Track Record: Vulnerabilities and CVEs
RSA’s most persistent real-world vulnerability isn’t in the math, it’s in implementation. The Bleichenbacher padding oracle attack, first published in 1998 and still resurfacing in variants against poorly hardened implementations (the ROBOT attack in 2017 found it alive in major vendor products two decades later), exploits how servers respond to malformed PKCS#1 v1.5 padding during RSA decryption. It’s a textbook example of why deprecating RSA key transport in favor of ephemeral DH-family exchange closes off an entire class of attack, rather than just patching individual bugs as they surface.
Diffie-Hellman’s headline vulnerability is Logjam, discussed above, which was a protocol-and-parameter weakness rather than a flaw in the DH math itself. As of 2025-2026, there is no publicly known cryptanalytic break of RSA or finite-field DH at 2048-bit or larger key sizes. Current security concerns center on implementation details (constant-time exponentiation, safe parameter generation, avoiding small-subgroup attacks) rather than the underlying hardness assumptions. NIST and IETF guidance continues to treat RSA-2048/3072 and DHE-2048/3072 (FFDHE) as acceptable for most classical-security applications, while steering new deployments toward ECC for efficiency and toward post-quantum hybrids for long-term confidentiality.
Pros and Cons
RSA (key transport / signing)
- Cheap public-key operation makes client-side verification and encryption fast
- Decades of implementation maturity and near-universal library support
- Still the right tool for certificate signing and authentication, just not for key exchange
- No forward secrecy when used for static key transport: a single key compromise unlocks all past sessions
- Private-key operations get expensive fast at 3072/4096-bit sizes
- Historically the target of implementation-level padding oracle attacks (Bleichenbacher, ROBOT)
- Removed entirely as a key-exchange mechanism in TLS 1.3
Finite-field Diffie-Hellman (DHE)
- Provides forward secrecy by design when ephemeral keys are used per session
- Standardized, well-vetted FFDHE groups (RFC 7919) eliminate the shared-weak-group risk Logjam exposed
- Still usable in TLS 1.3, SSH, and IPsec/IKE for environments that restrict elliptic curves
- Performance scales poorly with group size, and DHE-4096 is roughly 8x slower than DHE-2048
- Dramatically slower than ECDHE at equivalent security levels (20x-150x, per benchmark data above)
- Historic target of downgrade attacks (Logjam) exploiting weak or shared groups
- Larger wire footprint than elliptic-curve alternatives at the same security level
Migration Guide: Moving Off Static RSA and Legacy DHE
If an audit or a config review turns up static RSA key transport or sub-2048-bit DH groups, the fix path is well-trodden. Here’s the practical sequence most teams follow.
Step 1: Inventory current cipher suites
Run an SSL Labs scan or use openssl s_client -cipher / nmap –script ssl-enum-ciphers against every TLS-terminating endpoint to see exactly which key-exchange methods are currently negotiable, not just which ones are configured.
Step 2: Disable static RSA key-transport cipher suites
Remove any cipher suite string containing plain “RSA” as the key-exchange component (e.g., TLS_RSA_WITH_AES_128_GCM_SHA256) from your TLS 1.2 configuration. Keep ECDHE_RSA and ECDHE_ECDSA suites, which still use RSA/ECDSA for authentication but ECDHE for key agreement.
Step 3: Audit DH group sizes wherever DHE remains
Anywhere DHE is still offered (internal systems, older VPN gateways, legacy SSH configs), confirm the group is at least FFDHE2048 or an equivalent RFC 3526 MODP group of 2048 bits or larger. Reject anything smaller as a Logjam-class risk.
Step 4: Enable TLS 1.3 and prefer ECDHE
Turn on TLS 1.3 support where it isn’t already active. It removes static RSA key transport by protocol design, so this step alone closes most of the gap. Configure X25519 and P-256 as the preferred curves for ECDHE.
Step 5: Update SSH key-exchange preferences
In sshd_config and client configs, move curve25519-sha256 to the top of the KexAlgorithms list and keep diffie-hellman-group14-sha256 only as a fallback for legacy peers that can’t negotiate it.
Step 6: Plan for post-quantum hybrids
For systems handling data with long confidentiality requirements (health records, government communications, trade secrets), start evaluating hybrid ECDHE+ML-KEM key exchange now. Harvest-now-decrypt-later risk means waiting until a quantum computer actually exists is too late for data captured today.
Step 7: Re-scan and validate
Re-run the SSL Labs / nmap scan after changes to confirm static RSA key transport and weak DH groups are gone, and that forward secrecy is reported as fully supported across every negotiable cipher suite.
Use-Case Recommendations
- Public-facing web servers: Use TLS 1.3 with ECDHE (X25519 preferred) for key exchange and RSA or ECDSA certificates for authentication. Static RSA key transport should already be disabled.
- Internal enterprise APIs still on TLS 1.2: Prioritize enabling TLS 1.3 first. If TLS 1.2 must remain, restrict to ECDHE_RSA/ECDHE_ECDSA suites only and drop DHE entirely if client compatibility allows.
- SSH bastions and jump hosts: Default to curve25519-sha256, and keep diffie-hellman-group14-sha256 only for legacy network gear that can’t negotiate curves.
- IPsec/IKE VPN gateways with legacy hardware: If curve support (Group 19-21/31) isn’t available, use DH Group 14 (2048-bit) or higher. Never fall back to Group 1/2 (768/1024-bit).
- Systems handling long-confidentiality data (health, legal, government): Begin hybrid ECDHE+ML-KEM evaluation now to mitigate harvest-now-decrypt-later exposure, rather than waiting for a forced migration deadline.
- Embedded/constrained devices without elliptic-curve support: Use FFDHE2048 or FFDHE3072 rather than legacy or self-generated DH parameters, and validate the group against RFC 7919’s standardized set.
The Verdict: What to Actually Use in 2026
For new deployments, this comparison has a clear practical answer even if it isn’t the one the “RSA vs Diffie-Hellman” framing implies. Neither wins outright, because they’re no longer really competing for the same job. RSA (or increasingly Ed25519/ECDSA) should handle authentication and certificate signing. ECDHE, the elliptic-curve descendant of Diffie-Hellman, should handle key exchange, full stop. Plain finite-field DHE survives only where curve support genuinely isn’t available, and even then, only at FFDHE2048 or larger following the Logjam-driven standardization in RFC 7919.
The data backs this up from every angle covered above: ECDHE beats DHE-2048 by roughly 20x and DHE-4096 by roughly 150x in raw handshake throughput, TLS 1.3 telemetry shows over 85% of top sites already on the protocol version that mandates (EC)DHE, and static RSA key transport has gone from ubiquitous to essentially absent on the public web in under a decade. If your infrastructure still negotiates static RSA key exchange or a sub-2048-bit DH group in 2026, that’s not a design choice, it’s technical debt that predates a decision the rest of the industry already made.
The next transition is already visible on the horizon: both RSA and every flavor of Diffie-Hellman fall to Shor’s algorithm at the same relative cost, so the long-term answer isn’t “DH beat RSA,” it’s “classical key exchange, all of it, is on a clock.” Hybrid ECDHE+ML-KEM deployment is the practical bridge, and teams handling sensitive long-lived data should be piloting it well before a quantum computer capable of breaking 2048-bit keys actually exists.
Frequently Asked Questions
Is Diffie-Hellman more secure than RSA?
Not inherently. At matched key sizes (2048-bit RSA vs FFDHE2048, for example), both offer roughly the same classical security level per NIST SP 800-57. DH’s real advantage is forward secrecy when used in ephemeral mode (DHE/ECDHE), not a stronger underlying math problem.
Why did TLS 1.3 remove RSA key exchange?
Static RSA key transport doesn’t provide forward secrecy. If the server’s private key is ever compromised, every past session encrypted with it can be decrypted retroactively. TLS 1.3, defined in RFC 8446, mandates (EC)DHE for every handshake to close that gap, using RSA (or ECDSA/Ed25519) only for authentication.
What was the Logjam attack and does it still matter?
Logjam, published in 2015, showed that TLS servers offering weak or shared 512-bit and 1024-bit Diffie-Hellman groups could be downgraded and broken by a well-resourced attacker. It still matters because security audits routinely check for DH groups below 2048 bits as a Logjam-class red flag, even a decade later.
Is finite-field DHE still used anywhere in 2026?
Yes, though it’s a minority choice. It persists in some SSH configurations for legacy compatibility, in older IPsec/IKE VPN gateways without curve support, and as an available-but-rarely-negotiated FFDHE group family within TLS 1.3 itself.
Does quantum computing threaten RSA or Diffie-Hellman more?
Neither is more resistant than the other. Shor’s algorithm breaks both integer factorization (RSA) and the discrete logarithm problem (DH and ECDH) at comparable quantum resource costs for matched key sizes. Both are considered equally vulnerable to a sufficiently large quantum computer.
What should replace RSA and DHE for long-term security?
For key exchange, ECDHE is the current practical default, paired increasingly with hybrid post-quantum key exchange (ECDHE combined with ML-KEM) for data that needs to stay confidential for years. For signing and authentication, RSA and ECDSA remain standard, with post-quantum signature schemes like ML-DSA emerging for long-term migration.
Can I just increase my RSA or DH key size instead of switching to ECDHE?
You can, and it raises classical security, but it doesn’t restore forward secrecy for static RSA key transport, and larger DH groups get computationally expensive fast (DHE-4096 is roughly 8x slower than DHE-2048 in typical benchmarks). Switching to ECDHE solves both the performance and forward-secrecy problems at once.
Does this affect Bitcoin or cryptocurrency wallets?
Not directly for key exchange, since Bitcoin doesn’t use RSA or Diffie-Hellman for its core protocol. It relies on ECDSA (and increasingly Schnorr signatures) for transaction signing. The same quantum threat discussed here does apply to Bitcoin’s elliptic-curve signatures, which is a separate, ongoing discussion in the post-quantum cryptography space.
