Is Diffie-Hellman Quantum Safe?

Diffie-Hellman is NOT quantum safe.

How Diffie-Hellman Works

Diffie-Hellman (DH) key exchange, invented in 1976 by Whitfield Diffie and Martin Hellman, was the first published practical method for establishing a shared secret over an insecure channel. Unlike asymmetric encryption (which encrypts data), DH is a key agreement protocol used to derive symmetric keys for subsequent encryption (typically AES).

The protocol operates in a finite field (modular arithmetic): Alice and Bob agree on public parameters (a large prime p and generator g). Alice chooses a secret integer a and computes A = g^a mod p. Bob chooses secret b and computes B = g^b mod p. They exchange A and B publicly. Alice computes s = B^a = (g^b)^a = g^(ab) mod p. Bob computes s = A^b = (g^a)^b = g^(ab) mod p. Both arrive at the same shared secret s = g^(ab) without transmitting a or b.

Common DH groups include: DH Group 14 (2048-bit prime), Group 15 (3072-bit), and Group 16 (4096-bit). Ephemeral Diffie-Hellman (DHE) generates new private keys for each session, providing forward secrecy — even if the server's long-term private key is compromised, past sessions remain secure.

Quantum Vulnerability Explained

DH security relies on the discrete logarithm problem (DLP): given g, p, and A = g^a mod p, it should be computationally infeasible to recover a. Classically, the best algorithms (Number Field Sieve) require sub-exponential time, making 2048-bit DH secure against classical attacks (estimated centuries to break).

Shor's algorithm solves the discrete logarithm problem in polynomial time, so larger finite-field DH groups do not create post-quantum resistance. Exact fault-tolerant resource requirements depend on the group, circuit, architecture, and error-correction assumptions.

DHE's forward secrecy provides no protection against quantum adversaries who record key exchanges. An adversary capturing DHE handshakes today can store them and decrypt the sessions once quantum computers mature (HNDL attacks).

Migration Path

Inventory Diffie-Hellman use and migrate it through an approved key-establishment profile:

• TLS: Modern TLS 1.3 commonly negotiates ECDHE rather than finite-field DHE. Where a defined hybrid group is supported, test the exact endpoints, negotiation, downgrade behavior, middleboxes, and rollback.
• VPN and IPsec: RFC 9370 defines multiple-key-exchange negotiation for IKEv2. The PQC algorithm, product support, configuration, and validation remain profile- and implementation-specific.
• SSH: Inspect the algorithms actually offered, selected, and accepted by both endpoints. A software version alone does not prove a hybrid algorithm is enabled or policy-approved.
• Legacy protocols: Some enterprise systems still use static DH (non-ephemeral) for key agreement, which lacks forward secrecy even classically. These require urgent replacement with ephemeral ML-KEM.

Industries at Risk

Enterprise VPN infrastructure (site-to-site and remote access VPNs) extensively uses IKEv2 with DH groups 14-20 for key establishment. Corporate networks connecting remote offices, cloud environments, and remote workers are vulnerable to HNDL attacks. A future quantum adversary could decrypt all VPN traffic captured today, exposing intellectual property, customer data, and internal communications.

Financial services use DH in legacy protocols (older TLS 1.2 configurations, proprietary trading protocols, SWIFT network connections). While most modern systems have migrated to ECDHE, legacy DH deployments remain in production due to interoperability requirements with older systems.

CNSA 2.0 requirements apply to NSS and related acquisition or interoperability contexts. The December 2024 FAQ describes staged 2027 acquisition, 2030 phaseout, and 2031 algorithm-use dates unless otherwise noted; it does not establish a universal 2030 mandate for every DH deployment.

Industrial control systems and SCADA networks use VPNs with DH key exchange to connect remote substations, manufacturing plants, and utility infrastructure. These systems have long operational lifetimes (20-30 years) and slow patch cycles, creating extended vulnerability windows.

Timeline to Obsolescence

• 2025-2026: DH provides classical security but faces HNDL quantum threats. Begin PQC migration.
• 2029: Treat as a readiness/control date. DH-protected communications captured today face future decryption once sufficient CRQC capability exists.
• 2030: Within CNSA 2.0's NSS scope, equipment and services unable to support CNSA 2.0 are to be phased out unless otherwise noted. NIST IR 8547 remains an initial public draft.
• 2035: NIST IR 8547's initial public draft proposes a federal disallowance planning horizon for affected DH uses; commercial vendor behavior must be verified from current primary documentation.

Set transition dates from observed DH use, capture exposure, data lifetime, applicable policy, supported profiles, interoperability evidence, and rollback readiness.