Post-quantum cryptography for practitioners: ML-KEM, ML-DSA, and hybrid TLS

What is at risk

A large, fault-tolerant quantum computer running Shor’s algorithm would break RSA, finite-field Diffie-Hellman, and elliptic curve cryptography, which protect key exchange and signatures today. Symmetric algorithms such as AES and hashes such as SHA-256 are much less affected; larger keys like AES-256 keep a comfortable margin. The urgent concern is “harvest now, decrypt later”: recorded traffic protected by classical key exchange could be decrypted in the future.

The new standards

In August 2024 NIST published FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) for key encapsulation, FIPS 204 (ML-DSA, from CRYSTALS-Dilithium) for signatures, and FIPS 205 (SLH-DSA, from SPHINCS+), a hash-based signature scheme. A further signature standard based on FALCON is in progress, and HQC was selected in 2025 as a backup key encapsulation mechanism.

Deployment starts with key exchange, because of harvest-now-decrypt-later. Major browsers and CDNs already negotiate a hybrid group, X25519MLKEM768, that combines classical X25519 with ML-KEM-768, so the connection stays secure if either algorithm holds.

Lab: see hybrid key exchange

With OpenSSL 3.5 or later, which includes ML-KEM, connect to a site that supports hybrid key exchange and check the negotiated group. In a browser, open developer tools, select the Security panel, and look at the key exchange for a major site. Then start a small crypto inventory for one application: list where it uses TLS, which libraries, which key exchange and signature algorithms, and which certificates and keys exist.

openssl version
openssl s_client -connect cloudflare.com:443 -groups X25519MLKEM768 -brief </dev/null 2>&1 | grep -iE 'Negotiated|group|Protocol'
openssl list -kem-algorithms | grep -i mlkem
openssl list -signature-algorithms | grep -iE 'ml-dsa|slh-dsa'

Planning a migration

Inventory cryptography: protocols, libraries, certificates, keys, hardware security modules, and long-term signed data. Prefer crypto agility, meaning algorithms are configuration rather than hard-coded. Upgrade TLS libraries to versions that support hybrid key exchange, and follow guidance from NIST, national cyber agencies, and your vendors for signature migration timelines, which are longer because certificates and PKI must change.