Definition

    Hybrid approaches and their limitations

    Hybrid cryptography combines a post-quantum and a traditional mechanism for the same function, usually key establishment, so protection holds if either one remains secure. Its security depends on the specific construction, implementation and negotiation policy, which should come from a published protocol specification rather than in-house design. Hybrid key establishment does not make authentication post-quantum, and no hybrid arrangement is approved automatically.

    New to this? Read Crypto agility: definition and practical demonstration first. After this, continue with Testing, acceptance and rollback.

    In one sentence: Hybrid adds resilience only through a specified construction, and it protects key exchange, not signatures.

    Why it matters

    Hybrid key establishment is a common transition choice in protocols such as TLS 1.3. It is easy to over-read: a hybrid key exchange leaves certificates and signatures as they were, and a poorly controlled fallback can quietly remove the post-quantum component.

    Illustrative example: a service enables a hybrid TLS group but still accepts classical-only negotiation from any client. Without fallback controls and monitoring, most sessions may still use classical key exchange.

    Protocol-specific constructions

    Hybrid is defined per protocol. For TLS 1.3, IETF RFC 10024 (Proposed Standard) defines specific hybrid key agreement mechanisms combining elliptic-curve Diffie-Hellman with ML-KEM. Other protocols have their own specifications. QCI-QS1 notes that RFC 10024 is relevant only where that TLS profile is selected and does not make TLS authentication post-quantum.

    NIST SP 800-227 (final, September 2025) gives recommendations for using key-encapsulation mechanisms, including how they are combined. Organizations should use these published constructions and library implementations rather than design their own combiner.

    Interoperability and limitations

    • Both endpoints must support the same construction; otherwise negotiation falls back.
    • Larger key shares can affect message size and fragmentation, which QCI-4.7-01 requires to be tested where relevant.
    • Authentication is separate: key establishment and authentication need separate posture records (QCI-4.5-03).
    • Dual signatures follow the approved construction; accepting either signature does not preserve protection if one algorithm fails (QCI-4.5-03).
    • Hybrid adds complexity and a later transition cost if the organization moves to PQC-only (Clause 9.5, informative).

    What a hybrid profile must specify under QCI-QS1

    Components, combiner or protocol construction, authentication mechanism, negotiation and verification policy, and permitted fallback behavior. Unauthorized classical fallback must be prevented or detected and acted on within policy limits, and any permitted fallback needs approved scope, expiry, monitoring and a residual-risk record (QCI-4.5-03). A draft specification or a supplier's "quantum-safe" label does not alone establish production approval (QCI-4.5-02).

    What organizations should do

    1. Choose hybrid only through an approved profile that names the published construction (QCI-4.5-01).
    2. Use maintained library implementations of the protocol specification; do not build a combiner in-house.
    3. Record key establishment and authentication posture separately (QCI-4.5-03).
    4. Set and monitor fallback policy, and treat permitted fallback as a scoped, expiring exception.
    5. Test size, fragmentation and interoperability with real counterparties (QCI-4.7-01).
    6. Record transition and retirement criteria for any interim hybrid construction (QCI-4.5-04).

    Evidence an auditor should expect

    Rows marked "QCI requirement" come from the standard. Rows marked "Editorial suggestion" are QCI's practical advice and are not requirements.

    Expected evidence
    ArtifactScopeOwnerCurrencyVerificationBasis
    Approved hybrid profileEach hybrid deploymentProfile ownerReview date in profileCheck construction, authentication, negotiation and fallback fieldsQCI requirement (QCI-4.5-03)
    Fallback monitoring recordHybrid endpointsService ownerContinuous, reviewed per policyCompare negotiated groups with policyQCI requirement (QCI-4.5-03)
    Interoperability test resultsCounterparties and intermediariesEngineeringBefore acceptanceReview against Clause 4.7 categoriesQCI requirement (QCI-4.7-01)

    How NIST or other primary authorities address it

    NIST FIPS 203 (final, August 13, 2024) specifies ML-KEM. NIST SP 800-227 (final, September 2025) gives recommendations for using KEMs. IETF RFC 10024 is a Proposed Standard defining hybrid key agreement for TLS 1.3.

    Whether a hybrid construction is acceptable for a regulated or national-security system is decided by the requirements that apply to it, not by these documents alone. QCI-QS1 Annex E notes that NSS applicability and specific profiles require separate determination.

    How QCI-QS1 addresses it

    QCI-QS1 defines PQ/T hybrid in Clause 3 and states that hybrid key establishment does not itself establish post-quantum authentication. Clause 4.5 governs hybrid profiles; Clause 9.5 (informative) advises against treating hybrid as universally mandatory.

    QCI-QS1 v2.3 mappings
    RequirementClauseRelationshipPillarGate
    QCI-4.5-034.5explicit requirementP4—
    QCI-4.5-014.5explicit requirementP4—
    QCI-4.5-024.5explicit requirementP4—
    QCI-4.5-044.5explicit requirementP4—
    QCI-4.7-014.7supporting evidenceP4—

    Common mistakes

    • Assuming hybrid key exchange makes certificates or signatures quantum-resistant.
    • Designing a custom combiner instead of using a published construction.
    • Leaving classical fallback unmonitored.
    • Treating a supplier's "quantum-safe" label as approval (QCI-4.5-02).

    Questions

    Is hybrid cryptography required by QCI-QS1?

    No. QCI-QS1 governs hybrid profiles when chosen but advises weighing complexity and transition cost rather than treating hybrid as universally mandatory (Clause 9.5, informative).

    Does hybrid TLS key exchange protect authentication?

    No. Hybrid key establishment does not itself establish post-quantum authentication; QCI-QS1 requires separate posture records for each (QCI-4.5-03).

    Is RFC 10024 a final standard?

    It is an IETF Proposed Standard, which is on the Internet Standards Track. It applies only where its TLS 1.3 profile is selected.

    Sources

    1. QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 3. Supports: PQ/T hybrid definition.
    2. QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 4.5. Supports: Hybrid profile requirements.
    3. QCI-QS1 Quantum Readiness and Post-Quantum Cryptography Governance Standard, Quantum Core Institute, Version 2.3, September 23, 2026, Clause 9.5 (informative). Supports: Selecting hybrid profiles.
    4. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, NIST, Final, August 13, 2024. Supports: ML-KEM specification and final status.
    5. SP 800-227, Recommendations for Key-Encapsulation Mechanisms, NIST, Final, September 2025. Supports: Recommendations for using KEMs, including combining them.
    6. RFC 10024, Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3, IETF, Proposed Standard, August 2026. Supports: Specific hybrid key agreement groups for TLS 1.3.

    Related learning

    Back to Migration and crypto agility · All Knowledge Center topics

    Page history

    Published
    Not yet recorded
    Standard edition
    QCI-QS1 v2.3 (September 23, 2026)

    Cite this page

    Quantum Core Institute. (n.d.). Hybrid approaches and their limitations. https://quantumcoreinstitute.com/learn/migration/hybrid-cryptography

    Link: https://quantumcoreinstitute.com/learn/migration/hybrid-cryptography