Home / Ciberseguridad / The encryption that will outlast quantum computers is already in your connections

The encryption that will outlast quantum computers is already in your connections

There is a silent threat that doesn’t unfold in real time, but slowly: the “harvest now, decrypt later” strategy. An attacker can be storing all the encrypted traffic flowing across the internet today, hoping to decrypt it once sufficiently powerful quantum computers exist. It’s not science fiction: the migration to post-quantum cryptography (PQC) has already begun, and your browser is likely already using some of it without you knowing.

The problem: RSA and ECC have an expiration date

The protocols that protect our communications (HTTPS, VPNs, encrypted messaging) rely on two families of mathematical problems: the factorization of large integers (RSA) and the discrete logarithm over elliptic curves (ECC). The security of RSA-2048 or ECC-256 stems from the fact that solving these problems with classical computers would take billions of years.

Shor’s algorithm changes the rules. A quantum computer with enough logical qubits and fault tolerance can solve both problems in polynomial time. Although no machine exists today capable of breaking RSA-2048, the pace of advancement in quantum error correction suggests the horizon is no longer theoretical. And since today’s confidential data may still be sensitive in 20 years, the threat is real even before the hardware arrives.

The answer: lattice-based cryptography

After a six-year competition, NIST standardized the first post-quantum algorithms in 2024: ML-KEM (FIPS 203, based on CRYSTALS-Kyber) for key exchange and ML-DSA (FIPS 204, based on CRYSTALS-Dilithium) for digital signatures. Both belong to a different mathematical family: lattice-based cryptography.

A lattice is a geometric structure formed by integer combinations of vectors in a multidimensional space. Finding the shortest vector in a lattice (SVP) or the closest one to a given point (CVP) is a computationally intractable problem, even for quantum computers using Shor’s algorithm. ML-KEM’s security rests on a variant called Learning With Errors (LWE): solving a system of linear equations where each equation carries a small random error.

How ML-KEM works in practice

The scheme is based on exchanging a public matrix A and a vector t = A·s + e, where s is the secret and e is the error. Recovering s from (A, t) is as hard as solving LWE. The magic lies in both parties being able to introduce additional noise and use reconciliation to derive a shared key without an observer being able to deduce it. There is no factorization or discrete logarithm: just linear algebra with noise.

The cost: keys are much larger. An ML-KEM-768 public key occupies 1184 bytes, compared to 32 bytes for X25519. This forces the TLS handshake to be fragmented across multiple packets if it exceeds the 1500-byte MTU, a real problem engineers have solved with ClientHello extensions and certificate compression (RFC 8879).

It’s already in your browser: X25519MLKEM768

The transition isn’t waiting for the quantum computer to arrive. Since 2024, Chrome, Firefox, and Edge have enabled the hybrid X25519MLKEM768 exchange by default in TLS 1.3. This approach combines the classical security of Curve25519 with the post-quantum resistance of ML-KEM: the session key is only compromised if both algorithms fail simultaneously.

The result is defense in depth: if a classical attacker breaks X25519, ML-KEM still protects; if a future quantum computer breaks ML-KEM (something not known today), X25519 still stands. It’s a conservative and pragmatic bet that already protects billions of daily connections.

What’s next

The next step is digital signatures. TLS certificates still use RSA or ECDSA, meaning an attacker with a quantum computer could forge a server’s identity. The migration to ML-DSA and SLH-DSA (hash-based) is underway, but it requires updating certificate authorities, browsers, and HSMs. It’s a deep change that will take years.

Meanwhile, the recommendation is clear: if your infrastructure uses TLS 1.3, verify that hybrid exchange is active. It’s not a measure for the future: it’s a response to the present, where today’s data is already being collected for tomorrow’s cryptanalysis.