Hybrid & Composite Cryptography
Combine classical and PQC algorithms for defense in depth during the quantum transition.
Why this matters: Hybrid (classical + PQC) lets you deploy now without betting everything on algorithms still maturing in the field.
Start here: Choose KEM or Signatures and press Generate All Keys: classical, post-quantum and hybrid key pairs are generated side by side, with a table of key, ciphertext or signature sizes and gen time.
For your role
- Developer / Engineer
- Compare classical, PQC and hybrid key generation, run KEM encapsulation and hybrid signatures, generate the two root CAs and the hybrid X.509 formats, then the HPKE step composed from PKCS#11 v3.2 mechanisms.
- Security Architect
- The certificate steps generate and compare the hybrid X.509 approaches with the IETF reference artifacts, and the signature-spectrum step covers concatenation, nesting and Silithium: the relying-party compatibility decision.
- Researcher / Academic
- The IETF reference artifacts in the certificate deep-dive and the three signature compositions with their non-separability properties are the material to check against the drafts.
- Certification & Validation Engineer
- The three signature compositions and the hybrid X.509 formats with their IETF reference artifacts show which part is a tested primitive and which is composition built on top of it.
- IT Ops / DevOps
- Generate the classical and PQC root CAs and the hybrid certificate formats: which one a relying party that only knows ECDSA still validates is the property your fleet needs during migration.
Why Hybrid Cryptography?
The transition to post-quantum cryptography faces a fundamental dilemma: PQC algorithms are newer and less battle-tested than classical algorithms, yet the “” (HNDL) threat means waiting is dangerous. solves this by combining classical and PQC algorithms together.
France's ANSSI requires hybrid mode during transition — PQC-only is not acceptable until algorithms are more mature. Exception: hash-based signatures (/SPHINCS+, LMS, XMSS) may be used standalone.
NIST SP 800-227 §1 frames hybrid key exchange as an interim measure during the PQC transition — recommended for TLS, IKE, and similar protocols. The spec ties the move to pure PQC to algorithm maturation (extended cryptanalysis, broad deployment), not calendar deadlines alone.
NSA's Commercial National Security Algorithm Suite 2.0 mandates PQC adoption (ML-KEM-1024 + ML-DSA-87) for national security systems, with exclusive-use deadlines running to 2030–2033 by equipment class. CNSA 2.0 does not require hybrid — it permits pure PQC (hybrid is mandated by ANSSI/BSI, not the NSA).
If either the classical or PQC component is broken, the other still provides security. Belt and suspenders.
RFC 9794 standardizes terminology for hybrid schemes — distinguishing “composite” (single OID, both-must-verify) from “non-composite” (parallel independent algorithms) and establishing naming conventions such as “PQ/T” (Post-Quantum / Traditional).
Certificate Format Approaches
Seven X.509 certificate formats make up the workshop's main comparison: five carry signature keys and two carry KEM (encryption) keys. One rule underlies all of them: the subject public key and the certificate signature are independent. The subject key is what the certificate is about; the signature comes from the issuer's key.
PQC-only — no legacy fallback
Pure PQC (ML-DSA)
PublishedStandard single-algorithm X.509 using a lattice-based PQC signature. ML-DSA OIDs are standardized in RFC 9881. Quantum-safe but requires all verifiers to support ML-DSA.
Pure PQC (SLH-DSA)
PublishedHash-based signature (SPHINCS+) with no lattice assumptions. OIDs in RFC 9909. allows standalone SLH-DSA without hybrid — security relies only on hash function properties. Larger signatures (7,856 B, about 7.9 KB, for SLH-DSA-SHA2-128s per FIPS 205) are the trade-off.
Composite (Dual-Algorithm)
RFC Editor queueA single composite OID identifies the algorithm pair. Both signatures must verify. Defined in draft-ietf-lamps-pq-composite-sigs-19, approved and in the RFC Editor queue (no RFC number yet). Strongest binding — neither signature can be stripped and reused alone. Not backward-compatible with legacy validators.
Hybrid with legacy fallback
Alt-Sig / Catalyst
ITU-T X.509A single classical cert with PQC key and signature in X.509 extensions. Legacy verifiers ignore the extensions; PQC-aware verifiers can check the alternative signature too, and their policy decides whether one or both must verify. Defined in ITU-T X.509 (2019) §7.2.2 and §9.8.
Related Certs (RFC 9763)
PublishedA new certificate carries a RelatedCertificate extension holding the hash of an existing one. The link is one-way: Cert A is never modified. The CA issues Cert B only after the requester proves it holds Cert A's key. Legacy systems use the classical cert; a protocol may ask for either certificate or both — RFC 9763 does not require both.
KEM certificates — the subject key encrypts, the issuer signs
Pure PQC KEM (ML-KEM)
PublishedRFC 9935 defines ML-KEM public keys in X.509. An ML-KEM key cannot sign, so its certificate is always issued by a separate signing-capable CA (ML-DSA, ECDSA, RSA, …). If keyUsage is present, keyEncipherment must be the only bit. Because the CA cannot check a self-signature from a KEM key, proof of possession uses a KEM-based exchange instead. The key is then used, for example, in CMS KEMRecipientInfo (RFC 9629, ML-KEM in RFC 9936).
Composite KEM
IESG Evaluationdraft-ietf-lamps-pq-composite-kem-21 puts an ML-KEM key and a classical KEM key (X25519, ECDH, RSA) under one OID, ML-KEM component first. Encapsulation runs both and combines the shared secrets. Still an Internet-Draft; not backward compatible.
Advanced examples
Certificate Discovery
Active draftdraft-ietf-lamps-certdiscovery-03 lets a certificate tell PQC-capable relying parties where to fetch a related certificate, through a subjectInfoAccess entry. A fetched certificate must still pass full path validation. The OIDs are not assigned yet, so the workshop's encoding is illustrative.
Unsigned certificate
PublishedRFC 9925 defines id-alg-unsigned for a certificate with no signature at all — a container for a key that is trusted by other means, such as a trust anchor. It is never valid in a certification path.
Historical design
Chameleon
Expired draftOne certificate with a DeltaCertificateDescriptor extension encoding the differences needed to rebuild a paired certificate. The proposal, draft-bonnell-lamps-chameleon-certs-07, is an expired individual draft that the LAMPS working group never adopted. It is shown for study only and is not recommended for new deployments.
Deployment guidance: Pure PQC (ML-DSA) is ready today (RFC 9881; the workshop is tested with OpenSSL 3.6.3). Pure SLH-DSA is also ready (RFC 9909) and ANSSI-approved as standalone. Composite requires both parties to support the draft spec — best suited to closed PKI. Alt-Sig works with legacy verifiers via extensions. Related Certs (RFC 9763) keeps the classical certificate fully usable on its own. Watchlist: FN-DSA (planned FIPS 206, not yet final) has an IETF certificate draft whose OIDs are still TBD; composite KEM will enable hybrid key encapsulation in S/MIME once published.
Hybrid KEMs
is the leading hybrid , combining Curve25519 ECDH with -768. It's already deployed in Chrome, Cloudflare, and AWS.
How X25519MLKEM768 Works
Even if ML-KEM-768 is broken in the future, X25519 still provides classical security. Even if X25519 is broken by a quantum computer, ML-KEM-768 provides quantum resistance.
Choosing a KEM Parameter Set (NIST SP 800-227)
SP 800-227 approves three ML-KEM parameter sets, each mapped to a NIST security category matching the strength of a given AES key size. Pick the set by threat model, not by default.
| ML-KEM | NIST Cat | Classical equiv. | Typical deployment |
|---|---|---|---|
| ML-KEM-512 | Category 1 | AES-128 | Constrained/IoT, short-lived sessions |
| ML-KEM-768 | Category 3 | AES-192 | Default for TLS 1.3 & most internet traffic |
| ML-KEM-1024 | Category 5 | AES-256 | CNSA 2.0, high-assurance/federal systems |
HNDL risk + data-retention window should drive the choice: if harvested ciphertext must remain secret past ~2035, prefer Cat 3 or Cat 5 over Cat 1.
Other Hybrid KEM Variants
SecP256r1MLKEM768 — P-256 + ML-KEM-768. Important for organizations requiring FIPS-approved classical curves (X25519 is not FIPS-approved).
SecP384r1MLKEM1024 — P-384 + ML-KEM-1024. Provides NIST Level 5 security for high-assurance environments.
Combiner Construction (SP 800-227 + SP 800-56C)
The high-level KDF(X25519_ss || ML-KEM_ss) above hides three real requirements that SP 800-227 defers to SP 800-56C-Rev2:
- Concatenation order is fixed per protocol. Hybrid TLS 1.3 drafts concatenate as
classical_ss || pqc_sswith a protocol-specific label; swapping order silently breaks interop. Order does not add security, but binding to a known order prevents cross-protocol confusion. - HKDF vs KMAC. SP 800-56C permits either an HMAC-based extractor (HKDF-SHA-256/384/512) or KMAC128/256. TLS 1.3 uses HKDF through its key schedule; KMAC is available for KEM-only protocols that want a single primitive.
- Dual-PRF assumption. The combined secret stays safe as long as either input looks uniform to the attacker — so a future break of ML-KEM or of X25519 alone does not break the session key. This is why the classical half is kept during the transition.
- Domain separation is mandatory, not optional. Every context (TLS handshake, KEMTLS, S/MIME, IKE) must feed a unique label/context string into the KDF so shared secrets cannot be replayed across protocols.
The X-Wing KEM draft bakes this combiner in directly (single labeled extraction); TLS 1.3 relies on its own key schedule for the same effect.
HPKE — (RFC 9180)
Definition
HPKE is a public-key encryption scheme built from three swappable components — a , a KDF, and an AEAD — combined through a standard KeySchedule so any KEM/KDF/AEAD triple, plus one of four modes (Base, PSK, Auth, AuthPSK), yields an interoperable construction. "Hybrid" in HPKE's own name refers to this KEM+KDF+AEAD composition, not to a PQC+classical pairing — that is a separate, additional meaning layered on top by draft-ietf-hpke-pq (below), and easy to conflate with the certificate-level hybrid formats covered earlier on this page.
Use cases
A KEM has no way for the sender to supply a chosen shared secret (unlike ECDH) — HPKE always encapsulates a fresh, sender-unpredictable one. That property is why it shows up wherever a protocol needs one-shot public-key encryption rather than an interactive handshake:
- MLS uses HPKE for TreeKEM path updates (see the MLS Group Messaging module).
- TLS 1.3 Encrypted Client Hello (ECH) uses it to encrypt the ClientHello.
- JOSE and COSE extend it to wrap a JWT or CWT payload the same way.
Variants
RFC 9180 itself registers only classical KEMs. The PQC angle comes from draft-ietf-hpke-pq — still an Internet-Draft, not yet an RFC — which registers pure ML-KEM and PQ/T hybrid KEM IDs that plug into the same KeySchedule and Seal/Open.
| Dimension | RFC 9180 (ratified) | draft-ietf-hpke-pq (draft) |
|---|---|---|
| KEM | DHKEM(P-256/P-384/P-521/X25519/X448) | ML-KEM-512/768/1024; MLKEM768-X25519, MLKEM768-P256, MLKEM1024-P384 |
| KDF | HKDF-SHA256/384/512 | + SHAKE128/256, TurboSHAKE128/256 |
| AEAD | AES-128/256-GCM, ChaCha20-Poly1305, Export-only | unchanged |
Independently of the KEM/KDF/AEAD choice, RFC 9180 defines four modes: Base (unauthenticated), PSK (pre-shared key), Auth (sender authenticated via its own KEM keypair), and AuthPSK (both). Auth and AuthPSK stay classical-only: draft-ietf-hpke-pq's ML-KEM and PQ/T hybrid KEM entries mark the Auth column "no", since ML-KEM has no AuthEncap/AuthDecap interface.
The MLKEM768-X25519/P256 and MLKEM1024-P384 hybrid KEMs are not defined by draft-ietf-hpke-pq itself — it delegates to the CFRG's generic hybrid-KEM combiner (draft-irtf-cfrg-hybrid-kems), instantiated concretely in draft-irtf-cfrg-concrete-hybrid-kems: PQ-component-first concatenation, SHA3-256 as the combiner over concat(ss_PQ, ss_T, ct_T, ek_T, Label).
PKCS#11 v3.2 has no CKM_HPKE mechanism — checked against the canonical v3.2 header, no HPKE entry exists at all. A real HSM deployment composes it from mechanisms the spec does define: CKM_ECDH1_DERIVE / CKM_ML_KEM for the KEM leg, plus HMAC signing for LabeledExtract/LabeledExpand, and AES-GCM / ChaCha20-Poly1305 for Seal/Open. — every KEM/KDF/AEAD/mode combination above is selectable, and the classical DHKEM path is cross-checked byte-for-byte against RFC 9180 Appendix A.
Hybrid KEMs in TLS 1.3
In TLS 1.3 (), hybrid KEMs integrate into the handshake via the key_share extension. The client and server exchange hybrid key material just as they would for classical ECDH — but with larger payloads:
Classical X25519 ClientHello key_share is 32 bytes. X25519MLKEM768 is 1,216 bytes — a 38× increase. This can push the ClientHello beyond a single TCP segment (the 1,460-byte MSS assumed by RFC 6928), requiring an extra round trip on some networks.
ML-KEM-768 encap/decap adds ~0.1–0.3 ms per handshake (indicative). The dominant cost is the larger key_share payload, not computation. Real-world measurements (Chrome, Cloudflare) show <1% latency increase at the P50.
For a full interactive TLS 1.3 handshake simulation with hybrid KEM negotiation, see the TLS Basics module.
Implementation Requirements (SP 800-227)
SP 800-227 §4 is explicit: a compliant ML-KEM deployment is more than “call the library.” Decapsulation must not leak any signal about whether a ciphertext was valid, and the implementation must resist timing and side-channel analysis.
On decapsulation failure, ML-KEM returns a pseudorandom key derived from the decapsulation key and ciphertext — never an error. Attackers cannot distinguish a real key from a rejection, so chosen-ciphertext probing gives them nothing. The workshop demo already follows this rule (“includes ek for implicit rejection”).
Execution time, memory access, and branch behaviour must not depend on secret key bits or on whether the ciphertext verifies. SP 800-227 §4.2 requires this for FIPS validation — a timing-variable implementation is non-conformant regardless of correctness.
Encapsulation calls an approved (SP 800-90A/B/C) for the 32-byte m. Weak or predictable RNG collapses ML-KEM security to zero — this is the single most common real-world failure mode for KEMs.
In hybrid constructions, both halves must be hardened: a timing leak in X25519 or ML-KEM-768 can compromise the combined session key even if the other half is safe. Hardware (HSM/TPM) deployments should enable their PQC side-channel countermeasures explicitly — they are not always on by default.
In short: hybrid gets you algorithmic safety (dual-PRF), but SP 800-227 §4 is what gets you deployment safety. Both are required.
Related Resources
Hybrid Signature Spectrum
Signing with both a classical and a PQC algorithm at the same time. The key design question: can either component be stripped and verified alone?
Defines the taxonomy of hybrid signature constructions and a non-separability spectrum. Basis for evaluating all hybrid signature proposals including Silithium.
datatracker.ietf.org ↗| Construction | How it works | Non-separability | Backwards compat |
|---|---|---|---|
| Concatenation | sig₁ ‖ sig₂ | None / WNS | Yes |
| Nesting | sign_ML(msg ‖ sig_EC) | WNS | Yes |
| Fused (Silithium) | shared μ = H(R ‖ pk_ec ‖ pk_ml ‖ msg) | SNS | No |
Non-Separability Spectrum
Silithium — Compact Fused Hybrid Signature
Devevey, Guerreau, Roméas · ePrint 2025/2059 · November 2025
Silithium adapts the Fiat-Shamir transform to produce a fused hybrid signature from EC-Schnorr (classical, secp256k1) and ML-DSA-65 (FIPS 204). Both components share a single challenge μ derived from both public keys, the EC commitment R, and the message. Neither component can be verified independently, achieving Strong Non-Separability (SNS).
k ← DRBG(sk_ec, msg), R = k·G (secp256k1 base point)μ = H(R ‖ pk_ec ‖ pk_ml ‖ msg) expanded to 64 bytes (approx.: full paper also binds ML-DSA commitment w1)s = (k + e·sk_ec) mod n where e = μ[:32] as bigintz = ML-DSA.Sign_internal(sk_ml, μ) (FIPS 204 §5.2 external-μ mode)σ = R ‖ s ‖ z (same total size as concatenation — savings require full w1 binding)Attack Model — Why Fused Wins
Generate hybrid keys, run KEM operations, and inspect .
Check off all sections and mark this reading done.
Related modules
In the Industry Landscape
Check your understanding
20 questions on Hybrid Cryptography, each with its answer and the reason.
Take the quizNext step
Practice it: Hybrid CertificatesHybrid Certificates is the hands-on version of this module: the same ideas, run in your browser.
Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.