Back to insights
PQC ResearchMay 20268 min read

Why ML-KEM-1024 is the new standard for secure communications

In August 2024 NIST finalised FIPS 203, elevating ML-KEM (formerly known as CRYSTALS-Kyber) to the status of mandatory federal standard for key encapsulation. For organisations defending data with a confidentiality horizon longer than five years, ML-KEM-1024 is no longer optional.

The end of an era for RSA and elliptic curves

For five decades, asymmetric cryptography has rested on two mathematical assumptions: the difficulty of factoring large integers, and the intractability of the discrete logarithm problem over elliptic curves. RSA, Diffie-Hellman and ECDH have protected everything from TLS handshakes to military command-and-control links, with security margins that grew along with key sizes.

Shor's algorithm, first described in 1994, broke this paradigm in theory. A sufficiently large fault-tolerant quantum computer would solve both problems in polynomial time, reducing 3072-bit RSA and P-256 ECC to trivially recoverable secrets. What kept the security community calm was the engineering gap between theoretical algorithm and practical machine. That gap is closing faster than most defenders are prepared to admit.

Recent progress on logical qubit error correction, surface codes and dynamic circuit compilation has shortened the most credible Q-Day estimates to a window centred on the next decade. For any data that must remain confidential beyond that window, the threat is not hypothetical: it is already here in the form of harvest-now decrypt-later collection, where adversaries archive encrypted traffic today to break it once the hardware exists [4][11].

What ML-KEM actually is

ML-KEM stands for Module-Lattice-Based Key-Encapsulation Mechanism. It is a key encapsulation scheme, not a digital signature: its job is to let two parties agree on a symmetric secret over an untrusted channel. The hard problem underneath it is Module-LWE, a structured variant of Learning With Errors over polynomial rings, which currently has no known sub-exponential quantum algorithm [5].

FIPS 203 specifies three parameter sets [1]. ML-KEM-512 targets NIST security category 1 (roughly AES-128). ML-KEM-768 targets category 3 (AES-192). ML-KEM-1024 targets category 5 (AES-256). The differences are in lattice dimensions and noise parameters, not in algorithmic structure. The encapsulation, decapsulation and key generation primitives are identical across all three.

The size cost is moderate but not negligible. An ML-KEM-1024 public key is 1568 bytes, a ciphertext is 1568 bytes, and a secret key is 3168 bytes. Compared to a 32-byte X25519 public key, this is a roughly 49x increase. For a TLS handshake, this means an additional few kilobytes on the wire per session. For most applications, this is irrelevant. For constrained radio links it requires engineering attention [6].

Why category 5, not category 3

The pragmatic question for any system architect is which parameter set to deploy. NIST accepts ML-KEM-768 as the default for most federal use. The NSA, through the CNSA 2.0 directive, mandates ML-KEM-1024 for all National Security Systems and any data classified at Secret or above [4]. The German BSI TR-02102-1 technical guideline similarly recommends category 5 parameters for any data with a protection horizon beyond ten years [9].

The argument for ML-KEM-1024 is not that ML-KEM-768 is broken. It is that the security margin against future cryptanalytic progress is meaningfully larger. Lattice cryptanalysis is an active field, and recent papers have refined the cost models for the BKZ family of lattice reduction algorithms. Each refinement has reduced the conjectured security level of ML-KEM-768 by a few bits. None have yet touched the margin of ML-KEM-1024.

For sovereign communications, defence applications and long-lived industrial secrets, the case is straightforward. The performance delta between category 3 and category 5 is on the order of 30 to 40 percent in CPU cycles, which for a key exchange that happens once per session is operationally invisible. The bandwidth delta is similar. There is no defensible reason to choose the smaller parameter set when protecting data with a multi-decade confidentiality requirement.

Hybrid deployment is not optional

Every credible deployment guidance, from NIST SP 800-227 [10] to the ETSI work on hybrid mechanisms to the German BSI [9], recommends hybrid key establishment during the transition period. A hybrid scheme combines a classical primitive (typically X25519 or ECDH P-384) with ML-KEM-1024, deriving the final session key from both shared secrets via a KDF such as HKDF-SHA384.

The reasoning is conservative. ML-KEM is young. It has survived four rounds of public scrutiny within the NIST PQC process [3], but the cryptanalytic community has had less than a decade with the final design. A subtle flaw in the lattice formulation, the noise sampling or the implementation could in principle reduce its effective security. The classical primitive is the safety net: as long as one of the two underlying problems remains hard, the session key is unrecoverable.

The cost of hybrid is one additional scalar multiplication and a KDF call, which is negligible. The complexity cost is real and is where most projects stumble. KDF inputs must be ordered correctly. Length-encoding must be unambiguous. Failure of one component must not leak information about the other. The IETF hybrid drafts, in particular draft-ietf-tls-hybrid-design [7], capture the consensus on these details.

Implementation pitfalls that have already cost teams

ML-KEM is structurally simple but operationally unforgiving. The Fujisaki-Okamoto transform used to achieve IND-CCA2 security relies on a re-encryption check inside decapsulation. Implementations that branch on the result of this check, or that release timing information about it, become vulnerable to chosen-ciphertext attacks that recover the long-term secret key in minutes. Constant-time implementation is not a recommendation, it is a requirement.

The polynomial arithmetic over the ring Z_q[x]/(x^256 + 1) with q = 3329 is typically accelerated using the Number Theoretic Transform. NTT implementations that use non-constant-time modular reductions, or that leak through cache timing, have been broken in published side-channel attacks [6]. Hardware implementations on FPGAs and dedicated accelerators have demonstrated full constant-time NTT, but software-only deployments on general-purpose CPUs require careful coding and regular testing with tools such as ctgrind or dudect.

Random number generation for the noise sampling is another failure mode. The reference implementation uses SHAKE-128 seeded by a 32-byte secret. Any reduction in the entropy of this seed compromises the entire scheme. Hardware-backed entropy from a certified TRNG, paired with a NIST SP 800-90A DRBG, is the only acceptable production configuration.

How this maps to the European regulatory landscape

ENISA's integration study on post-quantum cryptography sets out the European baseline for the migration [8]. Member states are now translating this into national mandates: the German BSI has aligned its cryptographic catalogue around ML-KEM-1024 and ML-DSA-87 [9], and the French ANSSI has issued technical positions requiring hybrid PQC for qualified products.

For vendors selling into European critical infrastructure, defence, telecommunications or finance, the operational implication is concrete. Any product whose certified lifecycle extends beyond 2030 must already include a PQC migration path. Any product entering the market in 2026 or later, if it claims to address long-confidentiality use cases, must ship with PQC enabled out of the box. Customers will increasingly ask not whether you support PQC but which parameter set you ship and how the hybrid is constructed [7].

What this means for you

If you operate or build systems that protect data with a confidentiality window beyond five years, ML-KEM-1024 in hybrid mode is the new baseline. Defaulting to ML-KEM-768 to save a few kilobytes is a false economy: you will rebuild the same system in three years under regulatory pressure, at significantly higher cost.

Practical first steps: inventory every place where RSA, ECDH or DH appears in your stack. Identify which of those touch data with a long confidentiality requirement. Engage your TLS, VPN and HSM vendors on their PQC roadmaps and demand hybrid ML-KEM-1024 with X25519. For custom protocols, follow the IETF hybrid drafts rather than rolling your own composition [7].

The transition will not be cheap, but the alternative is worse. Data exfiltrated today and broken in 2032 is not a hypothetical risk: it is the explicit operational thesis of every state-level signals intelligence agency on the planet. ML-KEM-1024 is the conservative, defensible, regulator-aligned answer to that thesis. It is the new standard because there is no longer any credible reason to choose anything weaker [1][4][9].

References

  1. NIST FIPS 203 — Module-Lattice-Based Key-Encapsulation Mechanism Standard (Aug 2024)
  2. NIST FIPS 204 — Module-Lattice-Based Digital Signature Standard (Aug 2024)
  3. NIST Post-Quantum Cryptography Standardization Project
  4. NSA — Post-Quantum Cybersecurity Resources (CNSA 2.0)
  5. Bos, Ducas et al. — CRYSTALS-Kyber: a CCA-secure module-lattice-based KEM (IACR ePrint 2017/634)
  6. Cloudflare — The state of the post-quantum Internet (2024)
  7. IETF — Hybrid key exchange in TLS 1.3 (draft-ietf-tls-hybrid-design)
  8. ENISA — Post-Quantum Cryptography: Integration Study
  9. BSI Technical Guideline TR-02102-1 — Cryptographic Mechanisms
  10. NIST SP 800-227 (Initial Public Draft) — Recommendations for Key-Encapsulation Mechanisms
  11. US Federal Migration to Post-Quantum Cryptography — OMB M-23-02 Memo

Ready to Secure Your Digital Sovereignty?

Join Europe's post-quantum security revolution. Contact our team for institutional partnerships and strategic collaborations.