up:: FIPS 203 (ML-KEM)
ML-KEM-1024
ML-KEM-1024 is the largest and most conservative of the three parameter sets defined in FIPS 203, the NIST post-quantum standard for key establishment, and it targets NIST security category 5, the highest tier, whose strength is anchored to a brute-force search of an AES-256 key. It does the same key-encapsulation job as its siblings, agreeing on a shared secret over an open network, and it carries the largest artifacts of the family, a 1,568-byte encapsulation key and a 1,568-byte ciphertext. That extra size buys the widest post-quantum margin the standard offers, which is why ML-KEM-1024 is the choice for national-security systems, classified contexts, and data whose confidentiality has to hold for decades, while NIST recommends ML-KEM-768 as the general-purpose default for everything else.
Source: NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, Table 3, August 2024.
The short version:
- ML-KEM-1024 is a key-encapsulation mechanism, so it establishes a shared secret. It is not a signature algorithm. (Signatures are ML-DSA and its siblings.)
- It sits at NIST security category 5, the highest of the three ML-KEM tiers, benchmarked to the difficulty of searching an AES-256 key.
- Its encapsulation (public) key is 1,568 bytes, its decapsulation (private) key is 3,168 bytes, its ciphertext is 1,568 bytes, and the shared secret it produces is 32 bytes.
- It is the highest-assurance set, for national-security, classified, and very-long-lifetime data. NIST recommends ML-KEM-768 as the default for general use.
- Its security rests on lattice math (Module-LWE), which Shor’s algorithm does not break.
What is ML-KEM-1024?
ML-KEM-1024 is the category-5 parameter set of ML-KEM, the standardized form of the algorithm known during the NIST competition as CRYSTALS-Kyber. A key-encapsulation mechanism lets two parties agree on a shared secret over an untrusted channel in three moves: the recipient publishes a public encapsulation key, the sender uses it to generate a fresh shared secret and a ciphertext, and the recipient uses the private decapsulation key to recover the same secret. ML-KEM-1024 runs that protocol at the strongest parameters the standard defines, which is what gives it the widest margin and the largest artifacts.
The “1024” refers to the internal lattice dimension the parameter set uses, not to a key length in bits. What it tracks in practice is the security category: ML-KEM-1024 is claimed at category 5, above ML-KEM-768 at category 3 and ML-KEM-512 at category 1. The security of all three rests on the Module-LWE problem, a lattice hardness assumption with no known efficient solution on a classical or a quantum computer, which is what makes ML-KEM the replacement for the ECDH key exchange that Shor’s algorithm destroys.
Source: NIST FIPS 203, §8, August 2024.
What are ML-KEM-1024’s sizes and security category?
The parameters are the thing to internalize, because they are where the engineering cost lives. These figures are verbatim from Table 3 of the standard.
| Property | Value |
|---|---|
| NIST security category | Category 5 (anchored to AES-256 key search) |
| Encapsulation (public) key | 1,568 bytes |
| Decapsulation (private) key | 3,168 bytes |
| Ciphertext | 1,568 bytes |
| Shared secret | 32 bytes |
The scale to note is the step up from the default. ML-KEM-1024’s encapsulation key and ciphertext are each 1,568 bytes, roughly a third larger than ML-KEM-768’s 1,184-byte key and 1,088-byte ciphertext, and its decapsulation key of 3,168 bytes is the largest private key of the three sets. The compute is slightly heavier than the default and the bandwidth impact is manageable in most modern deployments, so the reason to choose it is assurance, and the price is bytes rather than a meaningful performance hit.
Source: NIST FIPS 203, Table 3, August 2024.
When should you use ML-KEM-1024?
ML-KEM-1024 is the set you reach for when the security margin matters more than the artifact size, and for general enterprise use ML-KEM-768 remains the recommended default. NIST’s guidance to select the strongest practical parameter set at first deployment is what points high-assurance systems to category 5, so that no future improvement in cryptanalysis erodes protection over a long horizon. The roles where it fits:
- National-security and classified contexts. Where the highest security margin is a policy requirement rather than a preference, category 5 is the appropriate floor.
- Very long data lifetimes. Archives, key hierarchies, and records that must stay confidential for 30 years or more should carry the largest margin, because their secrecy has to outlast decades of unknown progress.
- High-assurance PKI roots and key hierarchies. A key that protects many other keys concentrates risk, so a conservative parameter choice at the root buys the most margin for the least incremental cost.
The tradeoff is deliberately narrow. ML-KEM-1024 costs about a third more bytes than the default and a little more compute, and in return it moves the security category from 3 to 5. For most estates that tradeoff does not pay, which is why NIST sets the default lower, and for the high-assurance and long-lifetime slice it is exactly the right call.
Source: NIST FIPS 203, §8, August 2024.
Common misconceptions
- “The 1024 means a 1024-bit key.” It does not. The number reflects the internal lattice dimension and maps to security category 5, not to a key length in bits. The public key is 1,568 bytes.
- “ML-KEM-1024 should be the default because bigger is safer.” NIST recommends ML-KEM-768 as the default because category 3 suits most uses at lighter cost. Category 5 is worth its extra bytes only where policy or a long retention horizon calls for it.
- “ML-KEM-1024 is dramatically slower.” Its compute is only slightly heavier than the default. The real cost is size, roughly a third larger keys and ciphertexts, not a performance cliff.
- “CNSA 2.0 requires ML-KEM-1024 specifically.” CNSA 2.0 requires ML-KEM at the category-5 level for national-security systems, which is the assurance ML-KEM-1024 provides, but confirm the exact requirement against the current CNSA 2.0 text before citing it as a named-parameter mandate.
[OPERATOR VERIFY: confirm CNSA 2.0 wording ties the requirement to ML-KEM-1024 by name or to category 5.]
Questions people ask
When should I choose ML-KEM-1024 over the default? When the security margin has to be maximal: national-security or classified systems, data with very long confidentiality lifetimes, and high-assurance PKI roots. For general enterprise use, ML-KEM-768 is the recommended default.
How much larger is ML-KEM-1024 than ML-KEM-768? Its encapsulation key and ciphertext are each 1,568 bytes against 1,184 and 1,088, roughly a third larger, and its decapsulation key is 3,168 bytes against 2,400. The shared secret is 32 bytes for both.
Is ML-KEM-1024 much slower than the smaller sets? Only slightly. The computation is modestly heavier and the bandwidth impact is manageable in most deployments, so the binding cost is size rather than speed.
Does ML-KEM-1024 do signatures? No. It is a key-encapsulation mechanism, so it handles key establishment only. Signatures are the job of ML-DSA, SLH-DSA, and FN-DSA.
Is ML-KEM-1024 required for national-security systems? CNSA 2.0 requires the highest-assurance ML-KEM level for national-security systems, which is category 5, the tier ML-KEM-1024 provides. Confirm the exact parameter wording against the current CNSA 2.0 advisory before quoting it.
Everything here is the map, given freely. When your team needs to decide where the category-5 margin of ML-KEM-1024 is worth its size against your own assurance and retention requirements, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.