↓ Skip to main content
Le Site de François
  1. Index/

Diffie-Hellman (DH / ECDH / X25519)

Cryptography Key-Exchange Tls Pqc Primitives Ecc

Diffie-Hellman (DH) is a key exchange protocol published by Whitfield Diffie and Martin Hellman in 1976 — the first public description of asymmetric cryptography and one of the most consequential cryptographic publications in history. Its fundamental contribution is solving the key establishment problem: two parties who have never communicated before, communicating over a channel that an adversary can fully observe, can nonetheless agree on a shared secret that the adversary cannot determine. The security of finite-field DH rests on the discrete logarithm problem: given g^a mod p and g^b mod p (the public values exchanged), computing g^ab mod p (the shared secret) requires solving for either a or b, which is computationally infeasible for sufficiently large groups. The 1976 original uses multiplicative groups of integers modulo a prime p; the security level is determined by the size of p (currently 2048-bit minimum, 3072-bit recommended) and the group’s structure. Finite-field DH is still deployed in TLS 1.2 DHE cipher suites and legacy IPsec configurations, but has been supplanted in new deployments by Elliptic Curve Diffie-Hellman (ECDH) and specifically by X25519, which provide equivalent security at dramatically smaller key sizes.

ECDH moves the discrete logarithm problem from multiplicative integer groups to elliptic curve groups, as covered in the ECC entry. X25519 (RFC 7748) is the specific ECDH instantiation using Bernstein’s Curve25519, and is the dominant modern key exchange: it is the default key exchange in TLS 1.3, SSH (since OpenSSH 6.5), WireGuard, Signal Protocol, and most modern cryptographic protocols. X25519 is a Diffie-Hellman function (not a general ECDH implementation) whose inputs are a 32-byte private scalar and a 32-byte public point, whose output is a 32-byte shared secret, and whose implementation is designed to run in constant time without branches or table lookups — eliminating the timing side-channel vulnerabilities that have historically plagued elliptic curve implementations. X448 (Curve448, RFC 7748) is a higher-security alternative with a 56-byte key size, used where a larger classical security margin is required. The critical property all DH variants provide when used with ephemeral key pairs — fresh key pairs generated per session and discarded after use — is forward secrecy: if a server’s long-term private key is later compromised, previously recorded sessions cannot be decrypted because the session keys were derived from ephemeral DH shares that no longer exist anywhere. TLS 1.3 mandates ephemeral key exchange (all DHE/ECDHE), making forward secrecy unconditional; TLS 1.2 RSA key exchange (where the client encrypts the pre-master secret under the server’s long-term RSA key) provided no forward secrecy and is the primary reason recorded TLS 1.2 traffic is HNDL-exposed even without an explicit ECDH break.

DH in all its forms — finite-field, ECDH, X25519 — is broken by Shor’s algorithm on a CRQC. The discrete logarithm problem (both in integer groups and on elliptic curves) is solvable in polynomial time by a quantum computer, meaning all DH-based key exchanges become retroactively insecure for sessions recorded today once a CRQC exists. This is the HNDL (Harvest Now, Decrypt Later) threat: a passive adversary recording TLS 1.3 sessions using X25519 today can decrypt all of them once a CRQC is available — even though TLS 1.3 provides classical forward secrecy, it provides no quantum forward secrecy. The replacement is ML-KEM (FIPS 203), which is based on the Module Learning With Errors problem for which no efficient quantum algorithm is known. The transition is already underway: the hybrid key exchange group X25519MLKEM768 — which XORs the X25519 shared secret and the ML-KEM-768 shared secret, so the session key is secure if either component is unbroken — is the default in Chrome 131+ and available in OpenSSL 3.4+, TLS 1.3, and IPsec IKEv2 (RFC 9370). SSH hybrid key exchange (mlkem768x25519-sha256) is available in OpenSSH 9.9+. WireGuard’s hardcoded X25519 does not yet have a standardised post-quantum replacement, making the PSK option the only partial mitigation available without a protocol revision, as discussed in that entry.

Related

ECC (Elliptic Curve Cryptography)

Cryptography Pki Tls Signatures Key-Exchange Pqc
Elliptic Curve Cryptography (ECC) is a family of public-key cryptographic algorithms built on the mathematics of elliptic curves over finite fields. Its security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a public point Q = k × G on a curve (where G is a fixed base point and k is the private key scalar), recovering k from Q and G is computationally infeasible on classical computers. The practical advantage over RSA is dramatic key size efficiency: a 256-bit ECC key provides roughly the same classical security as a 3072-bit RSA key, because the best known classical algorithms for ECDLP (Pollard’s rho) are exponential whereas the best RSA algorithms (GNFS) are sub-exponential. This size difference has compounding benefits — smaller keys mean faster operations, smaller certificates, smaller TLS handshake messages, and lower power consumption on constrained devices. ECC is now the dominant choice for all new asymmetric cryptography deployments: TLS 1.3 mandates ECDHE for key exchange, and ECDSA or EdDSA for authentication; SSH defaults to Ed25519; code signing infrastructure increasingly uses ECDSA P-256 or Ed25519.

ECDSA (Elliptic Curve Digital Signature Algorithm)

Cryptography Signatures Pki Tls Ecc Pqc
ECDSA (Elliptic Curve Digital Signature Algorithm) is the elliptic curve analogue of DSA, standardised in FIPS 186 and the IETF, that produces digital signatures using a private key and verifies them with the corresponding public key. It is the most widely deployed signature algorithm in X.509 certificates (P-256 with SHA-256 is the default for certificate authorities issuing TLS certificates), in code signing (Authenticode, macOS, Linux package signing), in TLS 1.3 certificate authentication, in SSH host keys and user keys (though Ed25519 is increasingly preferred), and in blockchain and cryptocurrency systems. An ECDSA signature over a message m with private key d on curve with base point G produces a pair (r, s), where r is the x-coordinate of an ephemeral public key k × G and s encodes the relationship between the message hash, r, the private key d, and the nonce k. Verification requires only the public key Q = d × G and is fast; signing requires the private key and a nonce.

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

Cryptography Pqc Key-Exchange Tls Nist Lattice
ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardised as NIST FIPS 203 in August 2024, is the primary post-quantum replacement for key encapsulation and key exchange. It replaces the role of ECDH (X25519, P-256) and RSA key transport in TLS handshakes, IPsec IKEv2 negotiations, and any other protocol that needs two parties to establish a shared secret without prior key material. ML-KEM is derived from CRYSTALS-Kyber, the submission that won NIST’s lattice-based KEM selection, and its security rests on the Module Learning With Errors (MLWE) problem: distinguishing a structured noisy linear system from a random one is computationally hard, and no efficient quantum algorithm for this problem is known. The “module” qualifier means the construction uses polynomial rings structured in a way that allows a good balance between security and efficiency, contrasting with pure LWE (larger keys, simpler structure) and NTRU (smaller keys, different structure).