FIPS 203 defines ML-KEM, NIST's post-quantum key-encapsulation mechanism. It does not explain how to use a KEM safely inside a protocol, or how to combine ML-KEM with a classical algorithm during the migration. NIST SP 800-227, "Recommendations for Key-Encapsulation Mechanisms", fills that gap. It was released as an initial public draft in January 2025 and published in final form in September 2025. This walkthrough covers what it says about KEMs in general and about hybrid post-quantum/traditional (PQ/T) key establishment in particular.
What a KEM Is
A KEM has three algorithms. KeyGen produces an encapsulation key (public) and a decapsulation key (private). Encaps takes the encapsulation key and outputs a shared secret key plus a ciphertext. Decaps takes the decapsulation key and the ciphertext and recovers the same shared secret key. SP 800-227 gives three examples: ECDH-KEM and RSASVE-KEM, both quantum-vulnerable, and ML-KEM, the NIST-approved post-quantum KEM.
What SP 800-227 Covers
The document is organised around three kinds of security:
- Theoretical security: choosing a KEM that is well defined, correct and secure, with IND-CCA security against active attackers as the main goal.
- Implementation security: implementing the KEM correctly, complying with NIST standards and validation, and managing keys, shared secrets and intermediate values properly.
- Deployment security: using the KEM correctly in an application. This includes post-processing the shared secret with an approved key-derivation method, key confirmation, proof of possession of KEM keys, and multi-algorithm KEMs.
Hybrid KEMs in SP 800-227
Section 4.6 covers multi-algorithm key establishment. A hybrid PQ/T scheme combines one post-quantum component with one traditional, quantum-vulnerable component, so that the result stays secure as long as at least one component does. SP 800-227 names X-Wing, which combines ML-KEM with X25519, as an example.
A multi-algorithm scheme has two stages:
- Establish shared secrets: run every component scheme, typically in parallel, so both parties hold one shared secret per component.
- Combine shared secrets: each party runs a key combiner that turns those shared secrets into one shared secret key.
For two component KEMs, SP 800-227 describes a composite KEM whose key combiner receives both shared secrets, both ciphertexts, both encapsulation keys and the parameter set.
Approved Key Combiners
Section 4.6.2 approves two families of key combiners:
- From SP 800-56C key derivation: a one-step or two-step key-derivation method applied to all the shared secrets together. This is approved if at least one shared secret comes from SP 800-56A, SP 800-56B or an approved KEM such as ML-KEM. The other secrets may come from methods that are not approved. The FixedInfo input can carry ciphertexts, encapsulation keys, parameter sets and domain separators.
- From SP 800-133 key combination: concatenation, XOR, or extraction with HMAC. These are allowed only when every component is approved, and a concatenated result should pass through a key-derivation function before use.
Why the Combiner Choice Matters
Section 4.6.3 points out a trap: a combiner that hashes only the two shared secrets, K = KDF(K1, K2), does not in general preserve IND-CCA security when only one component is IND-CCA secure, whatever KDF is used. NIST therefore encourages combiners that preserve IND-CCA security generically. Its example hashes the shared secrets together with both ciphertexts, both encapsulation keys and a domain separator, using a SHA-3 hash: H(K1, K2, c1, c2, ek1, ek2, domain_sep). The cited analysis shows this preserves IND-CCA security when the hash is modelled as a random oracle. Including the encapsulation keys is not needed for that property, but it can bind the result to the parties' identities.
SP 800-227 also warns that composite schemes add complexity and protocol choices, which can bring new vulnerabilities such as downgrade attacks.
Hybrids in Practice
The most widely deployed hybrid is the TLS 1.3 group X25519MLKEM768, which combines ML-KEM-768 and X25519. According to Cloudflare's documentation, it is the default in Chrome 131 and later, Edge 131 and later, Firefox 132 and later on desktop, and Safari 26 and later. Cloudflare reported that the share of human-generated web traffic it carries that is post-quantum encrypted rose from 29% at the start of 2025 to 52% in early December 2025.
Where QNSQY Stands
QNSQY uses hybrid key establishment by default for file encryption: ML-KEM with X25519, at ML-KEM-512 on Free, ML-KEM-768 on Pro and ML-KEM-1024 on Business, with a pure ML-KEM option on Business. It combines the two shared secrets with BLAKE3 in key-derivation mode, using length-prefixed inputs and a version label, and then derives the file keys with HKDF-SHA3-256 and a fresh random salt.
BLAKE3 is not an approved key-derivation function under SP 800-56C, so QNSQY's standard hybrid combiner is not one of the key combiners SP 800-227 approves. QNSQY is not FIPS 140-3 validated. Its approved-mode build, which is not yet released, uses ML-KEM-1024 on its own instead. See hybrid encryption for how QNSQY's files are built.
Frequently Asked Questions
Does NIST require hybrid key establishment?
No. ML-KEM (FIPS 203) on its own is approved. SP 800-227 describes how to build approved multi-algorithm schemes for those who want a hybrid during the migration. NSA's CNSA 2.0 does not require hybrids either.
What must a hybrid key combiner use?
To be approved under SP 800-227, a combiner must be built from an SP 800-56C key-derivation method, with at least one shared secret from an approved scheme such as ML-KEM, or from an SP 800-133 key-combination method when all components are approved.
Should the combiner include the ciphertexts?
SP 800-227 encourages combiners that preserve IND-CCA security, and its example includes both ciphertexts, both encapsulation keys and a domain separator. A combiner over the shared secrets alone does not preserve IND-CCA security in general.
Can ML-KEM be combined with RSA?
Yes. SP 800-227 treats RSA secret-value encapsulation (RSASVE-KEM) as a KEM, and an approved combiner only needs one of the shared secrets to come from an approved scheme.
Is QNSQY's hybrid an SP 800-227 approved composite KEM?
No. QNSQY combines the ML-KEM and X25519 shared secrets with BLAKE3, which is not an SP 800-56C approved key-derivation function. QNSQY's approved-mode build, not yet released, uses ML-KEM-1024 alone.
Sources
- NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms, NIST, September 2025
- FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, NIST, August 2024
- NIST SP 800-56C Rev. 2, Recommendation for Key-Derivation Methods in Key-Establishment Schemes, NIST, August 2020
- Barbosa M, Connolly D, Duarte JD, Kaiser A, Schwabe P, Varner K, Westerbaan B. "X-Wing." IACR Communications in Cryptology 1(1), 2024. https://doi.org/10.62056/a3qj89n4e
- Giacon F, Heuer F, Poettering B. "KEM Combiners." PKC 2018, pp. 190 to 218.
- Cloudflare, Post-quantum cryptography support and 2025 Radar Year in Review
Related Articles
- Hybrid encryption
- ML-KEM explained
- FIPS 203 walkthrough
- NIST SP 800-56A on key establishment
- NIST FIPS guide
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.