A ransomware crew calling itself “Kyber” spent the spring of 2026 doing something no criminal group had done before: encrypting victim data with a NIST-standardized post-quantum algorithm. According to a Cloud Security Alliance research note published April 23, 2026, the group’s Windows payload genuinely implements ML-KEM-1024, the top security tier of the algorithm the world knows as Kyber, to protect its symmetric encryption keys. That single incident dragged a decade-old academic rivalry back into the news: ML-KEM, standardized by NIST in FIPS 203, beat out a competing lattice design called NTRU for the title of “the” post-quantum key exchange algorithm. NTRU didn’t disappear, though. It still runs inside OpenSSH connections and commercial SSH stacks today, just without NIST’s blessing.
This comparison breaks down what ML-KEM and NTRU actually are, why NIST picked one over the other in 2022, how their key sizes and performance stack up, where each one is deployed in 2026, and what the practical migration path looks like if you’re still running RSA, ECDH, or an NTRU-based hybrid today. It’s part of this site’s ongoing cryptography coverage tracking how the post-quantum standards fight plays out in real infrastructure.
The stakes here go beyond an academic footnote. Every TLS handshake, SSH login, and encrypted message sent today can theoretically be recorded and decrypted later once a sufficiently powerful quantum computer exists, an approach security researchers call harvest-now-decrypt-later. That risk is why governments, browser vendors, and cloud providers spent the back half of the 2020s racing to swap classical RSA and elliptic-curve key exchange for lattice-based alternatives, and why the choice between ML-KEM and NTRU isn’t just theoretical for anyone running infrastructure that needs to stay confidential for years or decades.
Why NIST Chose Kyber Over NTRU in the First Place
ML-KEM and NTRU are not rival newcomers. Both are structured-lattice key encapsulation mechanisms, and both spent years inside NIST’s Post-Quantum Cryptography standardization project, which ran its Round 3 evaluation through 2020 and 2021. The finalists in the lattice KEM category included CRYSTALS-Kyber, built by a team including researchers from CWI Amsterdam and NXP, NTRU, a scheme dating back to 1996, one of the oldest lattice cryptosystems in existence, and NTRU Prime, a hardened variant designed by Daniel J. Bernstein and collaborators specifically to avoid structure some cryptographers worried could be exploited.
NIST’s 2022 status report on Round 3, NIST IR 8413, settled the question. The agency picked Kyber as its single standardized structured-lattice KEM and, in the report’s own words, “NIST also decided to remove FrodoKEM, NTRU Prime and Picnic from consideration for standardization.” NTRU itself, the original scheme, had already fallen out of the running earlier in the process. NIST wasn’t reacting to a cryptographic break in either algorithm. Kyber and NTRU Prime were both considered secure. The decision came down to NIST wanting one standardized answer instead of two competing ones in the same design space, and Kyber had the edge on performance, smaller combined key and ciphertext sizes at comparable security levels, and a head start in open-source implementations like liboqs and PQClean that vendors had already started testing against.
Kyber became ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism, when NIST finalized FIPS 203 on August 13, 2024. NTRU Prime didn’t vanish from the internet, though. A specific parameter set called sntrup761 lives on inside OpenSSH’s hybrid key exchange, and commercial libraries like wolfSSL still ship NTRU support for customers who want it. It just never became a government standard, and that single fact shapes almost every practical decision in this comparison.
The full timeline stretched almost a decade. NIST issued its call for post-quantum proposals in December 2016, received 82 initial submissions in 2017, narrowed the field to 26 candidates for Round 2 in 2019, and picked Kyber, NTRU, Saber, and Classic McEliece as its four lattice and code-based KEM finalists heading into Round 3 in 2020. NTRU Prime, a more conservative variant designed to resist a specific class of algebraic attacks some researchers worried could apply to ring-structured lattices, ran as an alternate candidate throughout that same period. By the time NIST published its Round 3 results in 2022, Kyber had built up the strongest combination of a clean security proof, competitive benchmarks across constrained and server hardware, and early implementation work from companies already testing it in production TLS traffic. That momentum, as much as any single technical metric, is what tipped the final decision.
ML-KEM vs NTRU: Full Specs Comparison
Before getting into benchmarks, it helps to see both algorithm families side by side. NTRU ships multiple parameter families, HPS and HRSS, each targeting different NIST security categories, while NTRU Prime’s sntrup761 is the variant actually deployed in production SSH traffic today.
| Attribute | ML-KEM (Kyber) | NTRU / NTRU Prime |
|---|---|---|
| NIST standardization status | Standardized, FIPS 203, final August 13, 2024 | Not standardized; NTRU Prime removed from Round 3 consideration in 2022 |
| Underlying hard problem | Module Learning With Errors (Module-LWE) | NTRU lattice problem (Shortest Vector Problem variant) |
| Origin | CRYSTALS-Kyber, submitted 2017 | NTRU, first published 1996; NTRU Prime, 2016 |
| Parameter sets | ML-KEM-512, ML-KEM-768, ML-KEM-1024 | NTRU-HPS, NTRU-HRSS, sntrup761 (NTRU Prime) |
| Security categories covered | Category 1, 3, 5 | Category 1 through roughly 5, plus an intermediate sntrup761 tier |
| FIPS 140-3 compliant | Yes, via FIPS 203 | No |
| Reference library support | OpenSSL 3.2+, BoringSSL, wolfCrypt, liboqs | liboqs, wolfSSL/wolfSSH, OpenSSH (sntrup761 only) |
| Browser/CDN support (2026) | Chrome, Cloudflare, most major TLS 1.3 hybrid deployments | None identified in mainstream browsers or CDNs |
| Messaging protocol use | Signal PQXDH, Apple iMessage PQ3 | Not used in mainstream messaging protocols |
| Default in OpenSSH 10.0+ | mlkem768x25519-sha256 | sntrup761x25519-sha512 remains available, no longer default |
| Known real-world criminal use | Kyber ransomware group, ML-KEM-1024, documented April 2026 | None documented |
| Long-term support outlook | Guaranteed by NIST standardization | Dependent on individual vendors continuing support |
Key and Ciphertext Sizes, Byte by Byte
Post-quantum KEMs trade the tiny 32-byte keys of classical elliptic-curve cryptography for something much larger, and the exact size matters for anything sensitive to handshake overhead, from embedded devices to QUIC packets that risk fragmentation. FIPS 203 specifies exact byte counts for every ML-KEM parameter set, and the NTRU family’s sizes come from the liboqs and PQClean reference implementations that NIST’s own evaluation drew on.
| Parameter set | Public key | Secret key | Ciphertext |
|---|---|---|---|
| ML-KEM-512 | 800 bytes | 1,632 bytes | 768 bytes |
| ML-KEM-768 | 1,184 bytes | 2,400 bytes | 1,088 bytes |
| ML-KEM-1024 | 1,568 bytes | 3,168 bytes | 1,568 bytes |
| NTRU-HPS2048509 (Cat. 1) | 699 bytes | 935 bytes | 699 bytes |
| NTRU-HRSS701 (Cat. 1) | 1,138 bytes | 1,450 bytes | 1,138 bytes |
| NTRU-HPS2048677 (Cat. 3) | 931 bytes | 1,234 bytes | 931 bytes |
| NTRU-HPS4096821 (Cat. 5) | 1,230 bytes | 1,590 bytes | 1,230 bytes |
| sntrup761 (NTRU Prime) | 1,158 bytes | 1,763 bytes | 1,039 bytes |
The pattern holds across every tier: NTRU’s HPS and HRSS variants pack a smaller public key and ciphertext than the closest ML-KEM equivalent, sometimes by 20 to 30 percent. At Category 1, NTRU-HPS2048509 needs 699 bytes for its public key against ML-KEM-512’s 800. At Category 5, NTRU-HPS4096821 comes in at 1,230 bytes against ML-KEM-1024’s 1,568. Those differences matter for constrained devices and high-throughput handshake servers, but they’re not large enough on their own to outweigh the fact that only one of these algorithms has a NIST stamp on it.
Performance Benchmarks: Keygen, Encapsulation, Decapsulation
Raw speed numbers for post-quantum algorithms vary by CPU, compiler flags, and whether an implementation uses AVX2 or NEON vectorization, so treat any single cycle count as a snapshot rather than gospel. Three independent sources point in the same direction, though: the Open Quantum Safe project’s liboqs benchmark suite, the PQClean reference implementations that feed into it, and NIST’s own FIPS 203 performance commentary.
| Operation / parameter set | Approx. CPU cycles (x86-64, 3GHz+) | Source basis |
|---|---|---|
| ML-KEM-512 keygen/encaps/decaps | ~80,000-120,000 cycles each | liboqs/PQClean 2024-2025 benchmark runs |
| ML-KEM-768 keygen/encaps/decaps | ~120,000-150,000 cycles each | liboqs/PQClean 2024-2025 benchmark runs |
| ML-KEM-1024 keygen/encaps/decaps | ~160,000-200,000+ cycles each | liboqs/PQClean 2024-2025 benchmark runs |
| NTRU-HPS/HRSS (Cat. 1) keygen/encaps/decaps | ~100,000-200,000+ cycles each | liboqs/PQClean 2024-2025 benchmark runs |
| sntrup761 key exchange (OpenSSH context) | Comparable to ML-KEM-512, low hundreds of microseconds per handshake | OpenSSH and liboqs implementation notes |
ML-KEM comes out at or near the front of the pack across most independent benchmark sets, especially at the 512 and 768 tiers most deployments actually use. NTRU-HPS and HRSS are competitive rather than clearly slower, and sntrup761 in particular holds its own against ML-KEM-512 in real OpenSSH handshake measurements. Neither algorithm imposes an overhead that would be noticeable to an end user browsing a website or opening an SSH session. The gap that matters in practice isn’t cycles, it’s the fact that only ML-KEM ships with hardware-accelerated, side-channel-hardened implementations baked into mainstream TLS libraries by default.
Security Foundations: Module Lattices vs NTRU Lattices
Both algorithms rely on lattice problems believed to resist quantum computers, but they lean on different mathematical structures. ML-KEM’s security rests on Module Learning With Errors, a problem built from structured matrices over polynomial rings, chosen partly because decades of cryptanalysis against related LWE problems gave NIST’s evaluators confidence in its hardness margins. NTRU instead relies on a variant of the Shortest Vector Problem defined directly over its own polynomial ring structure, a design that predates Module-LWE by roughly two decades and has itself weathered a long stretch of academic attack attempts without a practical break.
Neither problem has a known efficient quantum algorithm as of September 2026, and NIST’s own FIPS 203 documentation, its only public update being a minor planning note from November 2025 flagging “an issue that will be corrected in a future update/revision,” concerns implementation-level clarifications rather than a cryptanalytic weakness. The reason both algorithms resist quantum attack in the first place comes down to what Shor’s algorithm can and can’t do: it factors large integers and solves discrete logarithms efficiently on a quantum computer, which is exactly why RSA and elliptic-curve cryptography are considered dead the moment a large enough fault-tolerant quantum machine exists. Lattice problems like Module-LWE and the NTRU problem don’t reduce to either of those operations, so Shor’s algorithm doesn’t apply. The main quantum threat lattice schemes do face is Grover’s algorithm, which offers a quadratic speedup on brute-force search and effectively halves the bit-security of a symmetric key or lattice problem, a much smaller hit that both ML-KEM and NTRU’s parameter sets were designed to absorb with margin to spare.
The practical security argument that keeps coming up in cryptography circles isn’t which lattice problem is stronger. It’s whether concentrating the entire internet’s post-quantum key exchange on one problem family, Module-LWE, creates a single point of failure. That’s the same logic NIST used when it later added HQC, a code-based algorithm built on an entirely different hard problem, as a backup KEM standard specifically so a future break in lattice cryptography wouldn’t leave the internet with nothing to fall back on, a decision covered in more depth in this site’s ML-KEM vs HQC comparison.
The Kyber Ransomware Story: When Post-Quantum Crypto Turns Criminal
The most concrete 2026 news event tied to this comparison isn’t a benchmark or a standards update, it’s a crime. The Cloud Security Alliance’s research note, published April 23, 2026, documents a ransomware operation that named itself Kyber and built its Windows encryptor around ML-KEM-1024, paired with X25519 and AES-256-CTR, to protect the symmetric keys locking victim files. CSA researchers describe it as the first known criminal operation to deploy a NIST-standardized post-quantum algorithm in a live attack, and they note the group appears to have folded ML-KEM-1024 into its payload by around March 2026, roughly nineteen months after FIPS 203 became final.
The group also runs a variant targeting VMware ESXi hosts, and that variant is worth flagging separately: it claims to use post-quantum encryption too, but researchers found it actually relies on conventional RSA-4096 and a cipher called ChaCha8, not any lattice-based scheme. Only the Windows payload’s ML-KEM-1024 implementation appears genuine.
None of this means ML-KEM itself is compromised. The ransomware group didn’t break the algorithm, they adopted it the same way any developer would, by pulling a standardized, well-documented, freely available implementation off the shelf. The story is really about how fast standardized cryptography moves from lab to deployment, in both defensive and offensive contexts, once NIST puts its name on it. It’s also a preview of the harvest-now-decrypt-later defense argument playing out in reverse: a criminal group locking data behind an algorithm designed to resist decryption even by a future quantum computer.
For defenders, the practical takeaway is narrow but important: incident response teams that assumed post-quantum cryptography was still years away from touching real attacks now have a documented counterexample sitting in their threat model. Decryption-key recovery techniques that work against ransomware relying on classical RSA or weak custom encryption will not work against a correctly implemented ML-KEM-1024 payload, which is exactly the property the algorithm was designed to guarantee. That’s a reminder that standardization cuts both ways, the same qualities that make ML-KEM trustworthy for defenders make it just as reliable for attackers who bother to implement it correctly.
Standardization Status: FIPS 203 vs NTRU’s Road Not Taken
FIPS 203 became final on August 13, 2024, and took effect the following day after sign-off from the Secretary of Commerce, alongside FIPS 204 for digital signatures (ML-DSA, formerly Dilithium) and FIPS 205 (SLH-DSA, formerly SPHINCS+). That gives ML-KEM the full weight of a US federal cryptographic standard: mandatory for federal systems on a NIST-set migration timeline, a requirement baked into FIPS 140-3 validated cryptographic modules, and the default target for every major cloud provider and browser vendor’s post-quantum rollout plan.
NTRU never got that path. NIST IR 8413 closed the door on NTRU Prime’s standardization in 2022, and the original NTRU scheme had already dropped out earlier in the Round 3 process. That leaves NTRU and its variants in an unusual spot for 2026: cryptographically respected, implemented in serious libraries, actively used in production SSH traffic, but permanently excluded from FIPS compliance and from the standardized codepoints that browsers, CDNs, and cloud KMS providers build their post-quantum roadmaps around. Any organization that needs to check a FIPS 140-3 compliance box has exactly one lattice KEM option, and it isn’t NTRU.
How ML-KEM Fits NIST’s Broader Post-Quantum Portfolio
ML-KEM doesn’t stand alone. NIST finalized it alongside two signature algorithms in the same August 2024 batch: ML-DSA (FIPS 204, built from CRYSTALS-Dilithium) as the default post-quantum signature scheme, and SLH-DSA (FIPS 205, built from SPHINCS+) as a more conservative, hash-based backup. A close look at how ML-KEM and ML-DSA divide the key exchange and signing workload shows the same design philosophy at work twice: pick one fast, efficient primary algorithm per category, then keep a structurally different backup in reserve. NIST later extended that logic to signatures again with FN-DSA, and a deeper look at the gap between FN-DSA and ML-DSA shows how signature size and standards timing shaped that follow-up decision the same way NTRU’s exclusion shaped this one.
Key exchange got the same backup treatment. NIST didn’t stop after standardizing ML-KEM; it kept HQC, a code-based KEM with no relationship to lattice mathematics, in reserve specifically as insurance against a future lattice break. Bandwidth and compute costs differ sharply between the two, a tradeoff covered in detail in the ML-KEM vs HQC breakdown, but the underlying strategic point is the same one that runs through this NTRU comparison: NIST’s post-quantum portfolio isn’t really about picking a single winner forever, it’s about making sure the internet never depends on exactly one unbroken math problem at a time. Where TLS 1.3 fits into that migration is covered separately in this site’s ML-KEM vs X25519 TLS 1.3 comparison, and how ML-KEM stacks up against the classical RSA it’s slowly replacing is covered in the ML-KEM vs RSA comparison.
Where ML-KEM Runs in Production Today
ML-KEM’s standardization translated into real deployment faster than most NIST algorithms typically see. Cloudflare has run hybrid post-quantum key exchange across its edge network since well before FIPS 203 finalized, and has continued aligning its production hybrid suites with the standardized ML-KEM parameter sets rather than the pre-standard Kyber round submissions. Chrome shipped hybrid X25519Kyber768, later transitioning toward the FIPS 203-aligned X25519MLKEM768 group, to a majority of its desktop traffic, making ML-KEM one of the most widely negotiated TLS key exchange mechanisms on the modern web whether users notice it or not.
The pattern repeats across messaging and infrastructure. Signal’s PQXDH protocol layers Kyber-based key establishment into its Signal Protocol handshake to protect against harvest-now-decrypt-later attacks on stored ciphertext. Apple’s PQ3 protocol, which secures iMessage, does the same. AWS has rolled hybrid post-quantum TLS support into services touching Key Management Service and Certificate Manager traffic, following NIST’s post-FIPS-203 migration guidance. And as of OpenSSH 10.0, mlkem768x25519-sha256 is the default key exchange algorithm for new SSH connections, replacing the NTRU-based hybrid that had held that spot for several prior releases.
VPN vendors and enterprise networking gear followed the same path once FIPS 203 landed. IPsec and WireGuard-adjacent hybrid key exchange proposals moved to reference ML-KEM specifically rather than pre-standard Kyber round submissions, and enterprise firewall vendors building FIPS-validated appliances had no real alternative once compliance auditors started asking for FIPS 203 by name instead of a generic “post-quantum” checkbox. That compliance pressure, more than any single benchmark win, is why ML-KEM’s production footprint grew so quickly in the two years after standardization.
Where NTRU and NTRU Prime Still Survive
NTRU’s production footprint in 2026 is smaller but real. OpenSSH still ships [email protected] as an available hybrid key exchange method, a holdover from the years before ML-KEM support landed, when sntrup761 was effectively the only post-quantum option available to SSH administrators wanting protection today rather than waiting for a NIST standard. Millions of servers still negotiate it, either because they’re running an OpenSSH version predating 10.0’s ML-KEM default, or because an administrator pinned it deliberately.
wolfSSL and wolfSSH continue to advertise NTRU and NTRU Prime support as optional post-quantum mechanisms for embedded TLS and SSH deployments, independent of NIST’s standardization decision, aimed at customers already invested in NTRU or working in constrained environments where its slightly smaller key sizes matter. Academic and research testbeds also keep NTRU-HPS and HRSS in active use, both as a genuine security option and as a diversity hedge against the possibility that Module-LWE cryptanalysis advances faster than expected.
Cryptocurrency infrastructure is a smaller but growing corner of this same conversation. Wallet software and node implementations experimenting with post-quantum signatures ahead of any eventual break in elliptic-curve cryptography have mostly followed the ML-KEM and ML-DSA standards track for the same compliance and interoperability reasons everyone else has, though a handful of research wallets test NTRU-based schemes specifically for the size tradeoffs on resource-constrained hardware wallets. Either way, the exposure question for existing blockchains has less to do with which lattice KEM wins this comparison and more to do with how much on-chain value still sits behind classical, quantum-vulnerable signatures today.
Adoption Cost and Infrastructure Overhead
Neither algorithm carries a license fee. Both ML-KEM and the NTRU family ship as open source through liboqs, PQClean, and vendor libraries, so the real cost of adopting either one shows up in engineering time, bandwidth, and long-term support risk rather than a purchase order.
| Cost factor | ML-KEM | NTRU / NTRU Prime |
|---|---|---|
| Software license cost | Free, open source (OpenSSL 3.2+, BoringSSL, liboqs) | Free, open source (liboqs, wolfSSL community edition) |
| Handshake bandwidth overhead (mid-tier) | ~1,184-byte public key, ~1,088-byte ciphertext (ML-KEM-768) | ~1,158-byte public key, ~1,039-byte ciphertext (sntrup761) |
| Constrained-device readiness | Demonstrated on Cortex-M class hardware in academic benchmarks | Comparable, with marginally smaller footprint at matched categories |
| Cloud KMS / managed TLS support, 2026 | Included in standard API pricing at AWS, Cloudflare; no PQC surcharge identified | Not offered as a managed KMS or CDN option |
| FIPS 140-3 compliance path | Yes, direct, via FIPS 203 | No path; permanently excluded from Round 3 standardization |
| Migration engineering cost | Lower; standardized target with existing IETF and OpenSSH codepoints | Higher for new deployments; safest use case is legacy interop only |
| Long-term vendor support risk | Low, backed by a federal standard | Moderate to high, dependent on individual vendors continuing investment |
The biggest hidden cost with NTRU isn’t compute, it’s building against an algorithm NIST has already told the industry it won’t standardize. Every hour spent wiring new infrastructure around NTRU today is time spent on a dead-end codepath for anything that needs future FIPS compliance or CDN and browser interoperability. That’s why most 2026 migration budgets point at ML-KEM first, and treat NTRU support as something to preserve for legacy SSH compatibility rather than something to build new around.
Migration Guide: Moving to ML-KEM
Whether you’re migrating off classical RSA/ECDH key exchange or off an NTRU-based hybrid you deployed early for interim post-quantum protection, the path to ML-KEM follows the same basic sequence.
- Inventory every place your infrastructure negotiates key exchange: TLS termination points, SSH bastion hosts, VPN gateways, and any custom protocol handling key establishment.
- Confirm library versions support ML-KEM. You need OpenSSL 3.2 or later, a current BoringSSL build, wolfSSL 5.7 or later, or liboqs for anything custom.
- Enable hybrid key exchange, not pure post-quantum. Pair ML-KEM with a classical algorithm like X25519 so a flaw in either half doesn’t compromise the connection on its own.
- Update SSH configuration to prefer the ML-KEM hybrid group over any NTRU-based or classical-only algorithm still listed.
- Test interoperability across every client your infrastructure actually serves, including older clients that may not support ML-KEM yet and will need a classical or NTRU-based fallback during the transition window.
- Monitor handshake latency and packet fragmentation. ML-KEM’s larger public keys and ciphertexts can push TLS or SSH handshakes past a single MTU, and QUIC deployments in particular need testing for this.
- For anything requiring FIPS 140-3 compliance, confirm your cryptographic module is validated specifically against FIPS 203, not just “post-quantum” in general.
On the SSH side specifically, moving from an NTRU-based hybrid to ML-KEM is a one-line configuration change on any server running OpenSSH 10.0 or later:
# /etc/ssh/sshd_config
# Before: NTRU Prime hybrid (still supported, no longer default)
KexAlgorithms [email protected]
# After: ML-KEM hybrid, OpenSSH 10.0+ default
KexAlgorithms mlkem768x25519-sha256,[email protected]Keeping the NTRU-based algorithm listed as a fallback during the transition avoids breaking connections from older clients while still preferring ML-KEM whenever both sides support it.
Common Migration Pitfalls to Avoid
The most common mistake is assuming NTRU has a standardization future it doesn’t. Teams sometimes build new infrastructure around sntrup761 because it was the first post-quantum option available to them, then discover a year later that browsers, CDNs, and compliance auditors only recognize ML-KEM. Treat any new NTRU deployment as a legacy-interop decision, not a forward-looking one.
The second is deploying pure post-quantum key exchange without a classical fallback. Every major production deployment of ML-KEM in 2026, from Cloudflare’s edge to Signal’s PQXDH, runs it in hybrid mode paired with X25519 or another elliptic-curve algorithm. Lattice cryptography is comparatively young, and hybrid mode means a flaw discovered in ML-KEM later wouldn’t strip a connection down to zero protection.
The third is ignoring MTU and fragmentation effects. ML-KEM’s public keys and ciphertexts are an order of magnitude larger than a classical elliptic-curve key, and protocols built assuming small handshake payloads, especially anything running over UDP like QUIC, can silently degrade or fail without explicit testing. The fourth is assuming any post-quantum label satisfies a compliance requirement. FIPS 140-3 validation specifically requires FIPS 203, 204, or 205 algorithms; an NTRU-based deployment, however well implemented, does not qualify.
Pros and Cons: ML-KEM vs NTRU
ML-KEM pros: NIST-standardized under FIPS 203 with a guaranteed long-term support path; broad ecosystem support across OpenSSL, BoringSSL, Chrome, Cloudflare, AWS, Signal, and Apple iMessage; the only option that satisfies FIPS 140-3 compliance; competitive or best-in-class performance across independent benchmarks.
ML-KEM cons: Larger public keys and ciphertexts than the closest NTRU equivalent at every security tier; being the sole standardized lattice KEM concentrates the internet’s post-quantum key exchange on one hard problem, Module-LWE, which is part of why NIST added the structurally different HQC as a backup.
NTRU pros: Smaller keys and ciphertexts at comparable security categories; one of the longest-studied lattice cryptosystems in existence, with a design lineage predating Kyber by two decades; no known implementation-breaking flaw after extensive cryptanalysis; useful as an algorithmic diversity hedge alongside ML-KEM.
NTRU cons: Permanently excluded from NIST standardization after NIST IR 8413; no FIPS 140-3 path; shrinking library and vendor support outside OpenSSH interoperability and wolfSSL’s commercial offerings; not recognized by browsers, CDNs, or cloud KMS providers.
Five Use Cases and Which Algorithm Fits
Web and TLS infrastructure teams: Use ML-KEM. It’s the only option Chrome, Cloudflare, and other CDNs negotiate, and it’s the target every major browser vendor’s post-quantum roadmap is built around.
SSH and ops teams hardening remote access: Prefer ML-KEM (mlkem768x25519-sha256) on OpenSSH 10.0 and later, but keep sntrup761x25519-sha512 listed as a fallback for older clients during the transition window rather than ripping it out immediately.
Regulated industries needing FIPS 140-3 compliance: ML-KEM is mandatory. NTRU cannot satisfy a FIPS 203 requirement regardless of implementation quality, so this decision isn’t really a choice.
Constrained IoT and embedded devices: Evaluate both. NTRU-HPS at Category 1 offers a marginally smaller memory footprint that can matter on tightly constrained microcontrollers, though ML-KEM-512 is close enough, and comes with NIST’s backing, that most new embedded designs in 2026 default to it anyway.
Messaging apps defending against harvest-now-decrypt-later attacks: ML-KEM, following the path Signal’s PQXDH and Apple’s PQ3 have already taken in production.
Security architects building crypto-agile systems: Consider running NTRU as a secondary, non-standard KEM alongside ML-KEM in especially sensitive systems, mirroring the diversity logic NIST applied when it standardized HQC as a code-based backup to ML-KEM’s lattice-based design.
The Verdict: Which Post-Quantum KEM Should You Use
For nearly every practical deployment in September 2026, ML-KEM is the right default. It’s the only algorithm with a FIPS 203 standardization behind it, the only one browsers and CDNs actually negotiate, the only one that satisfies compliance audits, and it holds its own or wins outright against NTRU on independent performance benchmarks. NTRU’s smaller key and ciphertext sizes are real, but they’re not large enough to justify building new infrastructure around an algorithm NIST has explicitly declined to standardize.
NTRU still earns its place in specific corners: legacy SSH interoperability through sntrup761, constrained embedded designs already committed to it, and as a genuine second opinion for teams worried about putting all of the internet’s post-quantum eggs in the Module-LWE basket. But if you’re starting a migration from scratch today, or deciding what to build into new infrastructure, ML-KEM is the algorithm to standardize on, and the Kyber ransomware incident is proof that adoption is already well past the theoretical stage.
Frequently Asked Questions
What is ML-KEM and how is it related to Kyber?
ML-KEM, Module-Lattice-Based Key-Encapsulation Mechanism, is the name NIST gave to the standardized version of CRYSTALS-Kyber when it finalized FIPS 203 on August 13, 2024. Kyber and ML-KEM refer to the same underlying algorithm; ML-KEM is simply the official standardized name.
What is NTRU and why wasn’t it standardized by NIST?
NTRU is a lattice-based key encapsulation family dating to 1996, one of the oldest post-quantum cryptosystems still in use. NIST evaluated NTRU and the related NTRU Prime scheme through Round 3 of its PQC standardization project, but chose to standardize only one structured-lattice KEM, Kyber, and formally removed NTRU Prime from further consideration in its 2022 status report, NIST IR 8413.
Is NTRU still safe to use in 2026?
Yes, based on current public cryptanalysis. No practical break of NTRU, NTRU Prime, or sntrup761 has been published as of September 2026. NIST’s decision not to standardize it was about consolidating around one algorithm, not about a security flaw.
Which is faster, ML-KEM or NTRU?
They’re close. Benchmarks from the liboqs and PQClean projects generally put ML-KEM at or near the front for keygen, encapsulation, and decapsulation speed, especially at the 512 and 768 tiers, but NTRU’s HPS and HRSS variants and sntrup761 remain competitive rather than clearly slower on modern x86-64 hardware.
Why does OpenSSH still offer sntrup761 if NIST didn’t standardize it?
OpenSSH added sntrup761x25519-sha512 years before ML-KEM support existed in mainstream libraries, when it was one of the only practical post-quantum options available. It remained the default for several releases and is still offered today as a fallback for older clients, even though mlkem768x25519-sha256 became the default in OpenSSH 10.0.
What is the Kyber ransomware group and does it mean ML-KEM is broken?
The Kyber ransomware group, documented by the Cloud Security Alliance in April 2026, is a criminal operation that built its Windows encryptor around a genuine implementation of ML-KEM-1024 to protect its symmetric keys. It’s the first known criminal use of a NIST-standardized post-quantum algorithm, but it doesn’t indicate any break in ML-KEM. The group adopted the algorithm the same way legitimate developers do, using a publicly available, standardized implementation.
Can I use NTRU for FIPS-compliant systems?
No. FIPS 140-3 validation for post-quantum key exchange requires FIPS 203 (ML-KEM). NTRU and NTRU Prime have no NIST standardization path and cannot satisfy that requirement, regardless of implementation quality.
Should I run both ML-KEM and NTRU for extra security?
For most organizations, no, the added complexity isn’t worth it outside specialized cases. Some security architects do treat NTRU as an algorithmic diversity hedge in especially sensitive systems, similar to how NIST itself added the code-based HQC as a backup standard alongside ML-KEM. For anything needing standard compliance or broad interoperability, ML-KEM alone, in hybrid mode with a classical algorithm like X25519, is the practical answer.
How much bigger are ML-KEM handshakes compared to classical RSA or ECDH?
Substantially bigger. A classical X25519 exchange needs only a 32-byte public key, while ML-KEM-768 needs 1,184 bytes for its public key and another 1,088 bytes for its ciphertext, roughly 35 to 70 times larger depending on which side of the exchange is measured. NTRU’s variants land in a similar range. That overhead is manageable for most TLS and SSH traffic but can matter for latency-sensitive or bandwidth-constrained links, which is one reason hybrid deployments test handshake size carefully before rolling out broadly.
Does switching to ML-KEM protect data that was already encrypted with RSA or ECDH?
No. Migrating to ML-KEM protects future traffic, not ciphertext already recorded under classical key exchange. Anyone who captured RSA- or ECDH-protected traffic before a migration can still attempt to decrypt it later if a capable quantum computer eventually exists. That’s the entire premise behind the harvest-now-decrypt-later threat model driving the urgency of post-quantum migration in 2026.
