Implementing Post-Quantum TLS:
A Practical Guide

TLS (Transport Layer Security) protects the vast majority of internet communications. Adding post-quantum security to TLS is one of the most impactful steps organizations can take to prepare for the quantum era. This guide walks through practical implementation approaches.

Understanding TLS Key Exchange

TLS uses key exchange algorithms to establish shared secrets between clients and servers. Currently, most TLS connections use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), which is vulnerable to quantum attacks. Specifically, Shor's algorithm can solve the Elliptic Curve Discrete Logarithm Problem (ECDLP) in polynomial time on a sufficiently large quantum computer, reducing what is currently a ~128-bit security problem to something trivially breakable.

Post-quantum TLS replaces or augments this with quantum-resistant key encapsulation mechanisms like Kyber (now standardized as ML-KEM under FIPS 203). Unlike Diffie-Hellman, which relies on the computational hardness of discrete logarithms, ML-KEM is built on the Module Learning With Errors (MLWE) problem -- a lattice-based assumption for which no efficient quantum algorithm is known.

Hybrid Key Exchange

The recommended approach during the transition period is hybrid key exchange, combining both classical and post-quantum algorithms:

In hybrid mode, both X25519 (classical) and Kyber-768 (post-quantum) key exchanges occur, with the results combined to derive the session key. The combined shared secret is computed as HKDF(X25519_ss || Kyber_ss), meaning both algorithms must be independently compromised for the session key to be recovered. This is a strictly additive security model -- the hybrid is at least as strong as the stronger of the two components.

How ML-KEM Works in a TLS Handshake

In a standard TLS 1.3 handshake with hybrid key exchange, the client and server perform the following steps during the ClientHello and ServerHello exchange:

The total additional bandwidth cost is approximately 2.2 KB per handshake (1,184-byte encapsulation key + 1,088-byte ciphertext), compared to 32 bytes for X25519 alone. This is a non-trivial increase, but it occurs only once per connection establishment -- not per request.

Server-Side Implementation

For web servers, post-quantum TLS support is becoming available in major platforms:

# Nginx with OpenSSL 3.2+
ssl_protocols TLSv1.3;
ssl_ecdh_curve X25519Kyber768:X25519:prime256v1;

# Or using groups directive
ssl_conf_command Groups X25519Kyber768:X25519;

# Apache with OpenSSL 3.2+
SSLOpenSSLConfCmd Groups X25519Kyber768:X25519
SSLProtocol -all +TLSv1.3

The X25519Kyber768 group implements hybrid key exchange, combining X25519 with Kyber-768. Order matters in the group list -- place the hybrid group first so servers prefer it when clients support it, falling back to classical X25519 for older clients.

Client Support

Major browsers have begun supporting post-quantum TLS:

• Chrome: Supports X25519Kyber768 since version 124
• Firefox: Experimental support available
• Safari: Support expected in upcoming releases

For programmatic clients, updated TLS libraries are required:

// Node.js with updated OpenSSL
const https = require('https');
const options = {
  hostname: 'api.h33.ai',
  port: 443,
  secureProtocol: 'TLSv1_3_method'
  // Kyber negotiated automatically if server supports
};

Performance Considerations

Hybrid post-quantum TLS has modest performance impacts:

• Bandwidth: ~2.2KB additional per handshake (ML-KEM encapsulation key + ciphertext)
• Latency: ~0.1ms additional computation for key encapsulation/decapsulation
• CPU: Minimal impact with optimized implementations

For most applications, these impacts are negligible. High-frequency trading or extremely latency-sensitive applications may need careful testing.

Testing Your Implementation

Verify post-quantum support is working:

# Using openssl s_client
openssl s_client -connect yourserver.com:443 -groups X25519Kyber768

# Check the negotiated group in output
# Should show: Server Temp Key: X25519Kyber768

# Verify with curl (OpenSSL 3.2+ build)
curl -vvv --tls13-ciphers TLS_AES_256_GCM_SHA384 \
     --curves X25519Kyber768 https://yourserver.com/

# Programmatic validation with Python
python3 -c "
import ssl, socket
ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.set_ciphers('TLS_AES_256_GCM_SHA384')
with ctx.wrap_socket(socket.socket(), server_hostname='yourserver.com') as s:
    s.connect(('yourserver.com', 443))
    print('Cipher:', s.cipher())
    print('Version:', s.version())
"

Certificate Considerations

Note that post-quantum TLS key exchange doesn't affect certificates (yet). Server certificates still use classical signatures (RSA or ECDSA). Post-quantum certificate signatures are a separate, ongoing standardization effort under IETF and the CA/Browser Forum.

The distinction is important: key exchange protects the confidentiality of session data, while certificate signatures protect authentication (proving the server is who it claims to be). A quantum adversary with a sufficiently large quantum computer could forge classical certificate signatures, enabling man-in-the-middle attacks. But key exchange is the more urgent migration target because of harvest-now-decrypt-later -- stolen ciphertext is already at risk, whereas certificate forgery requires a quantum computer to be available at the time of the attack.

For organizations that need post-quantum authentication today, Dilithium (ML-DSA) signatures provide FIPS 204-compliant digital signatures with ~244 microsecond sign-and-verify latency. H33 uses Dilithium as the attestation layer in its production authentication pipeline, signing batch proofs covering 32 users per signature operation.

Rollout Strategy

A phased rollout minimizes risk:

• Phase 1: Enable on development/staging environments. Run regression suites against PQ-enabled endpoints. Confirm that middleboxes (load balancers, WAFs, CDN edge nodes) do not strip or reject the larger ClientHello.
• Phase 2: Deploy to a subset of production traffic (5-10%). Monitor handshake failure rates, latency p99, and connection reuse ratios.
• Phase 3: Expand to 50%, then 100%. Track certificate validation errors and client compatibility issues.
• Phase 4: Full production deployment with alerting on any fallback to classical-only key exchange.

Post-quantum TLS is production-ready today. With hybrid key exchange, you can add quantum resistance while maintaining full compatibility with existing clients. Start your implementation now to protect your users' data against future quantum threats.