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.

Defense in Depth

If either the classical or PQC component is broken, the other still provides security. Belt and suspenders.

Three Certificate Format Approaches

There are three distinct X.509 certificate formats for PQC deployment — each with different standardization status and trade-offs:

Pure PQC

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 PQC signature. ML-DSA OIDs are standardized in RFC 9881; SLH-DSA/LMS OIDs in RFC 9802. Quantum-safe but requires all verifiers to support the PQC algorithm.

Composite (Dual-Algorithm)

Draft

Certificate {

algorithm: id-MLDSA65-ECDSA-P256

OID: 2.16.840.1.114027.80.8.1.6

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-14. Not yet in OpenSSL production builds — strongest security model.

Parallel (Alt-Sig)

Informational

Certificate {

algorithm: id-ml-dsa-65

extensions {

AltSigAlg (2.5.29.73): ECDSA-P256

AltSigValue (2.5.29.74): ECDSA-sig

}

PQC primary signature with classical key/sig in X.509 extension fields (OIDs 2.5.29.73/74). Legacy verifiers validate the primary PQC sig and ignore extensions. Maximizes backward compatibility at the cost of complexity.

Deployment guidance: Pure PQC is ready today (RFC 9881 OIDs in OpenSSL 3.x). Composite requires both parties to support the draft spec — ideal for closed PKI environments. Parallel works with legacy verifiers but adds X.509 extension complexity. ANSSI explicitly permits pure hash-based (, LMS) as standalone alternatives.

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.

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.