Learn

Build

Hybrid & Composite Cryptography

Combine classical and PQC algorithms for defense in depth during the quantum transition.

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.

Mandate

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.

SP 800-227

NIST recommends hybrid key exchange for TLS and other protocols during the PQC transition period.

(NSA)

NSA's Commercial National Security Algorithm Suite 2.0 mandates PQC adoption for national security systems by 2030 — with hybrid key exchange required during the transition window.

Defense in Depth

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

There are six distinct X.509 certificate formats for PQC deployment, split into two groups by backward compatibility:

PQC-only — no legacy fallback

Pure PQC (ML-DSA)

Published

Certificate {

algorithm: id-ml-dsa-65

OID: 2.16.840.1.101.3.4.3.18

publicKey: ML-DSA-65-key

signature: ML-DSA-65-sig

}

Standard 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)

Published

Certificate {

algorithm: id-slh-dsa-sha2-128s

OID: 2.16.840.1.101.3.4.3.20

publicKey: SLH-DSA-128s-key

signature: SLH-DSA-128s-sig (7856 B)

}

Hash-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.9 KB) are the trade-off.

Composite (Dual-Algorithm)

Draft

Certificate {

algorithm: id-MLDSA65-ECDSA-P256

OID: 1.3.6.1.5.5.7.6.45

publicKey: ML-DSA-65-key || ECDSA-key

signature: ML-DSA-65-sig || ECDSA-sig

}

A single composite OID identifies the algorithm pair. Both signatures must verify. Defined in draft-ietf-lamps-pq-composite-sigs. Strongest security model — prevents downgrade attacks. Not backward-compatible with legacy validators.

Hybrid with legacy fallback

Alt-Sig / Catalyst

Draft

Certificate {

algorithm: ecdsa-with-SHA256

extensions {

AltPubKey (2.5.29.72): ML-DSA-65

AltSigAlg (2.5.29.73): ML-DSA-65

AltSigValue (2.5.29.74): ML-DSA-sig

}

A single classical cert with PQC key and signature in X.509 extensions. Legacy verifiers ignore the extensions; PQC-aware verifiers check both. Defined in draft-ietf-lamps-cert-binding-for-multi-auth.

Related Certs (RFC 9763)

Published

Cert A (Classical) {

algorithm: ecdsa-with-SHA256

ext: sha256(CertB) → binding

}

Cert B (PQC) {

algorithm: ML-DSA-65

ext: sha256(CertA) → binding

}

Two separate independent certificates bound by a hash in a RelatedCertificate extension. Each certificate is independently valid. Legacy systems validate the classical cert; PQC-aware systems verify both and check the binding hash.

Chameleon

Draft

Certificate (PQC primary) {

algorithm: ML-DSA-65

ext: DeltaCertDescriptor {

sig: ecdsa-with-SHA256

pubKey: EC P-256

sigValue: ECDSA sig

}

One certificate with a DeltaCertificateDescriptor extension encoding the differences needed to reconstruct a partner cert. More space-efficient than Related Certs. Backed by DigiCert and Entrust ( draft-bonnell-lamps-chameleon-certs).

Deployment guidance: Pure PQC (ML-DSA) is ready today (RFC 9881 OIDs in OpenSSL 3.x). Pure SLH-DSA is also ready (RFC 9909) and ANSSI-approved as standalone. Composite requires both parties to support the draft spec — ideal for closed PKI. Alt-Sig and Chameleon work with legacy verifiers via extensions. Related Certs (RFC 9763) provides full backward compatibility with two independent certificates. Upcoming: FN-DSA (FIPS 206) will add compact lattice-based signatures; composite KEM (ML-KEM+ECDH) will enable hybrid key encapsulation in S/MIME.

Hybrid KEMs

is the leading hybrid , combining Curve25519 ECDH with -768. It's already deployed in Chrome, Cloudflare, and AWS.

How X25519MLKEM768 Works

1.Key Generation: Generate both key pair and ML-KEM-768 key pair

2.Encapsulation: Sender performs X25519 ECDH + ML-KEM-768 encap → produces combined ciphertext

3.Decapsulation: Recipient performs X25519 ECDH + ML-KEM-768 decap → recovers combined shared secret

4.Key Derivation: Combined shared secret = KDF(X25519_ss || ML-KEM_ss) → session key

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.

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.

Note: The KDF step above is simplified. In TLS 1.3, the concatenated shared secrets feed into the protocol's -based key schedule. The X-Wing KEM draft uses a separate labeled extraction.

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:

Client→ClientHello supported_groups: [X25519MLKEM768, X25519]

key_share: X25519MLKEM768 public key (1,216 bytes)

Server→ServerHello selected_group: X25519MLKEM768

key_share: ciphertext (1,120 bytes) = X25519 ct || ML-KEM ct

Both→HKDF(X25519_ss || ML-KEM_ss) → handshake keys

Size Impact

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 packet (~1,460 bytes), requiring an extra round trip on some networks.

Performance

ML-KEM-768 encap/decap adds ~0.1–0.3 ms per handshake. 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.

Composite Signatures

Composite signatures combine with or Ed25519 into a single signature operation. Both signatures must verify for the composite to be valid.

Composite Signature Structure

CompositeSignature ::= SEQUENCE {

classicalSig ECDSA-P256-Signature,

pqcSig ML-DSA-65-Signature,

}

Advantages

• Single OID simplifies certificate handling
• Both-must-verify prevents downgrade attacks
• Atomic operation — no partial verification

Trade-offs

• Larger signatures (~3.4 KB vs ~72 B for ECDSA alone)
• Both algorithms must be supported by verifier
• Composite draft not yet finalized — OIDs may change before RFC

Note: If you only need quantum safety without a classical fallback, use a pure PQC certificate instead — ML-DSA OIDs are fully standardized in RFC 9881 and work in OpenSSL today. Composite is specifically for environments that require the both-must-verify dual-algorithm property.