Hybrid Cryptography Deployment Guide: Classical + PQC Transition Strategy

Why Hybrid Cryptography Is the Recommended Transition Strategy

The post-quantum cryptography transition presents a unique engineering challenge: organizations must protect against future quantum attacks (requiring PQC algorithms) while maintaining protection against current classical attacks (requiring well-tested classical algorithms). Hybrid cryptography solves both problems simultaneously.

A hybrid approach combines a classical algorithm (like X25519 or ECDSA) with a post-quantum algorithm (like ML-KEM or ML-DSA) such that both must be broken to compromise the system. This provides:

• Protection against quantum computers: The PQC component resists quantum attacks
• Protection against undiscovered PQC weaknesses: The classical component provides proven security if the PQC algorithm has a flaw
• Backward safety: If ML-KEM is broken by classical means (unlikely but possible with new algorithms), X25519 still protects you
• Forward safety: When quantum computers break X25519, ML-KEM still protects you

Every major standards body and government agency recommends hybrid deployment as the transition strategy: NIST, NSA (CNSA 2.0), BSI (Germany), ANSSI (France), and NCSC (UK) all endorse hybrid approaches.

Hybrid Key Exchange: How It Works

The Fundamental Pattern

In hybrid key exchange, both a classical and a post-quantum key exchange are performed simultaneously, and the resulting shared secrets are combined:

Client                                    Server
  │                                         │
  ├─── X25519 ephemeral public key ────────►│
  ├─── ML-KEM-768 encapsulation key ───────►│
  │                                         │
  │◄──── X25519 ephemeral public key ───────┤
  │◄──── ML-KEM-768 ciphertext ────────────┤
  │                                         │
  │  Classical shared secret: ss_x25519     │  Classical shared secret: ss_x25519
  │  PQC shared secret: ss_mlkem           │  PQC shared secret: ss_mlkem
  │                                         │
  │  Combined: KDF(ss_x25519 || ss_mlkem)   │  Combined: KDF(ss_x25519 || ss_mlkem)
  │                                         │
  └──── Encrypted session (AES-256-GCM) ───┘

The combined shared secret is derived using a Key Derivation Function (KDF) that takes both shared secrets as input. An attacker must break both X25519 and ML-KEM to recover the session key.

TLS 1.3 Hybrid Key Exchange

In TLS 1.3, hybrid key exchange is implemented using named groups. The IETF has defined hybrid key exchange groups that combine classical and post-quantum components:

Hybrid Group	Classical	Post-Quantum	Combined Key Share Size
X25519MLKEM768	X25519 (32 bytes)	ML-KEM-768 (1,184 bytes)	1,216 bytes (client)
SecP256r1MLKEM768	ECDH P-256 (65 bytes)	ML-KEM-768 (1,184 bytes)	1,249 bytes (client)
X25519MLKEM1024	X25519 (32 bytes)	ML-KEM-1024 (1,568 bytes)	1,600 bytes (client)
SecP384r1MLKEM1024	ECDH P-384 (97 bytes)	ML-KEM-1024 (1,568 bytes)	1,665 bytes (client)

For comparison, a classical X25519-only key share is 32 bytes. The hybrid approach adds approximately 1.1-1.6 KB to the TLS ClientHello.

The TLS 1.3 Handshake with Hybrid Key Exchange

Client                                         Server
  │                                              │
  │──── ClientHello ────────────────────────────►│
  │     supported_groups: [X25519MLKEM768,       │
  │                        X25519, SecP256r1]    │
  │     key_share: X25519MLKEM768               │
  │       - x25519_public (32 bytes)             │
  │       - mlkem768_encaps_key (1,184 bytes)    │
  │                                              │
  │◄──── ServerHello ───────────────────────────┤
  │      selected_group: X25519MLKEM768          │
  │      key_share:                              │
  │        - x25519_public (32 bytes)            │
  │        - mlkem768_ciphertext (1,088 bytes)   │
  │                                              │
  │  [Both derive combined shared secret]        │
  │  [Handshake continues with derived keys]     │
  │                                              │
  │◄──── EncryptedExtensions ───────────────────┤
  │◄──── Certificate ──────────────────────────┤
  │◄──── CertificateVerify ────────────────────┤
  │◄──── Finished ─────────────────────────────┤
  │──── Finished ──────────────────────────────►│
  │                                              │
  └───── Application Data (protected) ──────────┘

The hybrid exchange adds approximately 2.3 KB to the combined ClientHello + ServerHello compared to X25519-only. In practice, this means the handshake still completes within a single TCP round-trip in most configurations.

Browser and Client Support Status (2026)

Current Deployment

Client	Hybrid Support	Default Status	Group Supported
Chrome 131+	✓	Enabled by default	X25519MLKEM768
Edge 131+	✓	Enabled by default	X25519MLKEM768
Firefox 132+	✓	Enabled by default	X25519MLKEM768
Safari 18+	✓	Enabled by default	X25519MLKEM768
curl 8.9+	✓	Via —curves flag	X25519MLKEM768
OpenSSL 3.4+ s_client	✓	Configurable	Multiple
Java 24+	✓	Configurable	X25519MLKEM768
Go 1.23+	✓	Enabled by default	X25519MLKEM768
.NET 9+	✓	Configurable	X25519MLKEM768

As of mid-2026, all major browsers ship with hybrid key exchange enabled by default. Over 30% of TLS connections on the public internet already use hybrid key exchange — making this the fastest cryptographic transition in internet history.

Server-Side Support

Server/Platform	Hybrid Support	Configuration
Cloudflare	✓ (all plans)	Enabled by default
AWS ALB/CloudFront	✓	Configurable security policy
Google Cloud Load Balancer	✓	Enabled by default
Azure Front Door	✓	Preview/GA depending on region
Nginx (with OpenSSL 3.4+)	✓	ssl_ecdh_curve directive
Apache (with OpenSSL 3.4+)	✓	SSLOpenSSLConfCmd Curves
HAProxy 3.0+	✓	ssl-default-bind-curves
Caddy 2.8+	✓	Via Go’s native support

Implementation Guide: OpenSSL 3.x

Enabling Hybrid Key Exchange in OpenSSL

OpenSSL 3.4+ supports hybrid key exchange natively with the OQS provider:

# Install oqs-provider (if not already included)
# Most Linux distributions now include this in OpenSSL packages

# Verify PQC algorithm availability
openssl list -kem-algorithms | grep -i mlkem

# Test hybrid key exchange with s_client
openssl s_client -connect example.com:443 -groups X25519MLKEM768

Nginx Configuration

server {
    listen 443 ssl;
    server_name example.com;
    
    ssl_certificate /etc/ssl/certs/server.crt;
    ssl_certificate_key /etc/ssl/private/server.key;
    
    # Enable hybrid PQC key exchange (prefer hybrid, fall back to classical)
    ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;
    
    # TLS 1.3 only for hybrid support
    ssl_protocols TLSv1.3;
    
    # Cipher suites for TLS 1.3 (key exchange is separate from ciphers in 1.3)
    ssl_conf_command CipherSuites TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256;
}

Apache Configuration

<VirtualHost *:443>
    ServerName example.com
    
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/server.crt
    SSLCertificateKeyFile /etc/ssl/private/server.key
    
    # Enable hybrid PQC groups
    SSLOpenSSLConfCmd Groups X25519MLKEM768:X25519:prime256v1
    
    # Enforce TLS 1.3
    SSLProtocol -all +TLSv1.3
</VirtualHost>

HAProxy Configuration

frontend https_frontend
    bind *:443 ssl crt /etc/ssl/server.pem curves X25519MLKEM768:X25519 alpn h2,http/1.1
    
    # Log which key exchange was negotiated
    http-response set-header X-Key-Exchange %[ssl_fc_curve]

Implementation Guide: BoringSSL (Google)

BoringSSL, used by Chrome and Google’s infrastructure, has native ML-KEM support:

// BoringSSL hybrid key exchange configuration
#include <openssl/ssl.h>

SSL_CTX *ctx = SSL_CTX_new(TLS_method());

// Set supported groups with hybrid preference
static const int kGroups[] = {
    NID_X25519MLKEM768,  // Hybrid: X25519 + ML-KEM-768
    NID_X25519,           // Fallback: classical X25519
    NID_secp256r1,        // Fallback: classical P-256
};
SSL_CTX_set1_groups(ctx, kGroups, sizeof(kGroups) / sizeof(kGroups[0]));

Implementation Guide: Go

Go 1.23+ supports hybrid key exchange in its standard library:

package main

import (
    "crypto/tls"
    "net/http"
)

func main() {
    tlsConfig := &tls.Config{
        MinVersion: tls.VersionTLS13,
        // Go 1.23+ automatically enables X25519MLKEM768
        // No explicit configuration needed for default behavior
        CurvePreferences: []tls.CurveID{
            tls.X25519MLKEM768, // Hybrid PQC
            tls.X25519,         // Classical fallback
        },
    }
    
    server := &http.Server{
        Addr:      ":443",
        TLSConfig: tlsConfig,
    }
    
    server.ListenAndServeTLS("cert.pem", "key.pem")
}

Hybrid Signatures: The Next Phase

While hybrid key exchange is widely deployed, hybrid signatures are earlier in their adoption lifecycle. Hybrid signatures combine a classical signature (ECDSA or RSA) with a post-quantum signature (ML-DSA) in certificates and protocol authentication.

Why Hybrid Signatures Are More Complex

Challenge	Key Exchange	Signatures
Size impact	~1.2 KB added per handshake	~5-8 KB added per certificate in chain
Chain effect	Single exchange per session	Multiple signatures verified (root → intermediate → leaf)
Legacy support	Graceful negotiation	Certificate must be understood by all verifiers
Deployment	Server-side change	Requires CA ecosystem changes
Standards maturity	RFC-track	Early drafts

Composite Signature Approaches

Two approaches exist for hybrid signatures in X.509 certificates:

1. Composite Certificates (Single cert, two signatures)

Certificate:
  Subject: example.com
  Public Key: Composite(ECDSA-P256 + ML-DSA-65)
  Signature Algorithm: Composite(ECDSA-P256 + ML-DSA-65)
  Signature Value: ECDSA_sig || ML-DSA_sig

2. Dual Certificate Chains (Separate classical and PQC chains)

Chain 1 (Classical): RSA Root → RSA Intermediate → ECDSA Leaf
Chain 2 (PQC):       ML-DSA Root → ML-DSA Intermediate → ML-DSA Leaf

Server presents both; client verifies whichever it supports

Current Status of Hybrid Signatures

• IETF Drafts: draft-ounsworth-pq-composite-sigs and draft-ounsworth-pq-composite-kem are progressing
• CA Support: DigiCert and Entrust have issued test hybrid certificates
• Browser Support: Experimental in Chrome (behind flags), not yet default
• Timeline: Broad deployment expected 2027-2028

Performance Overhead Analysis

TLS Handshake Latency Impact

Measured overhead of hybrid X25519+ML-KEM-768 vs. X25519-only:

Metric	X25519 Only	X25519+ML-KEM-768	Overhead
ClientHello size	~300 bytes	~1,500 bytes	+1,200 bytes
ServerHello size	~100 bytes	~1,200 bytes	+1,100 bytes
Total handshake bytes	~5 KB	~7.3 KB	+2.3 KB
Handshake latency (LAN)	1.2 ms	1.3 ms	+0.1 ms
Handshake latency (100ms RTT)	102 ms	102.5 ms	+0.5 ms
CPU time (server)	0.15 ms	0.19 ms	+0.04 ms
Connections/sec (single core)	6,500	5,200	-20%

Key Observations

• Latency overhead is negligible: The additional computation time (~40-80 μs) is invisible compared to network RTT
• Bandwidth is the main cost: +2.3 KB per handshake matters for high-volume servers and constrained networks
• CPU overhead is manageable: ~20% reduction in max connections/second per core — solved by existing capacity margins or modest scaling
• MTU fragmentation: The larger ClientHello may cause TCP fragmentation, adding one packet to the handshake in some network configurations

When Performance Becomes a Concern

Hybrid cryptography performance is a non-issue for most deployments but may need attention in:

• IoT/constrained devices: Low-power devices with limited bandwidth and CPU
• High-frequency trading: Where microseconds of latency matter
• Very high connection rates: Servers handling 100K+ new TLS connections per second
• Satellite/high-latency networks: Where additional packet from fragmentation doubles already-high RTT

For these cases, benchmark your specific deployment before and after enabling hybrid.

Deployment Strategy: Phased Rollout

Phase 1: Enable Hybrid on Edge/CDN (Week 1-4)

Start with your outermost TLS termination points:

1. Enable X25519MLKEM768 as the preferred group on CDN/load balancers
2. Keep X25519 and P-256 as fallback groups
3. Monitor: connection success rate, handshake latency, error rates
4. Verify: Check that clients negotiating hybrid actually complete handshakes

Phase 2: Enable Hybrid on Application Servers (Week 4-8)

Extend to internal TLS:

1. Update OpenSSL/BoringSSL configuration on application servers
2. Enable hybrid for server-to-server (east-west) traffic
3. Monitor: Internal service latency, throughput metrics
4. Verify: All internal services successfully negotiate hybrid

Phase 3: Enable Hybrid for VPN/IPsec (Week 8-16)

Extend to network-layer encryption:

1. Update VPN concentrators to support PQC key exchange in IKEv2
2. Deploy hybrid IKE_SA_INIT with ML-KEM
3. Monitor: Tunnel establishment time, rekey performance
4. Verify: Site-to-site and remote access VPNs negotiate PQC

Phase 4: Monitoring and Optimization (Ongoing)

1. Track hybrid negotiation rates across all connection types
2. Identify connections still using classical-only (legacy clients, misconfigured services)
3. Address edge cases: middleboxes that strip large ClientHello, broken TLS implementations
4. Plan timeline for eventual removal of classical-only fallback

Common Deployment Challenges

Middlebox Interference

Some network middleboxes (firewalls, DPI devices, TLS inspectors) may not handle the larger ClientHello:

• Symptom: Connections fail for some clients, succeed from others
• Cause: Middlebox drops or truncates oversized ClientHello
• Solution: Update middlebox firmware; as a workaround, allow fallback to classical groups

Client Compatibility

A small percentage of TLS clients may not support the hybrid groups:

• Solution: Always include classical groups (X25519, P-256) as fallback
• Monitoring: Track which group is actually negotiated per connection
• Timeline: Classical fallback can be removed once <0.1% of traffic uses classical-only

Certificate Size (Hybrid Signatures)

When deploying hybrid signatures (future):

• TLS max handshake size: Consider MaxFragmentLength extension or Certificate Compression
• OCSP stapling: Larger certificates mean larger OCSP responses
• CT logs: Certificate Transparency logs must handle larger certificates
• Certificate stores: Client certificate stores must accommodate larger certificates

When to Move from Hybrid to Pure PQC

Hybrid is the transition strategy, not the end state. Organizations should plan to eventually deploy pure PQC:

Conditions for Removing Classical Component

Condition	Target
PQC algorithms have 5+ years of public scrutiny without breaks	2029+
FIPS 140-3 validation complete for PQC implementations	2027+
All clients in your ecosystem support PQC	Depends on client base
CNSA 2.0 mandates pure PQC	2033 (key establishment), 2035 (signatures)
Confidence in PQC security assumptions is high	Ongoing assessment

CNSA 2.0 Timeline

• By 2030: Prefer PQC for key establishment (hybrid acceptable)
• By 2033: Exclusively use PQC for key establishment (remove classical)
• By 2035: Exclusively use PQC for digital signatures

For most commercial organizations, maintaining hybrid until 2030-2033 is the prudent approach — removing the classical component only after years of successful PQC deployment and broad ecosystem maturity.

Monitoring Hybrid Deployment with QCecuring CBOM

QCecuring CBOM provides essential visibility during hybrid deployment:

• Hybrid negotiation tracking: Monitors which connections successfully negotiate hybrid vs. fall back to classical
• Coverage dashboard: Shows percentage of connections using hybrid key exchange across your infrastructure
• Failure detection: Identifies connections that fail when hybrid is enabled (middlebox issues, incompatible clients)
• Algorithm inventory: Verifies that classical-only connections are limited to expected legacy systems
• Compliance mapping: Tracks progress against CNSA 2.0 hybrid deployment milestones
• Regression alerting: Notifies when a previously hybrid-enabled endpoint reverts to classical-only

Without continuous monitoring, organizations cannot verify that their hybrid deployment actually achieves the intended protection across all connection types.

Key Takeaways

• Hybrid is the universally recommended transition strategy — every major standards body endorses combining classical + PQC during the transition period
• Hybrid key exchange is already widely deployed — major browsers and cloud providers enabled X25519+ML-KEM-768 by default in 2024-2025
• Performance overhead is minimal — ~0.1 ms additional latency on LAN, ~2.3 KB additional handshake data
• Implementation is straightforward — a single configuration line in Nginx, Apache, or HAProxy enables hybrid
• Hybrid signatures are the next frontier — more complex than key exchange due to certificate chain size, expected broad deployment in 2027-2028
• Always include classical fallback groups — ensures compatibility with clients that don’t yet support hybrid
• Monitor middlebox interference — some network devices may drop oversized ClientHello messages
• Plan for eventual pure PQC — hybrid is the transition strategy, with CNSA 2.0 mandating pure PQC by 2033-2035
• QCecuring CBOM tracks hybrid deployment coverage — verifying that all connections achieve quantum-safe key exchange
• Every day without hybrid adds to HNDL exposure — hybrid key exchange stops the harvest of decryptable data immediately