Learn PKI - Post-Quantum & Modern Cryptography

#Introduction

Episode 19 made your PKI visible and automated. But there is a question lurking behind all that comfort: will the RSA and ECDSA keys we built across these twenty episodes be safe in the future? The honest answer — possibly not. A sufficiently large quantum computer could crack the mathematics behind RSA and ECC at terrifying speed.

Episode 20 opens a window into the post-quantum world: the ML-KEM, ML-DSA, and SLH-DSA algorithms standardized by NIST, the hybrid handshake bridging the transition, provider support in OpenSSL, then modern trends such as short-lived certificates, hardware-bound keys, and device attestation. This is not fan material — the standards are already out, and adoption is underway across the industry.

#Why Quantum Is a Threat

Classical public key cryptography stands on difficult mathematical problems: prime factorization for RSA, discrete logarithms for ECC. Classical computers need astronomical time to solve them. A quantum computer, with Shor's algorithm, can crack both in polynomial time — meaning the cracking time drops drastically once the machine is large enough.

Two problems often ignored: first, data intercepted today can be stored and decrypted later when a large quantum machine is available — this is called harvest now decrypt later. Second, changing algorithms in PKI takes years. That is why post-quantum standards are published now, long before the real threat arrives, so the transition is not done in a panic.

The good news: this transition is nothing new. PKI has moved from RSA 1024 to RSA 2048, then to SHA-1 and SHA-256, and now to ECDSA. Each time, the key is the same: there is an overlap period where old and new algorithms run side by side. This episode gives you the vocabulary and patterns to go through the next transition without fear.

#ML-KEM: Key Encapsulation (FIPS 203)

ML-KEM, previously known as Kyber, is the post-quantum algorithm for key exchange. It replaces the role of Diffie-Hellman and ECDH in the TLS handshake. Its name follows the lattice structure: the Learning With Errors problem believed to remain hard even for quantum computers. FIPS 203 defines the ML-KEM-512, ML-KEM-768, and ML-KEM-1024 parameter sets, with security levels roughly equivalent to AES-128, AES-192, and AES-256.

openssl list -kem-algorithms
openssl list -signature-algorithms | rg -i ml-dsa

ML-KEM public keys are much larger than ECDH, and the ciphertexts are larger too. This has practical implications: TLS handshake packet sizes balloon, and some network middleware that parses handshakes must be updated. The computational load is actually light — lattice multiplication is very fast on modern hardware.

#ML-DSA: Signatures (FIPS 204)

ML-DSA, previously called Dilithium, is the post-quantum signature algorithm. It replaces the role of RSA and ECDSA for signing certificates, CRLs, and messages. FIPS 204 defines sizes that can be adjusted, with public keys and signatures much larger than ECDSA. This size is the main reason the post-quantum transition in PKI cannot happen overnight — every certificate, chain, and handshake grows along with it.

For CAs that will still be alive for years, choosing ML-DSA for root or intermediate certificates is a wise long-term decision. But remember: old clients that do not recognize the new algorithms will not be able to validate a fully post-quantum chain. The transition must be gradual, and this is where the hybrid handshake and cross-signing from episode 18 return.

#SLH-DSA: The Conservative Alternative (FIPS 205)

SLH-DSA, previously known as SPHINCS+, takes a different approach: it is hash-based, not lattice-based. Because it only relies on the security of hash functions, SLH-DSA carries a more conservative security assumption and survives longer against future threats not yet imagined. The price paid is very large keys and signatures, plus slower speed.

openssl list -signature-algorithms | rg slh-dsa shows its support in an updated OpenSSL. SLH-DSA is rarely used for every certificate, but it is very well suited to situations where keys live a very long time — such as a root CA kept offline for decades. Combining ML-DSA for day-to-day needs and SLH-DSA for the topmost layer is a pattern many are beginning to adopt.

#Hybrid Handshake X25519MLKEM768

The biggest problem of the transition is compatibility: a new server cannot simply abandon old clients. The solution adopted by industry is the hybrid handshake — performing the classical and post-quantum key exchanges together, then combining the results. Even if one algorithm breaks in the future, the combined result remains safe.

openssl s_client -connect app.example.com:443 \
  -groups X25519MLKEM768 -tls1_3

Group names such as X25519MLKEM768 appear in the groups list when both the client and server support them. Many implementations, including BoringSSL and the latest OpenSSL, make hybrid the default for TLS 1.3. Note that the hybrid handshake only protects the connection — certificate signatures still need their own treatment, which is where the combination of ML-DSA and cross-signing comes in.

#A Gradual Transition Strategy

Moving to post-quantum is not a big one-night event; it is a process running over years. The wisest move is to mimic the pattern we already know from episode 18: use cross-signing so the old root and new root coexist, then slowly shift clients to the new chain. Each new certificate can use ML-DSA, while old clients still accept the classical chain.

A realistic path for most organizations starts with the easiest step: enable hybrid groups in TLS 1.3 for all new services. This protects data from the harvest now decrypt later threat without changing infrastructure at all. After that, test post-quantum chains in dev and staging environments, measure the overhead of packet size and latency, then roll out to production with a wide observation window.

Finally, prioritize the devices that live the longest. Root CAs, VPN certificates, and device firmware are the first candidates for post-quantum algorithms, because their lifetime crosses the estimated quantum threat horizon. Devices updated every month can safely wait longer.

#Provider Support in OpenSSL 3.5 and 4.0

OpenSSL adopts post-quantum through the provider architecture. Algorithms no longer have to be built into the core library; they can be loaded as separate providers, just like you already saw for the legacy provider in episode 3. This makes adding new algorithms an add-on module, not a library overhaul.

openssl s_server -provider default -provider mlkem \
  -accept 4433 -cert server.crt -key server.key

Official and third-party post-quantum providers supply ML-KEM, ML-DSA, and SLH-DSA for OpenSSL. Infrastructure operators who want to be future-ready can start testing post-quantum chains in staging environments now, while still using ECDSA or RSA as a safety net — exactly the hybrid spirit we discussed earlier.

#Modern Trend: Short-Lived Certificates

While the world prepares new algorithms, there is a parallel trend: short-lived certificates. The principle is simple — if a certificate lives only a few hours or days, the value of a stolen key becomes almost zero. Episodes 8 and 10 showed that ACME and cert-manager make automating these short certificates practical to run.

Private keys still must be protected, but the severity drops drastically. A short validity period also reduces reliance on revocation: a problematic certificate expires by itself before it can be misused. The challenge is operational — short certificates demand solid monitoring and automation, two things we already built in episode 19.

#Hardware-bound Keys and YubiKey

Keys stored on disk can be stolen; keys bound to hardware cannot be moved easily. Hardware-bound keys were born from that need: the private key never leaves the secure element or smartcard. YubiKey is the most well-known example — its PIV and OpenPGP keys can be used for signing, SSH, and authentication without ever exposing the private key.

ssh-add -s /dev/smartcard0
ssh user@server.example.com

This architecture changes the threat model: stealing a certificate is not enough, the attacker also needs the physical device and its owner's PIN. Combine it with episode 13 about HSM and KMS — the same pattern, from a small device in your pocket to a data-center-class HSM for the root CA.

#Device Attestation and DICE

Trust is not only about who holds the key, but also how confident we are that the device is really the intended device. Device attestation answers that question: a device proves its identity and integrity before being given access. In TLS 1.3, an attestation extension lets client and server share evidence verified beyond ordinary credentials.

DICE brings this principle to firmware: a trust chain begins from a unique per-device key burned into silicon, then each boot layer verifies the next layer and builds an identity usable in PKI. This lets IoT and edge devices obtain certificates specific to their physical unit, not just their device type.

On the practical side, attestation means device onboarding flows can be automated: a device proves itself once, then automatically gets a certificate from the internal CA — the machine identity pattern from episode 15, now running without waiting for a human. Policy can directly reject devices whose firmware is no longer compliant, before they ever touch the network.

#AI-assisted Key Management

The last trend is using AI to manage cryptographic policy. Imagine a system that analyzes certificate usage patterns, detects anomalies such as issuance at unusual hours, and recommends policy — for example shortening validity or changing algorithms for certain workloads. This is not replacing human decisions, but helping spot patterns that get missed.

More importantly: AI can also be an attacker tool, crafting more convincing phishing or automating key abuse. The best defense remains fundamental — episode 16 on security best practices never goes out of date. Algorithms may be new, but the discipline stays: keys protected, access restricted, everything audited. AI-assisted key management also promises reduced manual load: finding unmanaged certificates, mapping which expire soonest, and prioritizing algorithm migration by per-workload risk. Use AI as an analysis assistant, not as the full decision holder.

#Closing

Episode 20 takes you ahead of the curve: ML-KEM for key exchange, ML-DSA for signatures, SLH-DSA for conservative needs, the hybrid handshake as a transition bridge, provider support in OpenSSL, then modern trends from short certificates, YubiKey, DICE attestation, to AI help for key management.

Key takeaways:

• Quantum threatens RSA and ECC; post-quantum standards are already published and adoption is underway.
• ML-KEM replaces key exchange, ML-DSA replaces signatures, SLH-DSA is for very long-term needs.
• The hybrid handshake combines classical and post-quantum cryptography for a safe transition.
• OpenSSL supports new algorithms through providers that can be loaded modularly.
• Short-lived certificates and hardware-bound keys shrink the impact of key theft.
• The basic discipline still applies: keys protected, access restricted, everything audited.

Cryptography will keep moving, and every tool's roadmap keeps changing. In episode 21 we look at the roadmaps: modern OpenSSL 4.0 features, cert-manager 1.21, step-ca 0.30, and the big trends of 2026. See you there!