PQ/T hybrid schemes: bridging traditional and post-quantum cryptography

Migrating to post-quantum cryptography takes years; most organizations will run traditional and PQ algorithms in parallel during the interim period. PQ/T hybrid schemes (combining post-quantum (PQ) and traditional (T) algorithms, sometimes called "classical" algorithms) reduce exposure to two different failure modes during migration.

Why hybrid?

Hybrid schemes provide defense in depth during a migration period when organizations want protection against both quantum risk (which threatens traditional algorithms) and the relative immaturity of post-quantum replacements.

Post-quantum algorithms are younger than their traditional counterparts. While ML-KEM and ML-DSA have undergone extensive cryptanalysis, they have not had the decades of real-world deployment that RSA and ECDH have. Properly designed hybrid schemes aim to preserve security if one component fails:

• If the PQ algorithm is broken, the traditional algorithm still provides protection against non-quantum attackers
• If a quantum computer breaks the traditional algorithm, the PQ algorithm provides protection

However, the exact security guarantee depends on the component algorithms, the combiner construction, and the attacker model (RFC 9794). A protocol can achieve hybrid confidentiality (protecting key establishment) without necessarily achieving hybrid authentication (protecting identity verification). TLS 1.3 with hybrid key establishment is an example: it provides hybrid confidentiality, but authentication still relies on whichever single signature algorithm the certificate uses.

How hybrids work

Key establishment

In many hybrid key establishment designs, including the current TLS 1.3 ECDHE-MLKEM draft, the component shared secrets are concatenated before key derivation, so the resulting session keys depend on both a traditional key agreement and a post-quantum KEM.

The most prominent example is X25519MLKEM768 (draft-ietf-tls-ecdhe-mlkem, Internet-Draft). It combines X25519 ECDH with ML-KEM-768: the client sends both an X25519 public value and an ML-KEM-768 encapsulation key in the ClientHello. The server responds with its X25519 public value and an ML-KEM-768 ciphertext. The two 32-byte shared secrets (ML-KEM first, then X25519) are concatenated before the TLS 1.3 key schedule derives the session keys. In the terms of RFC 9794, this achieves hybrid confidentiality: the session remains protected as long as at least one component algorithm remains secure within the intended model.

Digital signatures

Hybrid signatures are more complex. Two approaches exist:

• Concatenated signatures: Both a traditional and PQ signature are produced and verified independently. Under the stricter AND policy, the message is authentic only if both verify; some deployments use an OR policy (verify either component) to maintain interoperability with non-hybrid verifiers, though this trades the hybrid authentication guarantee for backward compatibility.
• Composite signatures: A single signature scheme wraps both algorithms, producing one combined signature. RFC 9794 formalizes the terminology for these constructions.

The concatenated approach is simpler but produces larger message overhead. The IETF LAMPS working group is developing composite ML-DSA signatures for X.509 PKI (draft-ietf-lamps-pq-composite-sigs, Internet-Draft).

Hybrid authentication is less mature than hybrid confidentiality. The NCSC notes that proposed PQ/T authentication schemes are significantly more complex than those for confidentiality, that there has been less research activity, and that there is not yet guidance or consensus on how to do this securely in general. For this reason, the NCSC prefers a single migration to fully post-quantum PKI rather than an intermediate hybrid authentication step. Organizations considering hybrid signatures should treat the space as actively evolving and monitor IETF and NCSC guidance closely.

The NCSC position

The UK's NCSC frames hybrid schemes as an interim measure, not a long-term solution:

"If a PQ/T hybrid scheme is chosen, the NCSC recommends it is used as an interim measure, and it should be used within a flexible framework that enables a straightforward migration to PQC-only in the future."

Their migration timelines (March 2025) set concrete milestones: discovery by 2028, high-priority migrations by 2031, full PQC migration by 2035. Recommendations:

• Use hybrid schemes where the risk of "harvest now, decrypt later" attacks is high
• Plan for PQC-only migration; do not design systems that permanently depend on hybrid modes
• Ensure hybrid implementations can be cleanly upgraded to PQC-only

Practical considerations

Increased sizes

Hybrid schemes increase cryptographic overhead. The following table shows TLS handshake sizes for X25519MLKEM768 (per draft-ietf-tls-ecdhe-mlkem, Internet-Draft):

TLS handshake component	X25519 only	ML-KEM-768 only	X25519MLKEM768 (hybrid)
Client key share	32 bytes	1,184 bytes	1,216 bytes
Server key share	32 bytes	1,088 bytes	1,120 bytes

For key establishment, the overhead is often manageable, but full-handshake behavior should be tested against MTU, fragmentation, and middlebox constraints in the target deployment.

Signature sizes are a separate concern. For reference, an ECDSA P-256 signature (DER-encoded) is approximately 71 to 73 bytes, while an ML-DSA-65 signature is 3,309 bytes. In certificate chains with two or three signatures, the size increase accumulates and may require protocol changes such as certificate compression or reducing chain depth.

Performance

For key establishment, the performance overhead is modest since the KEM and ECDH operations can run in parallel. In many deployments, the bottleneck is network round-trips rather than computation. For signature verification in certificate chains, the overhead accumulates, since each certificate requires verifying both signatures.

Deployment complexity

Hybrid schemes add complexity to:

• Certificate management (dual certificates or composite certificates)
• Key storage and rotation
• Protocol negotiation logic
• Testing and validation

When to use hybrids

Use hybrid schemes when:

• Migrating systems with long-lived data confidentiality requirements
• Your risk model includes state-level adversaries with quantum computing programs
• You need to comply with NCSC or similar guidance that recommends hybrid as a transition step

Consider PQC-only when:

• Deploying new systems without legacy constraints
• You have high confidence in the specific algorithms (ML-KEM and ML-DSA completed NIST standardization in August 2024)
• Performance and size constraints make hybrid impractical

Planning for PQC-only

PQ/T hybrids are a transitional measure, not a destination. Design hybrid deployments so the PQC-only migration path is a configuration change, not a re-architecture.

A practical decision rule: hybrid key establishment (confidentiality) is the more mature pattern and is appropriate for systems with long-lived data or harvest-now-decrypt-later risk. Hybrid authentication (signatures, PKI) is less settled, and organizations should weigh the added complexity against the maturity of the available constructions. In both cases, plan for PQC-only as the end state.

For related background, see ML-KEM explained and the PQC Timeline.