So… you keep hearing that quantum computers are going to break all our encryption “someday,” and somewhere between the headlines and the hype you’ve started wondering: is this actually my problem? And if it is, what can I do about it today?
Great questions. And here’s the good news: we’re not going to answer them with hand-waving and scary slides. Over this series we’re going to roll up our sleeves and find out for ourselves, with real tools, real protocols, and real packets on the wire, all running on a couple of throwaway Docker containers on your own laptop. No cloud, no special hardware, no zillion-line examples from some expert. Just you, me, and a question worth answering: can your VPN survive a quantum computer?
This first post sets the stage. No commands yet, just the context you need so that everything that follows clicks into place. By the end you’ll know exactly what we’re going to do, why it matters, and (I hope) you’ll be itching to get hands-on. Ready? Let’s go!
The threat in one paragraph
Most of the cryptography protecting the internet today (the key exchanges and digital signatures behind your VPNs, your HTTPS, your SSH) rests on a couple of math problems that classical computers find effectively impossible: factoring enormous numbers, and computing discrete logarithms. A sufficiently large quantum computer running Shor’s algorithm solves both of those easily. The day a “cryptographically-relevant quantum computer” (CRQC) arrives, a big chunk of the crypto we lean on every day stops being safe.
Nobody knows exactly when that day comes. But here’s the part that matters: you don’t get to wait for it. As we’ll see in a moment, for some of this, the clock is already ticking.
That’s why NIST spent years running a global competition to standardise a new generation of post-quantum cryptography (PQC), algorithms built on math problems that quantum computers can’t shortcut either. In 2024 the first standards landed, and they’re the stars of this series:
- ML-KEM (FIPS 203): post-quantum key exchange.
- ML-DSA (FIPS 204): post-quantum digital signatures.
- SLH-DSA (FIPS 205): a more cautious, hash-based signature.
Names like alphabet soup right now, I know. By the end of the series they’ll feel like old friends.
A secure handshake stands on two pillars
Here’s the mental model that organises this whole series. When two machines set up a secure channel (say, an IKEv2/IPsec VPN tunnel), that handshake rests on two distinct pillars, and quantum computers threaten both, but in very different ways. This distinction is the single most important idea in the series, so let’s give it room.
Pillar 1: Key exchange (deciding the shared secret)
Before two peers can encrypt anything, they need a shared secret that only they know. The classic tool for this is Diffie-Hellman: each side generates a key pair, they swap public keys over an untrusted network, and through some beautiful math they both independently arrive at the same secret without ever sending it across the wire. Lovely.
The quantum threat here is the nasty, urgent one: “harvest now, decrypt later.” An attacker doesn’t need a quantum computer today. They just need to record your encrypted traffic today and sit on it. Years later, once quantum hardware grows up, they crack the recorded handshake and decrypt everything after the fact. If the data you send today still has value in ten years, and a lot of it does, then this threat is already live. Today’s secrets are tomorrow’s breach.
Pillar 2: Authentication (proving who’s on the other end)
A shared secret is worthless if you negotiated it with an impostor. Authentication is how each peer proves “I am who I say I am,” almost always with a digital signature, usually wrapped in an X.509 certificate signed by a Certificate Authority. Your browser trusts a website because a CA signed its cert. Your VPN gateway trusts its peer because a signature checks out. Pull on that thread and the entire trust fabric of the internet is signatures, all the way down.
The quantum threat here is sneakier, and a bit surprising. A signature on a live handshake only has to resist forgery up to the moment it’s verified. A quantum computer arriving in 2035 can’t reach back in time and forge your 2026 handshake; that session is long over, with nothing left to steal. So there’s no “harvest now” equivalent for a short-lived authentication. Phew, right?
Well… don’t relax too much. Authentication still has to go post-quantum, just for different reasons. Think of long-lived trust anchors (root CA certs live 10–25 years), credentials baked into hardware, and code- and firmware-signing keys: anything whose signature must still hold up a decade from now. And PKI migrates painfully slowly. So:
Key exchange is the fire alarm; authentication is the slow rebuild. One is urgent right now. The other is less dramatic but can’t be done overnight, and your trust anchors outlive your traffic. We need to understand both, now.
If you take one thing away from Part 1, make it that line. Everything else hangs off it.
So what are we actually going to do?
This isn’t a theory series. It’s a lab series. Across the upcoming posts we’ll get our hands dirty with two real, end-to-end labs, one for each pillar:
- The key-exchange lab: we’ll stand up two containers as VPN peers and watch them negotiate a hybrid key exchange that mixes classical Diffie-Hellman with post-quantum ML-KEM inside a real IKEv2 handshake. Then we’ll capture the packets and compare classical vs hybrid, byte for byte. Is it slower? Bigger? Does it break things? We’ll stop guessing and measure.
- The authentication lab: we’ll generate real post-quantum keys and certificates with ML-DSA and SLH-DSA, line them up next to the classics (RSA, ECDSA, Ed25519), and weigh them (spoiler: the certs get a LOT bigger). Then we’ll use them to mutually authenticate a real VPN tunnel, classical first, then post-quantum, and stand right at the bleeding edge where this stuff is still being built.
The only thing you need installed is Docker. Everything else compiles and runs inside throwaway containers on your own machine, so you can run, break, and rerun the labs as many times as you like.
Our tools of choice
Two open-source workhorses carry the whole series, and it’s worth meeting them up front:
- strongSwan: a battle-tested IKEv2/IPsec implementation. It’s the thing that actually speaks the VPN protocol and lets us watch ML-KEM (and, on the bleeding edge, ML-DSA) run in a real handshake.
- OpenSSL 3.5+: the first mainstream OpenSSL with native support for all three NIST PQC algorithms. It’s how we’ll generate and inspect post-quantum certificates using plain, ordinary OpenSSL commands.
Why two tools instead of one? Because that split is an honest snapshot of how mature post-quantum cryptography is right now, and noticing where each piece is ready (and where it isn’t) is half the lesson. More on that when we get there.
The roadmap
Here’s where we’re headed: this intro, then two acts, one per pillar.
Part 1 (you’re here): the quantum threat, the two pillars, and what we’ll build.
Act I: Key Exchange
- Part 2: “harvest now, decrypt later” up close, and meeting our two contenders: X25519 and ML-KEM.
- Part 3: the head-to-head showdown (size, speed, security) and why the smart answer is hybrid.
- Part 4: hands-on, watching a hybrid post-quantum handshake cross the wire, packet by packet.
- Part 5: a completely different road to quantum safety: the preshared-key trick.
Act II: Authentication
- Part 6: the sneakier quantum deadline, and meeting the post-quantum signatures.
- Part 7: hands-on, the great certificate size explosion (and signing, verifying, tampering).
- Part 8: live fire, mutually authenticating a real IKEv2 tunnel, classical then post-quantum.
Each Part is a small, self-contained pill. You can follow the whole thing front to back, or jump to the pillar you care about most.
Before you go
Here’s the thing I love about this topic: post-quantum cryptography sounds impossibly futuristic, but you can touch it today, on your own laptop, with free tools, in an afternoon. No PhD required, no quantum computer needed (thankfully). And once you’ve seen a quantum-safe VPN tunnel come up with your own eyes, the headlines stop being scary and start being… kind of exciting.
So if you’ve got Docker installed and a little curiosity, you’ve got everything you need. In the next post we’ll meet our first two contenders and put the “harvest now, decrypt later” threat under the microscope.
See you in Part 2. This is going to be fun!
