Hybrid Cryptography Explained

Many early production deployments use hybrid mode: a classical algorithm and a post-quantum algorithm contribute to a combined construction. The intended security property depends on the specific combiner and protocol, so teams must validate the implementation rather than infer safety from two algorithm names. Hybrid deployment is an engineering strategy represented in finalized standards and active drafts, not a universal mandate or a fixed deadline.

This guide explains why hybrid mode exists, how it works at the protocol level, which standards define it, and when organizations will be able to drop the classical component entirely.

Why hybrid mode exists

The core reasoning is straightforward: we trust classical algorithms because they have decades of cryptanalysis behind them. We trust post-quantum algorithms because of their mathematical foundations and the NIST standardization process. But PQC algorithms are newer, with less real-world deployment experience, and we cannot rule out the discovery of a classical attack against them.

Hybrid mode gives you the best of both worlds:

• If a quantum computer breaks the classical algorithm, the PQC algorithm still protects you
• If a classical attack is found against the PQC algorithm, the classical algorithm still protects you
• Both algorithms must be broken simultaneously for the combined scheme to fail

This is not theoretical paranoia. NIST’s own documentation acknowledges that while ML-KEM and ML-DSA have withstood extensive analysis, the risk of an unexpected breakthrough against lattice-based schemes (however unlikely) justifies the belt-and-suspenders approach during the transition period.

The asymmetry between key exchange and signatures

The urgency for hybrid mode differs between key exchange and signatures:

Key exchange (highest urgency): An attacker who records encrypted TLS traffic today can store it and decrypt it later when a quantum computer becomes available. This is the harvest-now-decrypt-later attack. Hybrid key exchange provides immediate protection against this threat.

Signatures (lower urgency for most use cases): An attacker cannot forge a signature retroactively. The threat to signatures is that a future quantum computer could forge new signatures, not undo existing ones. The exception is long-lived signed artifacts (certificates with multi-year validity, firmware signatures, legal documents) where forgery in the future matters.

This asymmetry explains why industry adoption started with hybrid key exchange (Chrome, Cloudflare, AWS) and signature migration is progressing more slowly.

How hybrid key exchange works

X25519MLKEM768: The dominant hybrid

The most widely deployed hybrid key exchange is X25519MLKEM768, which combines:

• X25519: Elliptic Curve Diffie-Hellman over Curve25519 (classical)
• ML-KEM-768: Module-Lattice-Based Key Encapsulation Mechanism at security level 3 (post-quantum)

During a TLS 1.3 handshake using X25519MLKEM768:

1. The client generates both an X25519 key share and an ML-KEM-768 encapsulation key, sending both in the ClientHello
2. The server performs X25519 key agreement and ML-KEM encapsulation, producing two shared secrets
3. Both shared secrets are combined (concatenated and fed through the TLS key derivation function) to produce the final session keys
4. If either component is broken, the other still provides a secure shared secret

The combined key share in the ClientHello is approximately 1,216 bytes (32 bytes for X25519 + 1,184 bytes for the ML-KEM-768 public key). The server response adds approximately 1,120 bytes (32 bytes for X25519 + 1,088 bytes for the ML-KEM-768 ciphertext).

Other standardized hybrid combinations

RFC 10024 (published 2026) defines three hybrid key agreement mechanisms:

Hybrid name	Classical component	PQC component	Security level
X25519MLKEM768	X25519 (Curve25519)	ML-KEM-768	NIST Level 3
SecP256r1MLKEM768	ECDH over P-256	ML-KEM-768	NIST Level 3
SecP384r1MLKEM1024	ECDH over P-384	ML-KEM-1024	NIST Level 5

X25519MLKEM768 is marked Recommended in the IANA TLS Supported Groups registry. The P-256 and P-384 groups are standardized but are not marked Recommended for general implementation. That registry value does not make them experimental or obsolete. Use them only for a defined interoperability, assurance, or policy requirement. See RFC 10024 Explained for the code points and migration checklist.

The IETF standards landscape

Understanding the standards helps you evaluate what is stable and what is still evolving.

Published RFCs (stable, ready for production)

RFC 9954: Hybrid Key Exchange in TLS 1.3

Published in 2026, this RFC defines the general framework for combining multiple key exchange algorithms in a single TLS 1.3 handshake. It specifies how the shared secrets from different algorithms are combined, how negotiation works through the existing TLS key_share extension, and how the approach integrates with the TLS 1.3 key schedule without requiring protocol changes.

Key design decisions:

• Hybrid key shares are encoded as a single NamedGroup in the TLS supported_groups extension
• The combined shared secret is the concatenation of the individual shared secrets
• Failure in either component causes the entire handshake to fail (no silent fallback to a single component)
• No additional round-trips compared to a non-hybrid handshake

RFC 10024: PQ/T Hybrid Key Agreement Mechanisms for TLS 1.3

Published as a Standards Track RFC in August 2026, this companion specification defines the exact encoding, final IANA code points, and operational requirements. It also obsoletes X25519Kyber768Draft00 and SecP256r1Kyber768Draft00.

RFC 10042: PQ/T Hybrid Key Exchange with ML-KEM for SSH

Published as an Informational RFC in August 2026, RFC 10042 defines three exact ML-KEM plus ECDH key-exchange methods for the SSH transport layer. It does not standardize post-quantum SSH host or user authentication. See what RFC 10042 standardizes for post-quantum SSH for the method matrix, implementation evidence and migration checks.

RFC 9881: ML-DSA Algorithm Identifiers for X.509

Published in 2025, this RFC defines how ML-DSA keys and signatures are encoded in X.509 certificates and related PKIX data structures. This is a building block for post-quantum certificate deployment, though not hybrid-specific.

RFC 9955: Hybrid Signature Spectrums

Published in 2026, this RFC classifies the design goals and security properties of hybrid signature schemes. It covers proof composability, non-separability (ensuring an attacker cannot strip one signature component from a hybrid signature), backwards and forwards compatibility, and simultaneous verification requirements.

IETF work approaching publication

draft-ietf-tls-mldsa-05, Use of ML-DSA in TLS 1.3

The IESG approved this document for publication as an Informational RFC on September 10, 2026. It defines TLS 1.3 signature-scheme identifiers and protocol mappings for pure ML-DSA-44, ML-DSA-65, and ML-DSA-87 authentication. Approval for publication is not the same as final RFC publication. A final RFC number is still pending.

This mapping concerns authentication signatures. It does not replace RFC 10024 hybrid ML-KEM key establishment, and it does not make public Web PKI certificates broadly deployable with ML-DSA today.

draft-ietf-lamps-pq-composite-sigs (revision 19)

This draft defines composite ML-DSA signatures for X.509 certificates. A composite signature combines ML-DSA with a classical algorithm (RSA, ECDSA, or EdDSA) in a single signature value. Both component signatures must verify for the composite to be valid.

This is the most mature approach for hybrid signatures in PKI. It is progressing through the IETF LAMPS working group and is expected to become an RFC. The draft specifies combinations such as:

• ML-DSA-65 + ECDSA-P256
• ML-DSA-65 + Ed25519
• ML-DSA-87 + ECDSA-P384
• ML-DSA-87 + Ed448

draft-reddy-tls-composite-mldsa (revision 10)

This draft specifies how composite ML-DSA signatures can be used for authentication in TLS 1.3. It covers how a TLS server presents a composite certificate and how the client verifies both signature components.

draft-ietf-jose-pq-composite-sigs (revision 3)

This draft defines serializations for hybrid composite signatures in JOSE (JSON Object Signing and Encryption) and COSE (CBOR Object Signing and Encryption) formats. It combines ML-DSA with either ECDSA or EdDSA for use in JWT, JWS, and related token formats.

draft-miller-sshm-composite-sigs

This draft specifies composite ML-DSA signatures for SSH, combining ML-DSA-65/87 with Ed25519 or ECDSA for SSH key authentication.

How long will hybrid mode last?

This is the practical question everyone asks. The answer depends on two factors: confidence in PQC algorithms and the operational cost of maintaining dual implementations.

A possible transition path, not a universal deadline

The initial public draft of NIST IR 8547 proposes transition treatment for quantum-vulnerable algorithms, including deprecation after 2030 for specified 112-bit-strength uses and disallowance after 2035. It is draft guidance, not a universal law or final protocol standard. Track the final publication and policies that apply to the system.

• Current phase: use documented hybrid constructions where compatibility and risk justify them
• Transition phase: maintain interoperability evidence and update implementations as standards mature
• Later phase: remove the classical component only when policy, protocol guidance and the ecosystem permit it

Under this timeline, hybrid mode is the standard approach for approximately a decade.

The realistic timeline (hybrid persists until 2035+)

In practice, hybrid mode may persist longer than technically necessary because:

1. Interoperability: Not all systems will support PQC simultaneously. Hybrid ensures backward compatibility with legacy systems that only understand the classical component.

2. Compliance: Many regulatory frameworks have not yet adopted PQC requirements. Organizations may keep classical algorithms for compliance with older standards while adding PQC for forward security.

3. Risk aversion: Even after extensive cryptanalysis, some organizations will want the insurance policy of dual algorithms, particularly for high-value, long-lived keys.

4. Inertia: Systems deployed in hybrid mode that work correctly have little incentive to change configuration.

When can you drop classical?

The conditions for safely dropping the classical component are:

1. PQC algorithms have been standardized and deployed for at least 10 years with no successful attacks
2. All systems in your communication ecosystem support pure PQC
3. Regulatory frameworks permit or require pure PQC
4. NIST or equivalent bodies issue guidance that hybrid is no longer necessary

No defensible universal retirement date exists. Organizations with full stack control may move differently from public ecosystems. Removal requires protocol guidance, interoperability, risk review and applicable policy.

Hybrid signatures vs. hybrid key exchange

The deployment stories for these two use cases are quite different.

Hybrid key exchange: mostly solved

Hybrid key exchange in TLS is standardized (RFC 9954, RFC 10024), widely deployed (Chrome, Firefox, Cloudflare, AWS, Google), and largely transparent to applications. If your TLS library supports it and the remote end supports it, you get hybrid key exchange with no application changes.

The remaining challenge is middlebox compatibility. Some legacy network devices (firewalls, proxies, DLP systems) cannot handle the larger ClientHello that results from the additional ML-KEM key share. This is an operational issue, not a cryptographic one.

Hybrid signatures: still in progress

Hybrid signatures face more challenges:

Size: A composite ML-DSA-65 + ECDSA-P256 signature is approximately 3,373 bytes, compared to 64 bytes for standalone ECDSA-P256. In certificate chains with 3-4 certificates, this multiplies the handshake size significantly.

Standards maturity: The LAMPS composite signatures draft is not yet an RFC. While it is mature and widely reviewed, it has not achieved the stability of the key exchange RFCs.

Infrastructure readiness: Certificate Authorities, OCSP responders, CRL distribution points, and certificate transparency logs all need updates to handle composite certificates. Most public CAs do not issue PQC or composite certificates yet.

Browser strategy: Chrome is pursuing Merkle Tree Certificates rather than traditional composite X.509 certificates, creating uncertainty about the ultimate path for web PKI PQC authentication.

Current production approach: Organizations that need hybrid authentication today typically use it at the application layer (composite signatures on documents, firmware, or tokens) rather than in TLS certificates.

Practical deployment guide

For TLS connections (immediate action)

1. Update your TLS library to one that supports X25519MLKEM768:

   • OpenSSL 3.5+ (default group since April 2025)
   • BoringSSL (supported since August 2024)
   • AWS-LC / s2n-tls (supported for AWS services)
   • GnuTLS 3.8.8+ (supported)

2. Configure your server to offer X25519MLKEM768 as the preferred key exchange group. In most modern TLS libraries, it is already the default.

3. Test with real clients. Verify that Chrome, Firefox, and programmatic clients successfully negotiate the hybrid group. Monitor for failed handshakes that might indicate middlebox issues.

4. Do not remove classical groups. Keep X25519 and ECDH P-256 in your offered groups for clients that do not yet support hybrid. The TLS negotiation will automatically select the best available option.

For digital signatures (plan now, deploy carefully)

1. Identify long-lived signatures. Any signature that needs to remain trustworthy for more than 10 years is a candidate for hybrid signing today.

2. Use managed KMS or HSM solutions only for capabilities they explicitly support. Google Cloud KMS offers GA ML-DSA and SLH-DSA signing, but its X-Wing and ML-KEM key import workflow is Preview and software-only. See the Google Cloud PQC support guide.

3. For internal PKI: Issue composite certificates if your CA and clients both support them. This is viable for private PKI where you control both ends.

4. For public-facing PKI: Wait for CA/Browser Forum standards. Do not attempt to use composite certificates in the public web PKI until browsers and CAs agree on the approach.

For application-layer crypto (evaluate case by case)

1. JWT/JWS tokens: Monitor the JOSE composite signatures draft. When it becomes an RFC, update your token signing to use composite algorithms.

2. Document signing: Consider dual-signing (two separate signatures) if composite signature tooling is not available in your ecosystem.

3. Code signing: Check your platform’s support. Apple, Google (Android), and Microsoft all have PQC roadmaps for code signing, but timelines vary.

Common misconceptions

“Hybrid mode is slower because you run two algorithms.”

For key exchange, the performance overhead of hybrid is negligible (sub-millisecond on modern hardware). For signatures, verification of a composite signature is roughly the sum of verifying both components, but this is still fast in absolute terms. The real cost is bandwidth (larger messages), not computation.

“Hybrid is a temporary workaround; pure PQC is better.”

From a security perspective, hybrid is strictly stronger than pure PQC. Running two algorithms can never be weaker than running one, assuming correct implementation. Hybrid is not a compromise; it is the maximum-security option during the transition period.

“I need to choose between hybrid and pure PQC.”

For key exchange, you are already getting hybrid if you use a modern TLS library. There is no separate “enable hybrid” step. For signatures, the choice between pure ML-DSA and composite (ML-DSA + classical) depends on whether all verifiers in your ecosystem support ML-DSA.

“The larger key sizes make hybrid impractical.”

X25519MLKEM768 adds approximately 1.1 KB to the TLS handshake. On any connection faster than dial-up, this is not meaningful. The concern is valid for extremely constrained IoT devices or scenarios with many concurrent handshakes (edge compute at massive scale), but for typical web, mobile, and API traffic it is not a practical issue.

The endgame: pure post-quantum

Hybrid may eventually be retired for a specific protocol and ecosystem. Do not schedule that change from a generic date. Record the final standards, participant support, policy basis, downgrade behavior, test evidence and rollback plan for the exact capability.

Use the migration plan template to record the construction and exit criteria. Use the vendor questionnaire to verify whether a supplier means hybrid key establishment, hybrid signatures or composite certificates.

Frequently asked questions

What happens if someone breaks ML-KEM?

In hybrid mode, nothing changes from a security perspective. The X25519 component still provides the same security you have today. You would need to replace the ML-KEM component with another PQC algorithm, but your existing traffic remains protected by the classical component.

Can I use hybrid mode with hardware security modules (HSMs)?

For TLS key exchange, the hybrid computation normally happens in the TLS library, not the HSM. For signatures, you need an HSM that supports the required algorithm or can perform the component operations separately. Do not equate a managed KMS feature with HSM support: Google Cloud’s Preview X-Wing import method accepts software-backed target keys only.

Is hybrid key exchange compatible with TLS session resumption?

Yes. The hybrid key agreement produces a standard TLS shared secret that feeds into the normal key schedule. Session tickets and resumption work exactly as they do with classical key exchange.

Do I need different certificates for hybrid key exchange?

No. X25519MLKEM768 is a key exchange mechanism, not an authentication mechanism. Your existing RSA or ECDSA certificate continues to authenticate the server. The hybrid key exchange protects the session keys independently of the authentication mechanism.

What about IPsec/VPN hybrid support?

IKEv2 has active IETF work on hybrid post-quantum key exchange (draft-ietf-ipsecme specifications) and hybrid authentication (using composite certificates). Some VPN vendors (such as WireGuard implementations with PQ add-ons) already support ML-KEM in hybrid mode. IPsec deployments should follow the ipsecme working group drafts.

When will the LAMPS composite signatures draft become an RFC?

The draft is at revision 19 and progressing through IETF Last Call and IESG review. Based on the current pace, publication as an RFC is likely in late 2026 or early 2027. However, organizations can implement composite signatures based on the current draft, which is considered stable enough for pilot deployments.

Is RFC 9954 different from RFC 10024?

RFC 9954 defines the framework (how to combine any two key exchange algorithms in TLS 1.3). RFC 10024 defines the specific combinations (X25519MLKEM768, etc.) that use that framework. You need both: 9954 for the “how” and 10024 for the “what.”

Sources

• RFC 9954: Hybrid Key Exchange in TLS 1.3 - IETF standard defining the general framework for combining multiple key exchange algorithms in TLS 1.3
• RFC 10024: PQ/T Hybrid Key Agreement Mechanisms for TLS 1.3 - defines X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024
• RFC 10042: PQ/T Hybrid Key Exchange with ML-KEM for SSH - Informational RFC defining three hybrid ML-KEM SSH key-exchange methods
• IETF LAMPS draft on composite signatures - draft composite ML-DSA signatures for X.509 certificates
• NIST IR 8547: Transition to Post-Quantum Cryptography Standards - initial public draft with proposed transition dates
• NIST FIPS 203: ML-KEM Standard - final ML-KEM specification underlying hybrid key exchange
• Cloudflare: Post-Quantum Cryptography goes GA - vendor report on its production hybrid PQ deployment
• Google Security Blog: A new path for Kyber on the web - vendor report on Chrome X25519MLKEM768 deployment