Evidence signature
Public signals bind to governed proof.
No customer data.
QScout proof sequence. Evidence Handshake. public-to-private proof path. No customer data.
No. ECDH is not quantum safe. It relies on the same elliptic curve math as ECDSA and is fully broken by Shor's algorithm.
Key Takeaway: ECDH is NOT quantum safe. Replace ECDH key exchange with ML-KEM (FIPS 203). During transition, use hybrid key exchange (e.g., X25519+ML-KEM-768) as Chrome and Cloudflare have deployed.
ECDH is NOT quantum safe.
Elliptic Curve Diffie-Hellman (ECDH) is a key agreement protocol that allows two parties to establish a shared secret over an insecure channel. It is the elliptic curve variant of classical Diffie-Hellman, offering equivalent security with much smaller key sizes. A 256-bit ECDH key (Curve25519 or P-256) provides similar security to 3072-bit classical Diffie-Hellman, resulting in faster computations and smaller key exchange messages.
The protocol works as follows: Alice generates a private key (a random scalar a) and computes a public key (A = aG, where G is a generator point on the elliptic curve). Bob does the same (private key b, public key B = bG). They exchange public keys over an insecure channel. Alice computes the shared secret as aB = a(bG) = abG. Bob computes bA = b(aG) = abG. Both arrive at the same shared secret abG without ever transmitting it.
ECDH is ubiquitous in modern internet security: TLS 1.3 mandates ECDHE (ephemeral ECDH) for forward secrecy, using curves like X25519, P-256, or P-384. Signal, WhatsApp, and iMessage use ECDH (specifically X25519) for end-to-end encrypted messaging. SSH uses ECDH for session key establishment. WireGuard VPN uses Curve25519 for key exchange.
ECDH security depends on the elliptic curve discrete logarithm problem (ECDLP): given public keys A and B, it should be computationally infeasible to determine the private keys a or b, or to compute the shared secret abG without knowing a or b. Classically, solving ECDLP requires exponential time (approximately 2(n/2) operations for an n-bit curve, so 2128 for P-256).
Shor's algorithm breaks ECDLP in polynomial time, just as it breaks RSA. A quantum computer with approximately 2,000-3,000 logical qubits could break ECDH on Curve25519 or P-256. This is actually fewer qubits than required for RSA-2048 (4,000-10,000 qubits), meaning ECDH may fall to quantum attacks before RSA does.
The attack scenario is devastating for forward secrecy: Even though ECDHE uses ephemeral (temporary) keys that are discarded after each session, an adversary recording today's TLS handshakes can decrypt them in the future when quantum computers mature. This is the harvest-now-decrypt-later (HNDL) threat. Data encrypted today using ECDHE key exchange — even with quantum-safe AES-256 encryption — can be decrypted retroactively once the adversary has a CRQC to break the ECDH key agreement.
Organizations must replace ECDH with ML-KEM (FIPS 203) for quantum-safe key establishment:
Implementation note: ML-KEM public keys and ciphertexts are larger than ECDH (ML-KEM-768 uses ~1,184 bytes vs. 32 bytes for X25519). Test for compatibility with network equipment, firewalls, and legacy systems that may have packet size limitations.
Financial services rely on ECDHE (TLS 1.3) for online banking, trading platforms, and payment APIs. Every customer login, wire transfer instruction, and trading algorithm transmitted via TLS 1.3 with ECDHE is vulnerable to HNDL attacks. Even though the symmetric encryption (AES-256) is quantum-safe, adversaries capturing handshakes today can decrypt sessions once they have a CRQC. Financial institutions must deploy hybrid PQC key exchange immediately to protect forward secrecy.
Healthcare organizations transmitting electronic health records, telemedicine consultations, and genomic data via TLS/HTTPS face acute HNDL risk due to 50+ year HIPAA data retention requirements. Patient data captured in 2025-2026 will still be sensitive in 2070-2075, long after quantum computers are expected to exist. Healthcare providers must migrate to ML-KEM-protected connections.
Government and intelligence agencies are primary targets for nation-state HNDL campaigns. Adversaries are aggressively collecting encrypted diplomatic cables, classified communications, and intelligence reports, betting on future quantum decryption. NSA CNSA 2.0 mandates ML-KEM deployment by 2030 for national security systems.
Messaging and collaboration platforms (Slack, Microsoft Teams, Zoom, end-to-end encrypted messaging apps) use ECDH for establishing encryption keys. While consumer messages may have short confidentiality requirements, corporate communications, trade secrets, and M&A discussions retain value for years or decades.
Organizations should deploy hybrid ECDH+ML-KEM immediately for high-value communications and complete full ML-KEM migration by 2030.
| Full Name | Elliptic Curve Diffie-Hellman |
| Category | key exchange |
| Quantum Vulnerability | Shor's algorithm — ECDLP solved in polynomial time. HNDL risk for encrypted data with long confidentiality requirements. |
| NIST Status | NIST IR 8547 recommends deprecation by 2030 and disallowing after 2035. |
| Deprecation Timeline | Deprecated by 2030, disallowed after 2035 (NIST IR 8547) |
| Replaced By | ML-KEM (FIPS 203) |
Replace ECDH key exchange with ML-KEM (FIPS 203). During transition, use hybrid key exchange (e.g., X25519+ML-KEM-768) as Chrome and Cloudflare have deployed.
QScout discovers instances of ECDH across your infrastructure in 7 days — designed to minimize operational disruption. 72-hour time to first findings.