up:: FIPS 203 (ML-KEM)
ML-KEM-512
ML-KEM-512 is the smallest of the three parameter sets defined in FIPS 203, the NIST post-quantum standard for key establishment, and it targets NIST security category 1, the tier whose strength is anchored to a brute-force search of an AES-128 key. It does the same key-encapsulation job as its larger siblings, agreeing on a shared secret over an open network so that fast symmetric cryptography can protect the traffic that follows, and it produces the smallest artifacts of the family, an 800-byte encapsulation key and a 768-byte ciphertext. That compactness is its whole reason to exist, because NIST recommends ML-KEM-768 as the general-purpose default and ML-KEM-512 is the set you reach for when bandwidth or memory is the binding constraint and category 1 is explicitly accepted by policy.
Source: NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, Table 3, August 2024.
The short version:
- ML-KEM-512 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 1, the lowest of the three ML-KEM tiers, benchmarked to the difficulty of searching an AES-128 key.
- Its encapsulation (public) key is 800 bytes, its decapsulation (private) key is 1,632 bytes, its ciphertext is 768 bytes, and the shared secret it produces is 32 bytes.
- NIST recommends ML-KEM-768 as the default, so ML-KEM-512 is the deliberate choice for constrained environments rather than the everyday one.
- Like every ML-KEM set, its security rests on lattice math (Module-LWE), which Shor’s algorithm does not break.
What is ML-KEM-512?
ML-KEM-512 is the category-1 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-512 runs that exact protocol with the smallest parameters in the family, which is why its keys and ciphertexts are the smallest of the three sets.
The “512” refers to the internal lattice dimension the parameter set uses, not to a key length in bits, so it should not be read the way “AES-128” names a key size. What the number tracks in practice is the security category: ML-KEM-512 is claimed at category 1, ML-KEM-768 at category 3, and ML-KEM-1024 at category 5. 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 a replacement for the ECDH key exchange that Shor’s algorithm destroys.
Source: NIST FIPS 203, §8, August 2024.
What are ML-KEM-512’s sizes and security category?
The parameters are the thing to internalize, because they are where the engineering cost lives and where ML-KEM-512 differs from its siblings. These figures are verbatim from Table 3 of the standard.
| Property | Value |
|---|---|
| NIST security category | Category 1 (anchored to AES-128 key search) |
| Encapsulation (public) key | 800 bytes |
| Decapsulation (private) key | 1,632 bytes |
| Ciphertext | 768 bytes |
| Shared secret | 32 bytes |
For scale, an ML-KEM-512 encapsulation key is 800 bytes where a classical elliptic-curve public key is 32 bytes, so even the smallest post-quantum set is more than twenty times larger on the wire. The compute is fast. The bytes are what you plan around, and ML-KEM-512 exists precisely for the environments where those bytes have to be as few as the standard allows.
Source: NIST FIPS 203, Table 3, August 2024.
When should you use ML-KEM-512 instead of ML-KEM-768?
NIST recommends ML-KEM-768 as the general-purpose default, so the honest framing is that ML-KEM-512 is the exception, not the starting point. NIST’s own guidance is to select the strongest practical parameter set when first establishing protections, so that a later upgrade is not forced, and for most systems that means ML-KEM-768. ML-KEM-512 earns its place in a narrower set of conditions:
- Severely constrained transport or memory. When key shares and ciphertexts have to fit inside tight datagram or buffer limits, the several-hundred-byte difference between category 1 and category 3 can decide whether the handshake fits at all.
- Category 1 is explicitly accepted by policy. The lower security margin should be a documented decision, not a default that slipped in, because the data protected by the session inherits that margin.
- Short confidentiality lifetimes. Where the traffic stops mattering quickly, the smaller margin is easier to accept than it is for data that must stay secret for decades.
On a real constrained device the tradeoff can even invert in ML-KEM-512’s favor on speed. In a 2026 measurement on an ESP32-class microcontroller running a DTLS 1.3 handshake, ML-KEM-512 was the fastest key exchange tested, beating elliptic-curve options, because its lattice arithmetic maps well to that processor. The catch was memory and transport: its key shares exceeded the datagram limit and forced fragmentation, and only this lowest level fit the device’s SRAM, with the higher levels deferred to more capable hardware. The binding constraint on those devices is size and memory, not cryptographic performance. See Constrained-Device PQC.
Sources: NIST FIPS 203, §8, August 2024; Blanco-Romero et al., arXiv:2603.10274 (2026), Tables 1 and 5.
Common misconceptions
- “ML-KEM-512 is too weak to use.” It is a NIST-standardized category-1 set, adequate by design for the environments it targets. It is not the recommended default, which is a different statement from insecure. The right question is whether category 1 suits the data and the retention horizon, not whether the set is broken.
- “The 512 means a 512-bit key, like AES.” It does not. The number reflects the internal lattice dimension and maps to security category 1, not to a key length in bits. The public key is 800 bytes, not 64.
- “Smaller parameters mean weaker math.” All three ML-KEM sets rest on the same Module-LWE problem. The smaller set targets a lower security category with smaller artifacts, not a different or weaker foundation.
- “If I pick ML-KEM-512 I can upgrade for free later.” Upgrading the parameter set changes the sizes on the wire and in storage, which can ripple through protocol limits and buffers, so NIST advises choosing the strongest practical set up front to avoid exactly that rework.
Questions people ask
Is ML-KEM-512 secure? Yes, as a NIST-standardized category-1 KEM. Its security rests on the same lattice problem as the larger sets, and Shor’s algorithm does not break it. The caution is about margin, because NIST recommends ML-KEM-768 as the default and reserves category 1 for constrained cases.
Why would I choose ML-KEM-512 over the default? Almost always for size. When key shares or ciphertexts have to fit inside tight transport or memory limits, ML-KEM-512’s smaller artifacts are the reason to accept category 1, ideally as a documented policy decision.
How much smaller is ML-KEM-512 than ML-KEM-768? Its encapsulation key is 800 bytes against 1,184, its ciphertext is 768 bytes against 1,088, and its decapsulation key is 1,632 bytes against 2,400. The shared secret is 32 bytes for both.
Does ML-KEM-512 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-512 what browsers deploy? No. The hybrid key exchange going into TLS pairs a classical algorithm with ML-KEM-768, the category-3 default, not ML-KEM-512. ML-KEM-512 shows up more in constrained-device and bandwidth-limited settings.
Everything here is the map, given freely. When your team needs the right ML-KEM parameter set chosen against your own transport limits and retention horizons, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.