QTLS: Building Quantum-Safe TLS for the Post-Quantum Era

Post Quantum Cryptography

---

Introduction

TLS protects virtually every Internet transaction — web browsing, API calls, email, financial settlement, IoT telemetry, and cloud-to-cloud traffic. When cryptographically relevant quantum computers (CRQCs) arrive, every classical TLS session becomes vulnerable: Shor’s algorithm breaks ECDHE key exchange in polynomial time, and Grover’s algorithm weakens symmetric ciphers.

Quantum-safe TLS (QTLS) is the umbrella term for TLS configurations that resist both classical and quantum attacks. It encompasses post-quantum key encapsulation mechanisms (KEMs) for key exchange, post-quantum digital signatures for authentication, and hybrid constructions that combine classical and post-quantum primitives during the transition period.

This post provides a structured walkthrough — from the threat model that motivates QTLS, through the standards landscape, to a practical deployment using hybrid certificates.

---

1. Why QTLS?

1.1 TLS Is the Single Largest Attack Surface

TLS is the most widely deployed cryptographic protocol in history. Every HTTPS connection, every API gateway, every microservice mesh, every mobile app backend — all depend on TLS for confidentiality, integrity, and authentication.

Fig 1. Classical TLS vs Quantum-Safe TLS. The asymmetric components — key exchange and authentication — are the quantum-vulnerable elements. QTLS replaces them with post-quantum primitives while retaining the proven symmetric layer.

The scale of the exposure is immense:

Protocol Use	Estimated Daily Volume	At Risk
HTTPS connections	~4.5 billion	Key exchange + authentication
API calls (cloud)	~50 billion	Key exchange + authentication
IoT telemetry (TLS/DTLS)	~15 billion	Key exchange + authentication
Email (STARTTLS)	~300 billion messages/day	Key exchange + authentication
Financial settlement (mTLS)	~2 billion	Key exchange + mutual auth

Every one of these sessions uses ephemeral ECDHE or RSA key exchange. Every one is vulnerable to a future CRQC.

1.2 Forward Secrecy Is Not Enough

TLS 1.3 mandates forward secrecy through ephemeral key exchange — compromising a long-term key does not compromise past sessions. But forward secrecy only protects against classical attackers. An adversary running Shor’s algorithm can recover the ephemeral ECDHE shared secret from the recorded key exchange, breaking forward secrecy retroactively.

Fig 2. Forward secrecy under quantum attack. Even though TLS 1.3 uses ephemeral ECDHE keys, a quantum adversary can recover those ephemeral secrets from recorded transcripts, retroactively breaking every session.

This is why QTLS is not optional — it is the only way to preserve confidentiality guarantees for TLS traffic that is recorded today and may be decrypted tomorrow.

1.3 Authentication Is Also at Stake

Beyond key exchange, TLS relies on digital signatures for server (and optionally client) authentication. RSA and ECDSA signatures are both broken by Shor’s algorithm. A quantum-capable active adversary could:

• Forge certificates — impersonate any server by forging signatures on fabricated certificates
• Perform real-time MITM — intercept, decrypt, modify, re-encrypt, and re-sign traffic on the fly
• Undermine code signing — distribute malicious software updates with forged signatures

QTLS must address both key exchange and authentication to be considered complete.

---

2. Threat Model and Risks

2.1 Adversary Classification

The quantum threat to TLS manifests differently depending on adversary capabilities and timing.

Fig 3. Quantum adversary classification for TLS. The passive pre-quantum adversary (harvest now, decrypt later) is the most pressing threat because it operates today. Active CRQC attacks represent the eventual worst case.

2.2 Differential Risk: Key Exchange vs. Authentication

A critical insight for QTLS prioritization is that key exchange and authentication have fundamentally different risk profiles.

Fig 4. Differential risk assessment. Key exchange is the higher priority because HNDL attacks are retroactive, passive, and already underway. Authentication compromise requires a real-time CRQC, making it a slightly deferred — but still critical — priority.

2.3 Downgrade and Interoperability Risks

Deploying QTLS introduces new attack surfaces that must be addressed:

Risk	Description	Mitigation
Algorithm downgrade	Attacker forces negotiation to classical-only cipher suite	Enforce minimum PQ-inclusive policy; reject classical-only handshakes for sensitive endpoints
Hybrid mismatch	Client and server disagree on hybrid construction	Standardized hybrid KEM combiners (IETF draft-ietf-tls-hybrid-design)
Key size amplification	ML-KEM-1024 public keys are ~1,568 bytes vs ECDHE’s ~32 bytes	Use TLS 1.3 key_share extension; consider certificate compression (RFC 8879)
Signature bloat	ML-DSA-87 signatures are ~4,627 bytes	Certificate chain optimization; hybrid certs with compact classical fallback
Implementation bugs	New PQ code has less cryptanalysis exposure	Use NIST-validated implementations; run interoperability test suites

---

3. The NIST Position on Hybrid Key Establishment and Authentication

3.1 NIST SP 800-227: Recommendations for Key Encapsulation Mechanisms

NIST’s position on post-quantum transition is documented across several publications. SP 800-227 (November 2025) provides the definitive guidance on key encapsulation mechanisms and hybrid constructions.

Fig 5. NIST's hybrid key establishment model. A Key Derivation Function combines the post-quantum shared secret (from ML-KEM) with the classical shared secret (from ECDH), ensuring the combined key is at least as strong as the stronger component.

The key principles from NIST SP 800-227:

1. ML-KEM is the primary recommendation — ML-KEM-768 for 128-bit security, ML-KEM-1024 for 192-bit
2. Hybrid key establishment is approved — combining ML-KEM with ECDH during the transition period
3. The combiner must be cryptographically sound — use a KDF (e.g., HKDF-SHA-256) over the concatenation of both shared secrets plus a context string
4. Standalone ML-KEM is also acceptable — hybrid is not mandatory, but provides defense-in-depth during initial deployment
5. RSA key transport is deprecated for new systems — even for hybrid use

3.2 Authentication: A More Nuanced Position

NIST’s position on post-quantum authentication is more cautious than its stance on key establishment. This reflects a fundamental asymmetry in the threat model.

Fig 6. NIST's asymmetric position on key establishment vs authentication. Key establishment should transition immediately; authentication can follow as the PKI ecosystem matures, because authentication attacks require real-time quantum compute.

3.3 CNSA 2.0 Timeline

The NSA’s Commercial National Security Algorithm Suite 2.0 provides concrete deadlines for US national security systems:

Component	Algorithm	Requirement	Deadline
Software/firmware signing	ML-DSA-87	Prefer immediately	2025
Web servers/browsers (TLS)	ML-KEM-1024 + ML-DSA-87	Support by	2025
Key establishment	ML-KEM-1024	Exclusively by	2030
Digital signatures	ML-DSA-87 or SLH-DSA	Exclusively by	2035
Symmetric encryption	AES-256	Continue using	Ongoing
Hashing	SHA-384+	Continue using	Ongoing

These deadlines are aggressive. For organizations handling classified or sensitive government data, the transition window is already closing.

---

4. Standards Landscape

4.1 Get Oriented

The QTLS standards landscape is complex, with multiple bodies working in parallel. The following map shows how the key specifications relate to each other.

Fig 7. The QTLS standards landscape. Five layers of specifications — from NIST algorithm foundations through IETF protocol integration, PKI certificate standards, government guidance, and open-source implementations — must align for a complete QTLS deployment.

4.2 Key Standards in Detail

IETF TLS Working Group

The IETF is the primary venue for TLS protocol standardization. Two drafts are particularly relevant:

• draft-ietf-tls-hybrid-design — Defines how to negotiate hybrid key exchange in TLS 1.3. The combined key_share carries both a classical (e.g., X25519) and a post-quantum (e.g., ML-KEM-768) component. The shared secrets are combined via a KDF before deriving the session keys.

• draft-ietf-tls-mlkem — Registers specific ML-KEM (NamedGroup) code points for TLS 1.3. Defines mlkem768, mlkem1024, and hybrid groups x25519_mlkem768, secp384r1_mlkem1024.

IETF LAMPS Working Group

The Lightweight Authenticated Message Protocols (LAMPS) working group handles X.509 certificate extensions:

• draft-ounsworth-pq-composite-sigs — Defines composite signature algorithms that combine a classical and a PQ signature in a single X.509 certificate
• draft-ounsworth-pq-composite-kem — Composite KEM for CMS and certificate-based key establishment

ANSI X9.146

The X9.146 standard (discussed in Section 5) defines a hybrid certificate format specifically for the financial industry, where backward compatibility with existing infrastructure is paramount.

---

5. X9.146 Hybrid Certificates

5.1 The Problem Space

Transitioning TLS authentication to post-quantum algorithms faces a chicken-and-egg problem: servers cannot present PQ certificates until clients support them, and clients have no incentive to support them until servers present them. Hybrid certificates solve this by carrying both a classical and a post-quantum key pair in a single X.509 certificate.

5.2 Certificate Anatomy

Fig 8. Anatomy of an X9.146 hybrid certificate. The certificate carries dual key pairs and dual signatures — a classical ECDSA pair for backward compatibility and an ML-DSA pair for post-quantum security. Three X.509v3 extensions (SubjectAltPublicKeyInfo, AltSignatureAlgorithm, AltSignatureValue) carry the PQ components.

5.3 Validation Logic

A key design goal of X9.146 is backward compatibility: legacy clients that do not understand the PQ extensions simply ignore them and validate only the classical signature. PQ-aware clients validate both.

Fig 9. X9.146 validation flow. Legacy clients ignore the PQ extensions and validate only the classical ECDSA signature (left path). PQ-aware clients validate both signatures — if either fails, the certificate is rejected (right path). This dual-validation provides both backward compatibility and forward security.

5.4 Certificate Chain Considerations

Hybrid certificates affect the entire PKI chain — not just the end-entity certificate:

Chain Level	Classical Component	PQ Component	Combined Size
Root CA	ECDSA P-384 (self-signed)	ML-DSA-65 (self-signed)	~9 KB
Intermediate CA	ECDSA P-384	ML-DSA-65	~9 KB
End-entity	ECDSA P-384	ML-DSA-65	~8.5 KB
Full chain	~3.6 KB (classical)	~26.5 KB (hybrid)	~7.4× increase

The size increase is significant for constrained environments. Mitigations include:

• RFC 8879 TLS Certificate Compression — Brotli or zstd compression typically achieves 40-60% reduction
• Cached Information Extension (RFC 7924) — Avoid retransmitting previously seen certificates
• Certificate chain abbreviation — Omit the root certificate (clients already have it in their trust store)
• OCSP stapling — Avoid separate OCSP responder connections

---

6. Practical QTLS Setup

6.1 Deployment Architecture

Fig 10. QTLS deployment architecture. The QTLS server terminates hybrid TLS connections using OpenSSL 3.5 with the OQS provider. External-facing connections use ML-KEM + X25519 hybrid key exchange and X9.146 hybrid certificates. Internal connections can migrate in a later phase.

6.2 Step-by-Step Setup

The following walkthrough deploys a QTLS server with hybrid key exchange and hybrid certificates using the Open Quantum Safe (OQS) ecosystem.

Step 1: Build the Software Stack

# Install dependencies
sudo apt install build-essential cmake ninja-build git \
     libssl-dev python3

# Build liboqs
git clone https://github.com/open-quantum-safe/liboqs.git
cd liboqs && mkdir build && cd build
cmake -GNinja -DCMAKE_INSTALL_PREFIX=/opt/oqs \
      -DBUILD_SHARED_LIBS=ON ..
ninja && sudo ninja install

# Build OpenSSL 3.5 (if not already installed)
git clone https://github.com/openssl/openssl.git
cd openssl && git checkout openssl-3.5
./Configure --prefix=/opt/openssl3.5 shared
make -j$(nproc) && sudo make install

# Build oqs-provider
git clone https://github.com/open-quantum-safe/oqs-provider.git
cd oqs-provider && mkdir build && cd build
cmake -GNinja \
      -Dliboqs_DIR=/opt/oqs \
      -DOpenSSL_ROOT=/opt/openssl3.5 \
      -DCMAKE_INSTALL_PREFIX=/opt/oqs-provider ..
ninja && sudo ninja install

Step 2: Configure OpenSSL to Load the OQS Provider

# /opt/openssl3.5/ssl/openssl.cnf  (append or modify)

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
oqsprovider = oqs_sect

[default_sect]
activate = 1

[oqs_sect]
activate = 1
module = /opt/oqs-provider/lib/oqsprovider.so

Step 3: Generate the Hybrid Certificate Chain

Fig 11. Hybrid certificate chain generation. Each level generates both a classical (ECDSA P-384) and a post-quantum (ML-DSA-65) key pair. The hybrid flag in OpenSSL instructs the tool to embed both keys and signatures in each certificate.

The full commands for generating the certificate chain:

export OPENSSL=/opt/openssl3.5/bin/openssl
export OPENSSL_CONF=/opt/openssl3.5/ssl/openssl.cnf

# --- Root CA ---
$OPENSSL genpkey -algorithm ec \
    -pkeyopt ec_paramgen_curve:P-384 -out root-classical.key
$OPENSSL genpkey -algorithm mldsa65 -out root-pq.key
$OPENSSL req -x509 -new -days 3650 \
    -key root-classical.key \
    -subj "/CN=QTLS Demo Root CA/O=PayZen Security" \
    -addext "basicConstraints=critical,CA:TRUE" \
    -addext "keyUsage=critical,keyCertSign,cRLSign" \
    -copy_extensions copyall \
    -out root.crt

# --- Intermediate CA ---
$OPENSSL genpkey -algorithm ec \
    -pkeyopt ec_paramgen_curve:P-384 -out inter-classical.key
$OPENSSL genpkey -algorithm mldsa65 -out inter-pq.key
$OPENSSL req -new -key inter-classical.key \
    -subj "/CN=QTLS Demo Intermediate CA/O=PayZen Security" \
    -out inter.csr
$OPENSSL x509 -req -days 1825 -in inter.csr \
    -CA root.crt -CAkey root-classical.key \
    -addext "basicConstraints=critical,CA:TRUE,pathlen:0" \
    -addext "keyUsage=critical,keyCertSign,cRLSign" \
    -copy_extensions copyall \
    -out inter.crt

# --- Server Certificate ---
$OPENSSL genpkey -algorithm ec \
    -pkeyopt ec_paramgen_curve:P-384 -out server-classical.key
$OPENSSL genpkey -algorithm mldsa65 -out server-pq.key
$OPENSSL req -new -key server-classical.key \
    -subj "/CN=server.example.com/O=PayZen Security" \
    -addext "subjectAltName=DNS:server.example.com,DNS:*.example.com" \
    -out server.csr
$OPENSSL x509 -req -days 365 -in server.csr \
    -CA inter.crt -CAkey inter-classical.key \
    -addext "keyUsage=critical,digitalSignature" \
    -addext "extendedKeyUsage=serverAuth" \
    -copy_extensions copyall \
    -out server.crt

# Verify the chain
$OPENSSL verify -CAfile root.crt -untrusted inter.crt server.crt

Step 4: Configure the QTLS Server (nginx)

# /etc/nginx/conf.d/qtls.conf

server {
    listen 443 ssl;
    server_name server.example.com;

    # Hybrid certificate chain
    ssl_certificate     /etc/nginx/certs/fullchain.pem;
    ssl_certificate_key /etc/nginx/certs/server-classical.key;

    # TLS 1.3 only (required for hybrid key exchange)
    ssl_protocols TLSv1.3;

    # Hybrid key exchange groups (PQ + classical)
    ssl_ecdh_curve x25519_mlkem768:secp384r1_mlkem1024:x25519:secp384r1;

    # Strong cipher suites
    ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;
    ssl_prefer_server_ciphers on;

    # OCSP stapling for performance
    ssl_stapling on;
    ssl_stapling_verify on;
    ssl_trusted_certificate /etc/nginx/certs/root.crt;

    # Certificate compression (reduces hybrid cert overhead)
    # Requires nginx compiled with Brotli support
    ssl_conf_command Options CompressCerts;

    location / {
        proxy_pass http://backend;
    }
}

Step 5: Test the Connection

# Test with the OQS-enabled OpenSSL client
$OPENSSL s_client -connect server.example.com:443 \
    -groups x25519_mlkem768 \
    -CAfile root.crt \
    -brief

# Expected output (key lines):
#   CONNECTION ESTABLISHED
#   Protocol version: TLSv1.3
#   Ciphersuite: TLS_AES_256_GCM_SHA384
#   Requested Signature Algorithms: ...mldsa65...
#   Peer certificate: CN=server.example.com
#   Server Temp Key: X25519MLKEM768

# Verify hybrid certificate content
$OPENSSL x509 -in server.crt -text -noout | \
    grep -E "Public Key Algorithm|Signature Algorithm"
# Should show both ECDSA and ML-DSA entries

# Test negotiation with curl (if compiled with OQS support)
curl --curves x25519_mlkem768 \
     --cacert root.crt \
     https://server.example.com/

6.3 QTLS Handshake Walkthrough

Fig 12. The QTLS 1.3 hybrid handshake. The ClientHello carries both X25519 and ML-KEM-768 key shares (~1,600 bytes). The server responds with its key share and ML-KEM ciphertext. Both sides derive a combined shared secret. The server presents an X9.146 hybrid certificate (~26.5 KB chain) with dual signatures for authentication. The handshake completes in a single round trip.

6.4 Performance Considerations

Hybrid QTLS introduces measurable overhead compared to classical TLS:

Metric	Classical TLS 1.3	Hybrid QTLS	Delta
ClientHello size	~300 B	~1,600 B	+1,300 B
ServerHello size	~120 B	~1,120 B	+1,000 B
Certificate chain	~3.6 KB	~26.5 KB	+22.9 KB
Handshake latency	~1.0 ms	~1.3 ms	+30%
KEM operations	~0.05 ms	~0.15 ms	+0.1 ms
Signature verify	~0.08 ms	~0.35 ms	+0.27 ms
First-byte time	~1.2 ms	~1.8 ms	+50%

The overhead is concentrated in the handshake. Once session keys are derived, bulk encryption performance is identical (AES-256-GCM throughput is unchanged). For most applications, the additional ~0.6 ms per handshake is negligible.

For latency-sensitive environments, consider:

• TLS session resumption — avoids full handshake for returning clients
• 0-RTT early data — sends application data alongside ClientHello (with replay protection)
• Certificate compression (RFC 8879) — reduces the 26.5 KB chain to ~12-15 KB
• Connection pooling — reduces handshake frequency for backend services

6.5 Monitoring and Validation

After deploying QTLS, establish ongoing monitoring:

# Verify the negotiated key exchange group
$OPENSSL s_client -connect server.example.com:443 \
    -groups x25519_mlkem768 -brief 2>&1 | \
    grep "Server Temp Key"
# Expected: Server Temp Key: X25519MLKEM768

# Check certificate algorithms
$OPENSSL s_client -connect server.example.com:443 \
    -groups x25519_mlkem768 2>&1 | \
    $OPENSSL x509 -noout -text | \
    grep -A1 "Public Key Algorithm"
# Expected: ECDSA  AND  ML-DSA-65

# Test fallback behavior (classical-only client)
openssl s_client -connect server.example.com:443 \
    -groups x25519 -brief 2>&1 | \
    grep "Server Temp Key"
# Expected: Server Temp Key: X25519 (graceful fallback)

# Monitor handshake performance
curl -w "time_connect: %{time_connect}\n\
time_appconnect: %{time_appconnect}\n\
time_starttransfer: %{time_starttransfer}\n" \
    --curves x25519_mlkem768 \
    --cacert root.crt \
    -o /dev/null -s https://server.example.com/

---

7. Migration Path

7.1 Phased Approach

Fig 13. The four-phase migration path from classical TLS to full QTLS. Phase 1 (hybrid key exchange) should begin immediately as it addresses the HNDL threat and requires no PKI changes. Subsequent phases progressively replace classical components with post-quantum alternatives.

7.2 Decision Matrix

Factor	Phase 1 (Hybrid KEM)	Phase 2 (Hybrid Cert)	Phase 3 (PQ-Only KEM)	Phase 4 (Full PQ)
HNDL protection	✓	✓	✓	✓
Auth forgery protection	✗	✓ (hybrid)	✗	✓
Backward compatible	✓	✓	✗	✗
CA changes required	✗	✓	✗	✓
CNSA 2.0 compliant	Partial	Partial	KEM-only	Full
Implementation maturity	Production	Early adoption	Planned	Future

---

Conclusion

QTLS is not a future concern — it is a present-day engineering task. The HNDL threat makes every TLS session recorded today a liability for the post-quantum future. The path forward is clear:

1. Deploy hybrid key exchange immediately — ML-KEM + X25519 protects confidentiality against harvest-now-decrypt-later attacks with minimal disruption
2. Prepare for hybrid certificates — X9.146 enables backward-compatible PQ authentication; begin testing now
3. Track the standards — IETF, NIST, and CNSA 2.0 deadlines are converging; the window for orderly migration is closing
4. Build crypto-agility — architect systems to swap algorithms without re-engineering, because quantum migration is only the beginning of continuous cryptographic lifecycle management

The tooling exists. The standards are maturing. The only remaining variable is organizational will.

---

This post is part of the Post-Quantum Cryptography series on PayZen Cybersecurity. For migration strategy details beyond TLS, see PQC Migration: A Comprehensive Strategy Guide.