Quantum-Safe Cryptography Explained: Future-Proofing Your Organisation's Data

Preparing for the post-quantum world today

27-03-2025

Quantum-Safe Cryptography Explained: Future-Proofing Your Organisation's Data

Contents

There is no quantum computer today that can break the encryption protecting your bank details, your VPN, or the TLS session you are almost certainly reading this over. That is the comforting half of the story. The uncomfortable half is that it does not matter. An adversary who cannot decrypt your traffic today can simply record it — quietly siphon the ciphertext into cold storage — and wait for the machine that can. This is called “harvest now, decrypt later”, and it turns a problem that feels a decade away into a problem you have already got, right now, for any data whose confidentiality has to outlive that decade. I first properly worried about this when I looked at my own certificate estate. Some of the TLS certs on my lab services were signed with keys I intended to keep around for years. Some of the data behind them — backups, personal archives, a self-hosted password store — needs to stay secret for the rest of my life, not the rest of the decade. Once you frame it that way, “post-quantum” stops being a conference buzzword and becomes a maintenance task with a deadline you cannot see. This is the piece I wish I had read before I started, so let me explain why the threat is real, what actually changed in 2024, and how to begin migrating without breaking everything you run. <h2 id="why-quantum-breaks-the-encryption-we-have">Why quantum breaks the encryption we have</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> Advertisement <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> Nearly all the public-key cryptography in daily use rests on one of two hard maths problems: factoring large numbers (RSA) or the discrete logarithm on elliptic curves (ECDH, ECDSA). “Hard” here means a classical computer would need longer than the age of the universe to brute-force a properly sized key. That assumption is what makes the padlock in your browser mean anything. In 1994 the mathematician Peter Shor published an algorithm that, running on a sufficiently large quantum computer, factors integers and solves discrete logarithms in polynomial time. Not a bit faster — categorically faster, the difference between “never” and “an afternoon”. Shor’s algorithm does not exist as a practical attack yet, because it needs thousands of stable, error-corrected logical qubits and current machines have a handful of noisy ones. But the algorithm is not in doubt. The only open question is engineering, and engineering questions have a way of getting answered. Symmetric cryptography — AES, the workhorse that actually encrypts your bulk data — is far less exposed. The best quantum attack there is Grover’s algorithm, which merely halves the effective key length. AES-256 drops to a still-comfortable 128 bits of security, so the fix is simply “use AES-256 and stop worrying”. The crisis is entirely in public-key land: key exchange and digital signatures, the parts that bootstrap every secure connection. If you want the wider context on what these machines can and cannot do, I have written a plain-English primer on <a href="/story/what-you-need-to-know-about-quantum-computing/">what quantum computing actually is</a> and a longer piece on <a href="/story/quantum-leaps-the-fascinating-journey-and-cultural-impact-of-quantum-computing/">the journey and cultural impact of quantum computing</a>; both are worth reading if the qubit talk above went past too fast. <h2 id="what-actually-changed-in-2024">What actually changed in 2024</h2> For years the honest answer to “what do I switch to?” was “wait”. That answer expired on 13 August 2024, when the US National Institute of Standards and Technology (NIST) published the first three finalised post-quantum standards. This is the single most important fact in the whole discussion, and a lot of older writing still gets it wrong by talking about candidates and competitions in the future tense. The competition is over. We have standards. <ul> <li>FIPS 203 — ML-KEM (formerly CRYSTALS-Kyber). A lattice-based key encapsulation mechanism. This is your replacement for RSA and ECDH key exchange — the part that establishes the shared secret at the start of a TLS handshake.</li> <li>FIPS 204 — ML-DSA (formerly CRYSTALS-Dilithium). A lattice-based digital signature scheme, NIST’s recommended default for signing certificates, code, and documents.</li> <li>FIPS 205 — SLH-DSA (formerly SPHINCS+). A hash-based signature scheme. Slower and bulkier than ML-DSA, but it rests only on the security of hash functions, so it is the conservative backup if a weakness is ever found in the lattice maths.</li> </ul> The naming churn is genuinely confusing, so keep the mapping straight: Kyber became ML-KEM, Dilithium became ML-DSA, SPHINCS+ became SLH-DSA. Tooling and blog posts use both sets of names interchangeably, which is a small tax you pay for having read the field before it settled. <h2 id="hybrid-the-only-sane-way-to-deploy-today">Hybrid: the only sane way to deploy today</h2><div class="ad-unit ad-in-article" aria-label="Advertisement"> Advertisement <ins class="adsbygoogle" style="display:block;text-align:center" data-ad-client="ca-pub-3726833845844946" data-ad-slot="3291553914" data-ad-format="auto" data-full-width-responsive="true"></ins> <script>(adsbygoogle = window.adsbygoogle || []).push({});</script> </div> You do not rip out the old algorithms and bolt on the new ones. The new schemes are young, and cryptographers are rightly nervous about trusting anything that has not been kicked around for a decade of real-world attack. The consensus approach is hybrid: run a classical algorithm and a post-quantum one side by side, and derive the session key from both. The connection is broken only if an attacker breaks both, so you lose nothing by adding the quantum-safe half — worst case, it is dead weight; best case, it is the thing that saves you. This is already live. OpenSSH added a hybrid post-quantum key exchange years ago and now defaults to it. If you are on a current OpenSSH, your SSH sessions are quite possibly already quantum-safe without you doing a thing: <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"># Check which key-exchange algorithm your SSH connection negotiated ssh -v [email protected] 2>&1 | grep -i "kex:" # Look for a line like: # kex: algorithm: [email protected] # The 'sntrup761' half is the post-quantum piece; 'x25519' is the classical half. </code></pre></td></tr></table> </div> </div>That <code>sntrup761x25519</code> is a hybrid: a post-quantum KEM combined with classical X25519. Seeing it means the harvest-now-decrypt-later attack on that SSH session has already failed. TLS is following the same path — hybrid <code>X25519MLKEM768</code> is now widely supported in browsers and servers — but the rollout is patchier, which is exactly why an inventory matters. <h2 id="making-a-migration-plan-that-survives-contact-with-reality">Making a migration plan that survives contact with reality</h2> Do not start by installing anything. Start by finding out what you actually have, because you cannot protect cryptography you have forgotten you deployed. On my own kit the exercise was humbling — I found certificates I could not remember creating and a VPN using a key I had generated years earlier and never rotated. The methodical version: <ol> <li>Inventory every use of public-key crypto. TLS certificates, SSH host and user keys, VPN tunnels, code-signing keys, database and disk encryption, JWT signing keys. A quick sweep of a host’s certificate store gets you started:</li> </ol> <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 7 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"># List every certificate on a host and its key algorithm/size find /etc/ssl /etc/pki -name '*.pem' -o -name '*.crt' 2>/dev/null | while read -r c; do printf '%s: ' "$c" openssl x509 -in "$c" -noout -text 2>/dev/null \ | grep -E 'Public Key Algorithm|Public-Key' | tr -d '\n' echo done </code></pre></td></tr></table> </div> </div><ol start="2"> <li> Classify by data lifetime. The urgent category is anything whose confidentiality must outlast the arrival of a cryptographically relevant quantum computer. A session token that expires in an hour does not care. A twenty-year archive of medical or legal records cares enormously. Sort by how long the secret must stay secret, not by how important the system feels. </li> <li> Upgrade the long-lived, harvestable things first. Key exchange for anything recorded in transit is priority one, because that is precisely what harvest-now-decrypt-later targets. Signatures are less urgent — a forged signature has to be produced before a future quantum computer exists to be useful, so you have more runway there. </li> <li> Prefer hybrid modes everywhere they exist. For your own services, <code>ssh-keygen -t ed25519</code> for host keys plus a modern OpenSSH gets you hybrid key exchange for free. For TLS, enable the hybrid group in your reverse proxy and let capable clients negotiate up. </li> </ol> If you run internal service-to-service encryption, this dovetails with a broader hardening job I have written about separately — see <a href="/story/mtls-mutual-tls-between-services-without-a-service-mesh/">mTLS between services without a service mesh</a>, because the certificate machinery you build for mutual TLS is exactly where you will be swapping algorithms first. <h2 id="gotchas-and-troubleshooting">Gotchas and troubleshooting</h2> The theory is tidy. The rollout is where it bites. Bigger keys break assumptions. ML-KEM and ML-DSA keys and signatures are substantially larger than their RSA or elliptic-curve equivalents — kilobytes where you had a couple of hundred bytes. That sounds trivial until a post-quantum certificate chain no longer fits in a single TCP packet and a handshake that assumed it would starts misbehaving. If a service works fine over a LAN but fails or stalls over a constrained or filtered network after you enable PQC, suspect fragmentation and MTU before you suspect the crypto. Middleboxes hate novelty. Corporate firewalls, deep-packet-inspection appliances, and older load balancers sometimes reject TLS handshakes carrying key-share groups they do not recognise. The failure looks like a mysterious connection reset with no useful error. Test the hybrid handshake end-to-end across the actual network path, not just against localhost, or you will ship a change that works on your desk and dies in production. Version skew. Hybrid key exchange only happens if both ends support the same group. Pin down your client and server versions first. On SSH, <code>ssh -Q kex</code> lists what your build offers; if <code>[email protected]</code> is absent, your OpenSSH is too old and no amount of config will conjure it. Do not roll your own. Every post-quantum library is young, and a naïve integration can leak key material through timing side channels the reference implementation guards against. Use OpenSSL 3.5+, a current OpenSSH, or a maintained library like liboqs. Wiring up lattice arithmetic yourself is how you turn a theoretical future threat into an actual present one. <h2 id="is-it-worth-it-and-who-is-this-for">Is it worth it, and who is this for?</h2> For a hobbyist running a media server and a few containers, the honest verdict is: mostly no, not yet — with one exception. Turn on hybrid SSH (you probably already have it) and use AES-256 for backups, and you have covered the realistic threat to a home lab for the price of doing nothing. Chasing post-quantum TLS across every internal service today is effort out of proportion to a threat that will not touch your holiday photos. For anyone holding data with a genuinely long confidentiality horizon, the calculus flips completely. Healthcare records, legal archives, state secrets, financial data under decades-long retention, long-lived signing keys and root certificates — if you are responsible for any of those, harvest-now-decrypt-later is not a future problem, it is a present liability accruing quietly in someone else’s cold storage. Start the inventory this quarter, move to hybrid key exchange for your longest-lived secrets first, and track the migration as ongoing maintenance rather than a one-off project. The reassuring part is that you are no longer waiting on the standards bodies. The algorithms are finalised, the hybrid modes are shipping in tools you already run, and the first concrete step — finding out what cryptography you actually depend on — costs nothing but an afternoon and a little honesty about the state of your own estate.

Written by Smarc

Founder and editor of vo.rs. A lifelong tinkerer who self-hosts far more than is sensible, hardens Linux boxes for fun, and prods the latest AI tools to see what they can really do. The how-to guides here are the notes Smarc wishes had existed the first time round.

Tagged#security #cryptography #quantum-computing #tls

Quantum-Safe Cryptography Explained: Future-Proofing Your Organisation's Data

Preparing for the post-quantum world today

Related Content

Reading the Tea Leaves: Hunting Intruders with journalctl and lnav

Prompt Injection: The SQL Injection of the AI Era

Locking Out the Bots: Fail2ban and CrowdSec on a Modern Linux Server

When Your AI Agent Goes Rogue: Securing Autonomous Agents in Production