Welcome to the second half of the journey! In the first five Parts we made sure a future quantum computer can’t decrypt the traffic we send today. Job done? Not quite. Because that leaves a juicy question hanging in the air: when two machines set up a secure channel, how do they know they’re actually talking to who they think they’re talking to?
That’s authentication: the other pillar, and the half almost everyone forgets. It has a genuinely different relationship with the quantum threat, one that catches even seasoned engineers off guard. So pour a coffee, because this is the part I really want you to sit with. No commands yet; we’ll start running them in Part 7.
Authentication is signatures
Authentication is how a peer proves “I am who I say I am.” On the internet, that proof is almost always a digital signature, usually wrapped in an X.509 certificate issued by a Certificate Authority (CA). Your browser trusts a website because a CA signed its certificate. Your VPN gateway trusts its peer because a signature checks out. Pull on that thread and the entire trust fabric of the internet turns out to be signatures, all the way down.
The classics that have guarded that fabric for decades (RSA, ECDSA, Ed25519) all share the same fatal flaw we met in the key-exchange pillar: their hard problem (factoring or discrete log) melts away in front of a quantum computer running Shor’s algorithm. An attacker could recover the private key from the public key and forge signatures at will. So authentication needs to go post-quantum too… but here’s where it gets interesting.
The plot twist
In the key-exchange pillar, the villain was “harvest now, decrypt later”: record traffic today, crack it years later. That threat is delayed (today’s secrets still have value tomorrow), which is exactly why post-quantum key exchange is urgent right now.
Authentication doesn’t work like that. A signature on a live handshake only has to resist forgery up to the moment it’s verified. If a quantum computer capable of forging signatures arrives in a few years, it cannot reach back in time and forge your 2026 VPN handshake to break into a session that ended years ago. The session’s already over. There’s nothing left to steal. So for short-lived authentication (a single TLS or IKEv2 handshake), there’s no “harvest now” equivalent.
Phew, right? So we can relax?
Well… no. Don’t relax too much. Authentication still has to go post-quantum, just for different (and sneakier) reasons:
- Long-lived trust anchors. Root and intermediate CA certificates routinely have 10–25 year lifetimes. A root signing key that a quantum computer can forge means an attacker could mint perfectly “trusted” certificates the moment a cryptographically-relevant quantum computer exists. Those roots need to be quantum-safe long before that day.
- Credentials that outlive the threat horizon. Code-signing keys, firmware-signing keys, device identity certs baked into hardware, long-term document signatures: anything whose signature must still hold up a decade from now.
- PKI migrates painfully slowly. Changing a signature algorithm means updating CAs, issuance pipelines, validation libraries, HSMs, and every single endpoint that verifies. That’s years of coordinated work across the whole ecosystem. Start late and you get caught out.
So here’s the mental model, the one line to remember from this post:
Key exchange is the fire alarm; authentication is the slow rebuild. Less urgent day-to-day, but you can’t do it overnight, and your trust anchors outlive your traffic. That’s exactly why we should understand it now.
Meet the contenders
Every showdown needs introductions. In one corner, the signatures that have guarded the internet for decades. In the other, the post-quantum newcomers.
The classics (quantum-vulnerable)
- RSA: the granddaddy. Security rests on factoring large numbers. Rock-solid for decades… and completely broken by Shor’s algorithm. Big-ish keys, modest signatures.
- ECDSA (P-256): elliptic-curve signatures. Much smaller keys than RSA for the same strength. Also toast against Shor’s.
- Ed25519, the modern darling: fast, misuse-resistant, tiny 32-byte keys and 64-byte signatures. Beautiful… and just as quantum-vulnerable as the others.
The post-quantum newcomers
- ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204). The lattice-based all-rounder and NIST’s recommended general-purpose default. Three sizes: ML-DSA-44 (NIST level 2), ML-DSA-65 (level 3, the sensible default), and ML-DSA-87 (level 5). Fast signing and verification; moderately large keys and signatures.
- SLH-DSA (Stateless Hash-Based Digital Signature Algorithm, FIPS 205). Its security relies only on hash functions: no lattices, no number theory, the safest assumption you can make. The price? Enormous signatures and slow signing.
- FN-DSA (uses a different math approach): small signatures, but famously tricky to implement safely. Still in draft, so we won’t lab it, but keep it on your radar for bandwidth-constrained uses.
The headline trade-off:
ML-DSA is the balanced workhorse you’ll reach for most of the time. SLH-DSA is the ultra-cautious choice for rarely-signed, long-lived things (think root CAs and firmware) where you’ll happily accept a giant signature in exchange for security that rests on nothing but hash functions.
Security and maturity at a glance
| Classical (RSA/ECDSA/Ed25519) | ML-DSA | SLH-DSA | |
|---|---|---|---|
| Quantum-safe | ❌ broken by Shor’s | ✅ no known quantum attack | ✅ no known quantum attack |
| Security basis | Factoring / discrete log | Module lattices | Hash functions only |
| Standardised | Decades of deployment | FIPS 204 (2024) | FIPS 205 (2024) |
| Maturity | Very high | Emerging | Emerging |
| Best for | Today’s everything | General-purpose default | Long-lived, rarely-signed anchors |
Neither extreme wins on its own. The classics are tiny, fast, and battle-tested, but quantum-doomed. SLH-DSA is the most cautious quantum-safe option but pays a heavy price in size and speed. ML-DSA-65 is the practical default: quantum-safe, fast, with certificate sizes that are bigger but totally manageable.
A familiar idea returns: composite signatures
Remember how the key-exchange pillar combined X25519 and ML-KEM so an attacker had to break both? Authentication has the very same idea, and it’s called composite signatures (or “hybrid” authentication): bind a classical signature and a post-quantum one into a single credential, and a verifier checks both. The credential stays safe as long as either algorithm holds.
Why bother instead of going pure ML-DSA? Two reasons: playing it safe (lattice crypto is young, so having two signatures protects you if someone finds a surprise break in the new one) and compliance (many environments still require a FIPS-validated classical algorithm during the transition). The cost is exactly what you’d expect: you carry both signatures, so the credential gets even bigger. It’s the authentication mirror of the key-exchange deal: pay a little size now to buy migration safety.
The IETF’s LAMPS working group is standardising composite signatures for X.509 right now, so this is very much live, evolving territory.
Next: let’s weigh these things
We’ve got the lay of the land: why authentication’s quantum deadline is different, who the contenders are, and the migration idea that ties it to the first pillar. Now it’s time to make it concrete, and the most striking thing about post-quantum authentication is something you can literally measure with ls.
In Part 7 we fire up OpenSSL 3.5, generate real post-quantum keys and certificates, and weigh them side by side with the classics. Fair warning: the size jump is going to make you say “whoa” out loud. Let’s go weigh some certificates!
