Quantum computers and today's encryption

Every few months there's a headline: "Quantum computer breaks encryption!" Usually, if you read past the headline, it's a research result on a tiny problem. Today's quantum computers are nowhere near breaking the encryption that protects the internet.

So why should DevOps engineers care now? Because the migration to quantum-safe cryptography is one of the biggest infrastructure changes of the next decade, and parts of it are already happening in the tools we use every day.

The problem in plain words

Most of the internet's security relies on public-key cryptography: RSA and elliptic curve algorithms. They're used in TLS (HTTPS), SSH, VPNs, code signing, certificates and much more. Their security rests on maths problems that are extremely hard for normal computers.

A large enough, stable quantum computer running Shor's algorithm could solve those problems efficiently. That would break RSA and elliptic curve cryptography.

Symmetric encryption like AES and hash functions like SHA-256 are much less affected. Longer keys (AES-256) are considered safe.

Nobody knows exactly when such a quantum computer will exist. Estimates range from several years to decades. But "we don't know when" is not the same as "we don't need to worry".

"Harvest now, decrypt later"

Here's the reason to act now. An attacker can record encrypted traffic today and store it. When a capable quantum computer exists, they decrypt it.

If your data needs to stay secret for ten or twenty years, like health records, financial data, government data, trade secrets or personal communications, it may already be at risk from traffic being recorded today.

That's why the focus right now is on key exchange: the part of TLS and other protocols that protects the session keys.

The data you send today needs to be safe from the computers of tomorrow.

The new standards

In August 2024, the US National Institute of Standards and Technology (NIST) published the first post-quantum cryptography standards, after years of public competition and analysis:

• ML-KEM (FIPS 203, formerly known as CRYSTALS-Kyber): for key exchange / encapsulation.
• ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium): for digital signatures.
• SLH-DSA (FIPS 205, formerly SPHINCS+): a hash-based signature scheme, as a conservative backup.

More algorithms are in progress. European agencies like Germany's BSI broadly align on these, with their own recommendations, often favouring hybrid approaches.

What's already supported

The good news: you might already be using post-quantum cryptography without knowing it.

• Browsers: Chrome, Firefox and Safari support hybrid key exchange (X25519 combined with ML-KEM) in TLS 1.3.
• CDNs and large providers: Cloudflare and others enable hybrid post-quantum key exchange by default, and a large share of their traffic already uses it.
• OpenSSL 3.5 added support for ML-KEM, ML-DSA and SLH-DSA.
• OpenSSH has used hybrid post-quantum key exchange by default for some time, and recent versions default to an ML-KEM-based hybrid.
• Go, Java, BoringSSL and other libraries have added support.

"Hybrid" means combining a classical algorithm with a post-quantum one, so the connection is safe as long as either one holds. That protects against both quantum attacks and the risk that a new algorithm turns out to have weaknesses.

Crypto agility: what DevOps teams should do

The biggest lesson from past migrations (SHA-1 to SHA-256, TLS 1.0 to 1.2) is that they take years, mostly because nobody knows where all the crypto lives. So start there:

1. Make an inventory. Where do you use cryptography? TLS endpoints, internal mTLS, SSH, VPNs, certificates, code signing, encrypted storage, tokens, third-party libraries. Tools that scan certificates and TLS configurations help.
2. Prioritise long-lived secrets. What data needs to stay confidential for many years? That traffic should move to hybrid key exchange first.
3. Keep software up to date. Most post-quantum support arrives through library, OS, load balancer and runtime updates. Old software is the biggest blocker.
4. Prefer TLS 1.3 everywhere. Post-quantum key exchange is built for it.
5. Build crypto agility. Avoid hardcoded algorithms. Make it possible to change algorithms through configuration, not code rewrites.
6. Ask your vendors about their post-quantum roadmap: cloud providers, load balancers, HSMs, VPNs, certificate authorities.
7. Watch certificates. Post-quantum signatures in public certificates will come later and bring larger certificates and handshakes. Test performance when the time comes.

So, should you panic?

No. Your HTTPS isn't broken. But this is a slow, multi-year migration, and the teams that start with an inventory and up-to-date software will have a much easier time than those who wait for a deadline.

My take: quantum computers aren't here yet, but the migration is. Know where your crypto lives, keep your stack current, and let hybrid key exchange do the rest.

— Desly