In a preprint submitted on August 13, 2026, and posted two days later, researcher Bhabani Sankar Das described how he had recovered most of an ML-KEM private key from shipped builds of wolfSSL, a cryptography library aimed at embedded and real-time systems. He exploited two flaws in the library’s optimized code, already patched by wolfSSL, with ordinary computers and no quantum computer. ML-KEM, formerly CRYSTALS-Kyber, is the post-quantum key-encapsulation mechanism (KEM) that the U.S. National Institute of Standards and Technology (NIST) standardized in 2024. A KEM is a method two parties use to agree on a shared secret over an open network.
The flaws Das exploited were among several published in new post-quantum code since 2024. For long-term signing and decryption keys, where such flaws do the most damage, pairing each post-quantum algorithm with a classical one limits what the flaws can expose, at the cost of a few percent more data, more code to maintain, and a second migration later.
In a hybrid deployment, the two algorithms run side by side. For key exchange, their secrets are combined so that an attacker must break both, and for signatures, a verifier checks both. The U.S. National Security Agency (NSA) cites the same evidence of implementation failures to argue that hybrids can weaken security, though it accepts them in specific cases.
Disclosure: Quantum Observer’s Editor-in-Chief Marin Ivezic is the founder and CEO of Applied Quantum, a quantum systems integration and consulting firm, and the author of its PQC Migration Framework.
Flaws published so far
Each of the following flaws was in released code before researchers reported it.
| Published | Code | Flaw | Demonstrated effect | Source |
|---|---|---|---|---|
| 2024 | Kyber (ML-KEM) reference code and several libraries | Division timing that depends on secret data | Secret keys recovered within minutes or within hours on a Raspberry Pi 2 and a Cortex-M4 chip | Bernstein et al. |
| February–June 2026 | libcrux and hpke-rs | 13 vulnerabilities documented, 11 of them novel by the author’s count, and 4 in formally verified specification and proof code | Decryption failures in Signal’s post-quantum ratchet from a platform-dependent bug, and nonce reuse from an integer overflow | Kobeissi |
| May 2026 | wolfSSL ML-DSA, memory-optimized build | Omitted modular reductions | Arithmetic overflow and signing failures that existing known-answer tests missed, with no key leak shown | Lee, Lim, and Yoon |
| June–August 2026 | wolfSSL ML-KEM, AVX2 and NEON assembly | Ciphertext check compared only part of each ciphertext | 98.0% to 98.5% of a reused ML-KEM-1024 key’s secret coefficients recovered | Das |
Several of the flaws were in code written for speed or memory, such as wolfSSL’s hand-written assembly for x86 and Arm processors and its memory-optimized build of ML-DSA, formerly CRYSTALS-Dilithium and now NIST’s main post-quantum signature standard. Nadim Kobeissi of Symbolic Software documented 13 vulnerabilities in the libcrux and hpke-rs libraries and wrote that 11 of them were novel. Four were in formally verified specification and proof code, among them “a wrong decompression constant” in ML-KEM.
Daniel J. Bernstein of the University of Illinois Chicago and Academia Sinica examined another class of bug in a paper dated June 1 and self-published on his website. He described bugs in ML-DSA signing code that conventional functionality tests cannot catch. He wrote that “a small change in ML-DSA software creates an ML-DSA version of the Dilithium 1.0 software vulnerability,” a flaw reported in 2018 in the official code for the scheme’s 2017 submission to NIST.
Bernstein introduced such bugs himself for his demonstrations and named no shipped ML-DSA library that contains one. With them, he recovered a signing key’s secret components from two signatures in under a second on one laptop core.
To estimate how many bugs to expect, Bernstein took vulnerability rates of 0.450 and 1.187 per 1,000 lines of code, published for the Network Security Services and OpenSSL libraries. He applied them to the 100,000 to 200,000 lines he expects about 50 ML-DSA libraries to add over five years. He arrived at about 100 vulnerabilities, two per library on average, and gave each library “about a 1/4 chance of a severe vulnerability.”
Attackers can exploit flaws like these with the computers they already have. In a study that Germany’s Federal Office for Information Security (BSI) published in 2025, the authors judged it realistic that a cryptographically relevant quantum computer, one able to break today’s public-key cryptography, would exist in about 15 years. They wrote that the period could shorten to about 10 years. Adversaries can still record encrypted traffic now and decrypt it once such a machine exists, an approach known as harvest now, decrypt later.
What a hybrid contains
The Internet Engineering Task Force (IETF) published a hybrid key-agreement standard in August for version 1.3 of Transport Layer Security (TLS), the protocol that encrypts web connections, as Quantum Observer reported in its article on RFC 10024. In that standard, Request for Comments (RFC) 10024, the authors combine the outputs of an elliptic-curve exchange and ML-KEM “to provide security as long as at least one of the component algorithms remains secure, even if the others are compromised.” The most widely deployed pairing uses X25519, an elliptic-curve key exchange.
Against an attack like Das’s, a hybrid recipient loses only its post-quantum half. An attacker who recovers its ML-KEM key still has to break its elliptic-curve key, for which no practical attack has been publicly demonstrated, provided the code that combines the two keys is sound. A hybrid does not give lasting confidentiality if its post-quantum half is broken today, because an attacker who records the traffic can recover the elliptic-curve half once a quantum computer exists.
The BSI has already relied on that property for Classic McEliece, a code-based post-quantum scheme. Since its technical guideline TR-02102 first listed the scheme, the agency has recommended using it only in combination with a classical key-agreement scheme. In 2026, three research groups estimated that key recovery costs less than the scheme’s claimed security. The BSI then advised against new uses and said such hybrids still offer at least the security of their classical half, as Quantum Observer reported in its article on the BSI’s Classic McEliece advisory.
Bernstein modeled how much of the software risk a hybrid removes, using assumed rates of bugs and patching, not measured failures. For 2027, he estimated that about 18% of ML-DSA keys would be breakable through unpatched severe bugs. He put the share at about 4.1% for keys that pair ML-DSA with Ed25519, a widely deployed elliptic-curve signature scheme, and at about 1.6% for Ed25519 keys used alone.
On his 2027 figures, fewer than a quarter as many hybrid keys as ML-DSA-only keys would be exposed. He concluded that replacing the hybrid with ML-DSA alone within the next five years “would damage security.”
A hybrid does not contain every flaw, since an attacker who finds a memory-safety bug in either half, or in code the two halves share, can expose both keys at once. Sophie Schmieg, a cryptography engineer at Google, wrote on the IETF’s TLS mailing list in April that a hybrid implementation’s exposure to such issues “is the union of the risk surfaces” of its components.
Bernstein built that risk into his model by assuming that one in five severe bugs in either half, such as a buffer overflow, breaks the whole hybrid. Because of that assumption, his hybrid estimate is higher than the one for Ed25519 alone. In his model, he wrote, “using Ed25519+ML-DSA rather than Ed25519 within the next 5 years would damage security.” He added that the comparison could reverse if the share were one in 20.
He also assumed no break in ML-DSA’s mathematics, one severe bug in eight, a 20% chance each year that a vulnerable library is patched, and a pool of about a billion active keys.
Code for the classical half can have flaws of its own. The vulnerabilities Kobeissi documented included a missing X25519 validation that the specification makes mandatory.
For signatures, IETF authors describe a way around the pairing in RFC 9955, published in July 2026. In what they call a stripping attack, an adversary takes a message and its hybrid signature and submits them to a verifier for just one of the component algorithms. The message’s security then depends on that algorithm alone.
What it costs
For TLS key exchange, the classical half is small. X25519 accounts for 32 of the 1,216 bytes in the X25519MLKEM768 key share a client sends, and ML-KEM-768 for the other 1,184, according to RFC 10024. The server’s share is 1,120 bytes, 32 of them for X25519.
When Google turned on hybrid key exchange with Kyber, the draft version of ML-KEM, its Chrome engineers measured a “4% median latency increase to all TLS handshakes in Chrome on desktop,” they wrote in May 2024. The extra data split the TLS ClientHello message into two packets and exposed bugs in several middlebox products. Operators who drop X25519 save 32 bytes of each share but keep the kilobyte of ML-KEM data that caused those effects.
For signatures, Ed25519 adds 64 bytes to a 2,420-byte ML-DSA-44 signature and 32 bytes to its 1,312-byte public key, according to FIPS 204 and RFC 8032. That is about 2.6% more signature and 2.4% more key.
The UK’s National Cyber Security Centre (NCSC) counted the engineering costs in 2024. It wrote that hybrid schemes “will be more complex to implement and maintain and will also be less efficient,” and that organizations adopting one face “the need to complete the migration twice,” first to the hybrid and later to post-quantum algorithms alone. In an October 2026 update to its TLS guidance, the NCSC recommended “both hybrid post-quantum/traditional and pure post-quantum cipher choices.”
For U.S. federal systems, a hybrid must also fit FIPS 140, NIST’s standard for validating cryptographic modules. RFC 10024’s authors wrote that a FIPS-approved deployment of X25519MLKEM768 needs a certified ML-KEM implementation. In July 2025, NIST said it did not propose to approve X25519.
In a notice of December 31, 2025, NIST said it would revise its key-establishment recommendations, SP 800-56A and SP 800-56C, to approve x-coordinate-only implementations of certain elliptic-curve key-agreement schemes and to allow more flexibility in formatting hybrid shared secrets. NIST did not name X25519 in that notice.
In its final transition plan of October 27, NIST kept hybrid key establishment allowed even after one input’s algorithm becomes disallowed, as Quantum Observer reported in its article on the final transition plan. For RSA and elliptic curves, that happens after 2035, and under NIST’s rules an operator need not remove a hybrid key exchange at that date.
For hybrid signatures, NIST said its standards accommodate them when at least one component is approved but cautioned that their security properties need careful analysis. NIST specified no way to bind the two signatures.
Apple has accepted the signature costs for S/MIME, the standard for signed and encrypted email. Its root program, which decides which root certificates Apple’s operating systems trust, announced in September that it will accept S/MIME roots that combine ML-DSA with ECDSA or RSA. Apple wrote that the classical component “keeps the system verifiable using an algorithm with decades of deployment experience.”
The case against hybrids
The NSA argues against hybrids from the premise that implementation errors cause more failures than broken algorithms. “Because more security products fail due to implementation or configuration errors than failures in their underlying cryptographic algorithms, spending limited resources to add cryptographic complexity can weaken security rather than improve it,” the agency wrote. It made the statement in the October 2026 version of its answers on the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), the algorithms it requires for U.S. national security systems (NSS).
The agency wrote that it “has confidence in CNSA 2.0 algorithms and will not require NSS developers to use hybrid certified products for security purposes.” It added that product availability and interoperability requirements “may lead to adopting hybrid solutions in specific cases.” The agency also wrote that “hybrid deployments add a second transition later.” For some formal security properties, it wrote, hybrids “may be no stronger, or possibly even weaker, than their individual components,” a question it described as “a matter of significant debate in industry and academia.”
Cryptography engineer Filippo Valsorda made a narrower case against hybrid signatures on April 6. His starting point was Google’s 2029 deadline, the most aggressive timeline anyone had set. “We don’t have the time if we need to be finished by 2029 instead of 2035,” he wrote.
He called hybrid key exchange “reasonably easy” but wrote that hybrid signatures “cost time and complexity budget.” In his view, their only benefit is protection if ML-DSA falls to a classical attack before quantum computers arrive, which he called “the wrong tradeoff at this point.” He argued that “we should go straight to pure ML-DSA-44.”
In a footnote, he wrote that “ML-KEM and ML-DSA are a lot easier to implement securely than their classical alternatives.” He added that, with better testing infrastructure, he expected to see “exceedingly few bugs in their implementations.” He linked that infrastructure to Wycheproof, a public collection of cryptographic test vectors.
Schmieg argued that “in many cases, signature keys can be revoked with varying amounts of pain,” so revoking affected keys can contain a published flaw. She wrote that the extra protection of hybrid signatures applies to attacks that are still unpublished. “I much prefer having pure ML-DSA over not having any PQC signature at all,” she wrote.
She still recommended hybrids when they “can be done without additional cost,” but “with a heavy bias towards just using pure signatures in case of difficulties arising.” For firmware signing keys, where “revocation is not really possible,” she preferred “having SLH-DSA, or as a fallback, hybrid signatures.” SLH-DSA, formerly SPHINCS+, is NIST’s hash-based signature standard.
For key exchange, the IETF has approved an option without the classical half. In revision 11 of the draft for ML-KEM used alone in TLS, posted September 17, its author, Deirdre Connolly, wrote that implementers “must evaluate their specific security, performance, and operational constraints when deciding whether to deploy standalone ML-KEM or a hybrid construction.” Connolly also co-wrote RFC 9955 on hybrid signatures.
The IETF’s steering group approved the draft on September 3. After a hold from September 24 to October 5 over complaints and appeals about its processing, the draft had no RFC number as of November 12, as Quantum Observer reported in its article on the draft’s Last Call.
Agencies and standards bodies split on hybrids, with the NSA at one end and Germany’s BSI and France’s cybersecurity agency, ANSSI, at the other.
| Body | Position on hybrids | Source |
|---|---|---|
| NSA (U.S. national security systems) | Not required for security, though product availability and interoperability may lead to hybrids in specific cases, as in its IKEv2 profile | CNSA 2.0 FAQ v2.2, October 2026 |
| Office of Management and Budget (U.S. federal agencies) | Each agency’s choice after weighing trade-offs, described as “an intricate and resource-intensive stopgap” | M-26-15, Appendix A, June 2026 |
| NIST (U.S.) | Hybrid key establishment can be FIPS-validated with one approved input, and hybrid signatures need careful analysis | IR 8547, October 2026 |
| NCSC (UK) | Both hybrid and pure post-quantum options recommended for TLS, with hybrids the most widely deployed in common libraries | TLS guidance update, October 2026 |
| BSI (Germany) | Post-quantum key agreement recommended in combination with a classical scheme | Classic McEliece notice, October 2026 |
| ANSSI (France) | Hybrid key exchange in TLS 1.3 is “la solution privilégiée par l’ANSSI,” the agency’s preferred option | ANSSI-FT-11, February 2026 |
| IETF TLS working group | Hybrid X25519MLKEM768 on the standards track and recommended, and ML-KEM alone approved as Informational with its groups marked not evaluated | RFC 10024, draft-ietf-tls-mlkem |
Weighing the objections
The researchers who published flaws in ML-KEM and ML-DSA code in 2026 all found them in implementations, consistent with the NSA’s premise. Bernstein counted the one-in-five share of bugs that break both halves and still found the hybrid safer than ML-DSA alone.
The NSA’s position also fits its setting, U.S. national security systems, where the agency chooses the algorithms. The NSA still accepts a hybrid where a protocol requires one. For IKEv2, the protocol that sets up many VPN tunnels, the agency will keep CNSA 1.0 key establishment “fortified by key establishment using ML-KEM-1024” in its profile.
In his footnote, Valsorda predicted “exceedingly few bugs” in ML-KEM and ML-DSA implementations. In a June 2 message to the IETF’s TLS mailing list, he wrote that Bernstein’s paper identified one real bug, in a 2017 implementation, and that known-answer tests would catch the three variants the paper constructed. Researchers found the 2026 flaws in hand-written assembly, a memory-optimized build, and verified specification code, the engineering that developers add to an algorithm in every production library. Wycheproof’s maintainers merged test cases for the kind of incomplete ciphertext comparison behind wolfSSL’s ML-KEM flaw only on September 2, after wolfSSL had fixed it.
Bernstein built a short timeline into his model. He assumed that a large-scale attacker could build “a secret billion-dollar quantum computer by 2029,” the year Google set as its deadline. In his model, the hybrid stays ahead of ML-DSA alone until the comparison flips “a decade after the first quantum computer,” around 2039 on that assumption. Valsorda’s argument about time is strongest where building hybrid support would delay any post-quantum signature, the case in which Schmieg also favors pure signatures.
By Schmieg’s own account, hybrids protect keys in the window before a flaw is published, when revocation cannot help. For wolfSSL users who turned on its post-quantum code early, that window lasted more than two years.
The AVX2 flaw in ML-KEM-1024 affected every wolfSSL release from 5.7.0, dated March 20, 2024, to 5.9.1, according to the company’s CVE record. In 5.7.0, the company shipped the code, then a pre-standard version of ML-KEM, as “Experimental wolfSSL Kyber,” enabled only through build options. It fixed the flaw in June 2026, as Quantum Observer reported in its article on the wolfSSL key recovery. The company credited Nicholas Carlini of Anthropic with reporting the second flaw Das used, in its code for Arm’s NEON instructions.
For decryption keys, revoking a key after the fix does not protect traffic an attacker recorded before it.
Where hybrids matter most
For TLS key exchange, the question is settled in practice. Chrome, desktop Firefox from version 132, and Apple’s iOS 26 and macOS 26 offer X25519MLKEM768 by default, and Google says its API endpoints use ML-KEM “in hybrid mode.” Those connections use a fresh key for each handshake. Das wrote that such keys are not open to his key-recovery method.
A flaw does the most harm in keys used for years. They include certificate and code-signing keys under ML-DSA, and ML-KEM keys that a recipient reuses, as in HPKE, a standard for encrypting to a recipient’s long-term public key. An attacker who recovers a signing key can forge signatures until relying parties stop accepting it. An attacker who recovers a decryption key can read every message encrypted to it, including stored ones, and revoking the key protects only later messages.
Practitioners disagree most about hybrids for those keys, mainly over whether hybrid signatures are worth their cost in time and complexity. Organizations can act without waiting for standards bodies to agree. They can keep the hybrid key exchange that their browsers and cloud providers already use. For long-term signing and decryption keys, they can choose hybrid or composite constructions where their protocols bind the two parts, as Apple plans for S/MIME roots.
They can also ask library suppliers for tests beyond interoperability. Wycheproof’s ML-KEM test cases flip single bytes at structural boundaries of a ciphertext to catch code that checks only part of it. Bernstein recommended derandomized known-answer tests for ML-DSA signing. Those tests compare each signature with an expected value and can catch signing bugs that verification tests miss.
What would change this assessment
Time is the main variable in Bernstein’s model. If post-quantum libraries go several years without severe flaws, operators will have less reason to keep the classical half. Of his assumption that one bug in eight is severe, Bernstein wrote, “It will be interesting in 5 years to compare the 1/8 model to the data accumulated by then.”
An early quantum computer would also narrow the hybrid’s advantage. Against a quantum attacker, the NCSC wrote in 2024, a hybrid “will provide no more security than a single post-quantum algorithm.” The classical half would still guard against classical attackers who exploit a flaw in the post-quantum half.
If deployed hybrid or composite signatures start failing through stripping or combiner bugs more often than ML-DSA alone fails through implementation bugs, the NSA’s reading of the shared premise will have proved right. No such pattern had appeared in the research that Quantum Observer reviewed through November 12, 2026.
