Post-Quantum Cryptography (PQC) & TLS 1.3: An Engineering Migration Roadmap
A practical guide to NIST’s finalized post-quantum standards (ML-KEM, ML-DSA), mitigating 'Harvest Now, Decrypt Later' attacks, and auditing cipher agility across cloud services, SSH, and VPNs.
Robin Singh · Published · Updated · 5 min read
For decades, the foundation of modern internet security has rested on two mathematical problems: integer factorization (RSA) and discrete logarithms over elliptic curves (ECDSA, ECDH, Ed25519). Every HTTPS connection, SSH tunnel, encrypted database snapshot, and digital signature relies on these primitives.
With the rapid progression of quantum computing and Shor's algorithm, these mathematical foundations have a definitive expiration date. In response, the National Institute of Standards and Technology (NIST) finalized its official Post-Quantum Cryptography (PQC) standards:
- FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) for Key Encapsulation Mechanisms.
- FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) for Digital Signatures.
- FIPS 205 (SLH-DSA, derived from SPHINCS+) for Stateless Hash-Based Digital Signatures.
Many engineering teams assume quantum security is a theoretical issue reserved for the 2030s. This assumption overlooks the primary active threat model today: "Harvest Now, Decrypt Later" (HNDL).
At Palmate Solutions, our cloud and DevOps engineers and security consultants are actively assisting businesses with cryptographic agility audits. Here is an actionable roadmap to protect your systems today.
The "Harvest Now, Decrypt Later" Threat Model
Adversaries, nation-states, and sophisticated threat actors are currently intercepting and archiving high volumes of encrypted internet traffic.
[ Active HTTPS / TLS Session Today ]
│
├──► [ Legitimate Server (Ephemeral Session Encrypted) ]
│
▼
[ Adversary Packet Tap (Wiretapping / ISP Intercept) ]
│
▼
[ Long-Term Ciphertext Vault (Stored indefinitely) ]
│
▼ (When cryptanalytically relevant quantum computers arrive)
[ Offline Quantum Decryption Engine ]
│
▼
[ Plaintext Customer Data, API Keys, Trade Secrets Exfiltrated ]
If your business transmits sensitive long-term data—such as financial transactions, medical records, intellectual property, or enterprise authentication secrets—that data must remain confidential for 10 to 25 years. Any data protected solely by standard RSA-2048 or classical elliptic-curve Diffie-Hellman (ECDH) captured on the wire today is effectively accessible in the future.
Hybrid Key Exchange: The Bridge to Post-Quantum Security
Transitioning directly to pure post-quantum algorithms carries risk: these algorithms are newer, mathematically distinct (lattice-based), and have larger key sizes. If a theoretical vulnerability is discovered in ML-KEM tomorrow, relying exclusively on it would be reckless.
The industry solution is Hybrid Key Exchange (most notably X25519Kyber768 and X25519MLKEM768). In a hybrid handshake:
- The client and server perform a classical elliptic curve key exchange (
X25519). - Simultaneously, they perform a post-quantum key encapsulation (
ML-KEM-768). - The shared session secret is derived using a cryptographic KDF from both exchanges combined.
An attacker must break both the classical elliptic curve math AND the post-quantum lattice problem to decrypt the session.
| Cryptographic Primitive | Classical Algorithm | Post-Quantum Standard (FIPS) | Hybrid Production Target | Public Key / Ciphertext Overhead |
|---|---|---|---|---|
| Key Encapsulation (KEM) | ECDH (X25519, NIST P-256) | ML-KEM (Kyber-768 / FIPS 203) | X25519Kyber768Draft00 / X25519MLKEM768 | Increases ClientHello by ~1,100 bytes |
| Digital Signatures | RSA-3072, Ed25519, ECDSA | ML-DSA (Dilithium / FIPS 204) | Hybrid X.509 Certificate Chains | Increases cert chain by ~2.5–5 KB |
| Symmetric Encryption | AES-128 | AES-256, ChaCha20-Poly1305 | AES-256-GCM | Minimal overhead (Grover's algorithm halves bits; 256 is quantum-safe) |
| Hash Functions | SHA-1, SHA-256 | SHA-384, SHA-512, SHA3 | SHA-384 / SHA-512 | Zero breaking changes |
Step 1: Enabling Hybrid Post-Quantum TLS 1.3 on Reverse Proxies
The fastest way to mitigate HNDL for web traffic and API endpoints is enabling post-quantum key exchange at your edge reverse proxy or CDN layer.
Cloudflare & AWS CloudFront
Both Cloudflare and AWS have introduced native support for hybrid post-quantum key agreement. On Cloudflare:
- Navigate to SSL/TLS → Edge Certificates.
- Enable Post-Quantum Cryptography. Cloudflare will automatically negotiate
X25519MLKEM768with supporting modern browsers (Chrome 124+, Firefox 132+, Edge).
NGINX with OpenSSL 3.2+ and OQS (Open Quantum Safe)
If you manage self-hosted ingress proxies or dedicated Linux VPS instances (see our guide on Linux server hardening), ensure your OpenSSL library supports hybrid groups:
# /etc/nginx/conf.d/security-ssl.conf
ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
# Enable hybrid X25519 + Kyber/ML-KEM key exchange groups
ssl_ecdh_curve X25519MLKEM768:X25519Kyber768Draft00:x25519:secp384r1;
# Ensure TLS session tickets are rotated frequently to limit replay windows
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
Verify your active TLS handshake from the terminal using OpenSSL 3.x:
openssl s_client -connect api.palmatesolutions.com:443 -tls1_3 -groups X25519MLKEM768
Look for the negotiated group output:
Negotiated Group: X25519MLKEM768 or X25519Kyber768Draft00.
Step 2: Post-Quantum SSH Bastions and Machine-to-Machine Access
SSH connections between developer laptops, CI/CD runners, and production cloud infrastructure are prime targets for wiretapping and credential exfiltration.
OpenSSH version 9.0+ introduced hybrid Streamlined NTRU Prime + X25519 ([email protected]) as the default key exchange mechanism.
Audit your /etc/ssh/sshd_config across all production instances:
# Enforce modern post-quantum hybrid KEX algorithms
KexAlgorithms [email protected],curve25519-sha256,[email protected]
# Enforce quantum-resistant symmetric ciphers
Ciphers [email protected],[email protected]
# Enforce secure MACs
MACs [email protected]
Then verify your client connects using hybrid post-quantum key exchange:
ssh -v [email protected]
The debug output should confirm:
kex: algorithm: [email protected]
Step 3: Upgrading Data-at-Rest Encryption (Symmetric Keys)
While asymmetric public-key cryptography (RSA/ECC) is completely broken by Shor's algorithm, symmetric cryptography (AES) is only weakened by Grover's algorithm, which quadratically speeds up brute-force searches.
- AES-128 offers 128 bits of classical security, but only 64 bits of post-quantum security—putting it within dangerous range of future quantum supercomputers.
- AES-256 offers 256 bits of classical security and 128 bits of post-quantum security—which remains cryptographically impenetrable against any physically realizable quantum machine.
Action Item: Audit all database tables, S3/GCS bucket encryption configurations, and backup archive scripts. Ensure all symmetric encryption keys are upgraded from AES-128 to AES-256-GCM or ChaCha20-Poly1305.
The Cryptographic Agility Audit Checklist
Implementing post-quantum defense does not require rebuilding your software from scratch. It requires cryptographic agility—the architectural ability to swap algorithms without breaking application code:
- Audit TLS reverse proxies and CDNs to enable hybrid
X25519MLKEM768key exchange. - Upgrade OpenSSH daemons to version 9.0+ and verify
sntrup761x25519-sha512is preferred. - Confirm all data-at-rest keys and automated backup snapshots utilize
AES-256rather thanAES-128. - Verify that internal MTLS service meshes (such as Tailscale or WireGuard tunnels) are running up-to-date versions that incorporate post-quantum handshakes.
- Replace hardcoded cryptographic algorithms in application code with configurable cipher suites.
- Inspect internal JWT tokens and authentication headers with our JWT decoder to ensure signature algorithms adhere to modern standards.
If you need a comprehensive security and DevOps architecture audit, reach out to the engineering team at Palmate Solutions.