Post-Quantum Cryptography: Preparing Your Hosting TLS Stack for the Future

Quantum Computers Will Break Current Encryption — The Question Is When, Not If

The encryption that protects every HTTPS connection, every SSH session, and every VPN tunnel relies on mathematical problems that classical computers cannot solve efficiently: factoring large prime numbers (RSA) and computing discrete logarithms on elliptic curves (ECDH, ECDSA). Quantum computers, using Shor's algorithm, can solve these problems in polynomial time. When sufficiently powerful quantum computers exist, every TLS connection secured with current algorithms becomes breakable.

The timeline is debated — estimates range from five to fifteen years — but the threat is already real today through "harvest now, decrypt later" attacks: adversaries capture encrypted traffic now and store it, planning to decrypt it when quantum computers become available. For hosting platforms transmitting sensitive data, the transition to post-quantum cryptography is not a future concern. It is a current one.

What NIST Has Standardised

The National Institute of Standards and Technology (NIST) spent eight years evaluating post-quantum cryptographic algorithms through a public competition. The result is a set of standardised algorithms designed to resist both classical and quantum attacks:

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

Previously known as CRYSTALS-Kyber, ML-KEM is the primary standard for key exchange — the process that establishes shared encryption keys between a client and server at the start of a TLS connection. ML-KEM is based on the mathematical hardness of lattice problems, which are believed to be resistant to quantum attacks. It has been standardised as FIPS 203 and is already being deployed in TLS 1.3 by major browsers and servers.

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

Previously known as CRYSTALS-Dilithium, ML-DSA is the primary standard for digital signatures — used in TLS certificates, code signing, and authentication. Standardised as FIPS 204.

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

Previously known as SPHINCS+, SLH-DSA is a signature scheme based entirely on hash functions — making it a conservative, well-understood choice for environments that want minimal assumptions about mathematical hardness. Standardised as FIPS 205. Signatures are larger than ML-DSA, making it less suitable for bandwidth-constrained applications but attractive for high-assurance environments.

What Changes in TLS

Key Exchange

The most immediate change is the TLS handshake. Current TLS 1.3 connections use ECDH (Elliptic Curve Diffie-Hellman) for key exchange. Post-quantum TLS replaces this with ML-KEM or, during the transition period, a hybrid that combines ECDH and ML-KEM. The hybrid approach ensures that the connection is secure even if one of the two algorithms turns out to have a weakness — the connection is protected as long as either algorithm holds.

Larger Handshakes

Post-quantum algorithms produce larger keys and ciphertexts than their classical counterparts. An ML-KEM key exchange adds approximately 1 to 2 kilobytes to the TLS handshake compared to ECDH. This is negligible on modern connections but may affect environments with extreme latency sensitivity or constrained networks. In practice, the handshake overhead is a one-time cost per connection and does not affect bulk data transfer performance.

Certificate Signatures

TLS certificates are signed by Certificate Authorities (CAs). Post-quantum certificate signatures (ML-DSA or SLH-DSA) are larger than current RSA or ECDSA signatures. A certificate chain with post-quantum signatures adds several kilobytes to the TLS handshake. The CA ecosystem is beginning to support post-quantum signatures, but widespread deployment of post-quantum certificates will take longer than post-quantum key exchange because it requires coordination across the entire certificate infrastructure.

The Transition Timeline

Already Happening: Hybrid Key Exchange

Major browsers (Chrome, Firefox) and cloud providers already support hybrid post-quantum key exchange in TLS 1.3, combining X25519 (classical) with ML-KEM-768 (post-quantum). When both the client and server support it, the handshake automatically uses the hybrid mode. This is transparent to the user and the hosting operator — no configuration changes required if your TLS stack supports it.

Near-Term: Server-Side Enablement

Hosting customers need to ensure their TLS termination software (Nginx, Caddy, HAProxy, cloud load balancers) supports post-quantum key exchange. Recent versions of OpenSSL (3.2+) and BoringSSL include ML-KEM support. Check your TLS library version and update if necessary. Most managed hosting and CDN providers are handling this transparently.

Medium-Term: Certificate Transition

When Certificate Authorities begin issuing post-quantum certificates at scale, hosting customers will need to deploy these certificates on their servers. The transition will likely follow the pattern of the RSA-to-ECDSA transition: dual certificate deployment (serving both classical and post-quantum certificates) during the overlap period, eventually transitioning to post-quantum-only certificates.

What Hosting Customers Should Do Now

Inventory Your Cryptographic Usage

Identify every place your hosting stack uses cryptography: TLS connections (web servers, APIs, databases), SSH access, VPN tunnels, encrypted backups, signed tokens (JWT), and any application-level encryption. Each of these will eventually need to transition to post-quantum algorithms.

Update Your TLS Stack

Ensure you are running a TLS library that supports post-quantum key exchange:

• OpenSSL 3.2 or later with OQS (Open Quantum Safe) provider, or OpenSSL 3.5+ with built-in ML-KEM support.
• BoringSSL (used by Nginx in some distributions, and by Go) with post-quantum support enabled.
• Verify that your web server configuration does not restrict cipher suites or key exchange groups in a way that excludes post-quantum options.

Test Hybrid Key Exchange

Enable hybrid post-quantum key exchange on staging environments and verify that all clients (browsers, API consumers, mobile apps) can negotiate the connection successfully. Hybrid mode is backward-compatible — clients that do not support post-quantum fall back to classical key exchange — so the risk of enabling it is minimal.

Plan for Larger Handshakes

If your infrastructure includes components that are sensitive to TLS handshake size (embedded IoT devices, constrained networks, extremely latency-sensitive APIs), test the impact of the larger post-quantum handshake. For the vast majority of hosting workloads, the impact is negligible.

Monitor the CA Ecosystem

Watch for your Certificate Authority's announcements about post-quantum certificate support. When they begin issuing post-quantum certificates, plan to test and deploy them on your infrastructure.

SSH and Other Protocols

TLS is the most visible protocol to transition, but SSH, VPN (IPsec, WireGuard), and application-level encryption also need attention:

• OpenSSH: Already supports hybrid post-quantum key exchange using sntrup761 combined with X25519. Enable it in your SSH configuration for forward-secure connections.
• VPN: WireGuard and IPsec implementations are adding post-quantum key exchange support. Monitor updates for your VPN solution.
• Application encryption: If your application encrypts data at rest or in transit using RSA or ECDH key exchange, plan the transition to post-quantum key exchange for these use cases as library support matures.

The Bottom Line

Post-quantum cryptography is not a future problem — the standards are published, the browser support is shipping, and the "harvest now, decrypt later" threat applies to traffic on the wire today. For hosting customers, the transition starts with updating your TLS stack to support hybrid post-quantum key exchange, which is already available and backward-compatible. The certificate transition will follow. The time to prepare is now, while the transition can be gradual and low-risk — not later, when it becomes urgent and chaotic.