Skip to content
PQC Portal
ไทย

Step 3 of 4

The fix

The new math behind post-quantum algorithms, the standardised families, and why today's deployments combine old and new.

Written by

  1. Step 1: Quantum basics
  2. Step 2: The threat
  3. Step 3: The fix
  4. Step 4: The cost & where to start

The fix: hard problems for both kinds of computer

Post-quantum cryptography runs on ordinary computers. It replaces factoring and discrete logarithms with problems that have no known efficient quantum algorithm.

b₁b₂targetclosest lattice point?

Find the closest point

Lattice schemes hide a secret behind noise. In two dimensions, finding the lattice point nearest a target is easy. ML-KEM-768 works in 768 dimensions, where no known classical or quantum algorithm does it efficiently.

Module lattices

Fast, moderate sizes. The default choice.

  • ML-KEMFIPS 203· Key exchange
  • ML-DSAFIPS 204· Signatures

Hash-based

Security rests only on hash functions. Conservative, but large signatures.

  • SLH-DSAFIPS 205· Signatures
  • LMS / XMSSSP 800-208· Signatures

NTRU lattices

Compact signatures, trickier to implement (floating point).

  • FN-DSAFIPS 206· Signaturesin development

Error-correcting codes

A backup KEM built on different math from ML-KEM.

  • HQCFIPS 207· Key exchangein development

PQC is not "quantum cryptography". It needs no quantum hardware and no special links. Quantum key distribution (QKD) is a different thing.

See the standards tracker →

Hybrid: belt and braces

Today's deployments run a classical and a post-quantum key exchange together and combine the results. An attacker has to break both.

ClientServerX25519 · 32 BML-KEM key · 1,184 BX25519 · 32 BML-KEM ciphertext · 1,088 Bss · X25519ss · ML-KEMss · X25519ss · ML-KEMSession keysML-KEM ‖ X25519Quantum attacker✓ still secret
  1. 1Client sends two key sharesThe ClientHello carries an X25519 public key (32 bytes) and an ML-KEM-768 encapsulation key (1,184 bytes).
  2. 2Server answersThe server sends its own X25519 key (32 bytes) and an ML-KEM ciphertext (1,088 bytes) that wraps a fresh secret for the client.
  3. 3Two shared secretsBoth sides now hold the same X25519 secret and the same ML-KEM secret. Neither secret ever crossed the network.
  4. 4Combined into session keysThe two secrets are joined (ML-KEM first) and fed into the TLS key schedule to make the session keys.
  5. 5Against a quantum attackerA quantum computer could break the X25519 part, but not ML-KEM, so the combined key stays secret.

If ML-KEM had an undiscovered flaw, X25519 still protects against today's attackers.

When a quantum computer arrives, ML-KEM still holds.

This hybrid, X25519MLKEM768, is on by default in current Chrome, Edge and Firefox, and Cloudflare negotiates it automatically.

Is your connection using it? →
Technical deep dive

ML-KEM is built on Module-LWE: given a public matrix A and b = A·s + e with a small secret s and small error e, recover s. ML-KEM-768 uses a 3×3 matrix of polynomials of degree 256 with coefficients mod q = 3329.

A Fujisaki–Okamoto-style transform makes the KEM secure against chosen-ciphertext attacks: decapsulation re-encrypts and compares, and implicitly rejects tampered ciphertexts.

In TLS 1.3, X25519MLKEM768 is one NamedGroup (0x11EC). The client key share is an ML-KEM-768 encapsulation key (1,184 bytes) followed by an X25519 public key (32 bytes); the server answers with a ciphertext (1,088 bytes) plus its X25519 share. The shared secret is the ML-KEM secret concatenated with the X25519 secret.