Post-Quantum Saturday — August 08 2026 Weekly Update

TL;DR — This Week

1. The Pure ML-KEM for TLS fight reaches its climax. On July 30, the IESG issued an IETF-wide Last Call for draft-ietf-tls-mlkem-09, the specification defining standalone (non-hybrid) ML-KEM key establishment for TLS 1.3. Comments close August 13. This is the most contentious PQC standardization decision in IETF history: three Working Group Last Calls, a contested rough-consensus determination (chairs found "roughly 7/10" support among experts but refused to release the underlying numbers), appeals to both the IESG and IAB at every stage, and a European Commission official formally requesting the vote tally. The code points are marked Recommended=N in an Informational RFC — while the hybrid X25519MLKEM768 remains on the standards track at Recommended=Y. The practical message: the IETF is documenting what it declines to endorse. Read the registry, not the RFC number.

2. RFC 9980 brings post-quantum cryptography to OpenPGP (June 30, 2026). The IETF published "Post-Quantum Cryptography in OpenPGP" as a Proposed Standard. It mandates composite ML-DSA-65 + Ed25519 for signatures and ML-KEM for encryption — notably, hybrid-only, the opposite of what TLS is getting. The catch: GnuPG (the engine behind most of the world's package verification) has no PQ signature support and is on a divergent LibrePGP track. The standard exists; the implementation gap is enormous.

3. The lattice cryptanalysis debate intensifies. Three developments reshape the risk picture: (a) Bernstein's 59-page "Exploiting ML-DSA bugs" paper (June 2026) demonstrates key recovery in under one second from software bugs that pass all standard tests; (b) the Ogilvie "Concrete Hardness Gap between MLWE and LWE" paper (ePrint 2026/279) proves the assumed equivalence between Module-LWE and plain LWE does not hold, saving the attacker bits; (c) the Luo preprint claiming to break ML-KEM with ~1,400 qubits was shown to have fatal flaws (the attack target is provably independent of the secret key), but the episode reinforced that plausible-looking attacks on lattice structure can appear. Together, these make the case for hybrid ECC+PQ deployment quantitatively, not just rhetorically.

4. Kobeissi's "Verification Theatre" exposes gaps in formally verified PQC code. Nadim Kobeissi's paper (ePrint 2026/192, February 2026) found 13 vulnerabilities in Cryspen's libcrux — the library used by Firefox and OpenSSH that advertises formal verification. Four bugs were inside the formal verification boundary itself, including a wrong multiplication specification in ML-DSA that rendered AVX2 proofs unsound. If "formally verified" PQC code ships with exploitable bugs, the unverified majority will fare worse.

5. Forescout data: 90% of SSH servers still not quantum-safe. New measurement data (July 2026) shows the PQC adoption gap in stark numbers. While 50% of IT devices have PQC-capable OpenSSH, adoption drops to 28% for IoT, 16% for OT, and 6% for IoMT. Two-thirds of OT devices in enterprise networks are both high-risk and not PQC-capable on TLS. The migration is happening, but unevenly.

6. MAS Singapore targets quantum resilience by end of decade. The Monetary Authority of Singapore (July 28, 2026) announced it will issue formal supervisory expectations later in 2026, aiming for quantum resilience across the financial sector before 2030. This aligns with the global regulatory consensus (US EO 14412, EU roadmap, ANSSI, BSI, NCSC).

7. Crypto 2026 (August 17–20) and AM-PQC 2026 (August 10–14) are imminent. These are the venues where the next wave of lattice cryptanalysis results will surface. Expect papers that could tighten or loosen security estimates for ML-KEM and ML-DSA parameters.

Freedom-tech implication: the pure-vs-hybrid ML-KEM debate is the single most important standards decision for anyone building decentralized privacy infrastructure. If you operate Nostr relays, mesh networks, or any system relying on TLS, the IETF is about to bless a standalone PQ option that drops the classical safety net. The recommendation remains unchanged: deploy hybrid X25519MLKEM768 everywhere, treat pure ML-KEM as a compliance profile for CNSA 2.0-style regimes, and build crypto-agility so you can flip modes per environment.

The Week in Detail

1. The Pure ML-KEM for TLS Last Call — A Standards Saga

This is the most consequential IETF PQC decision since the NIST standards were finalized, and it deserves full context.

What the draft does

draft-ietf-tls-mlkem defines ML-KEM-512, ML-KEM-768, and ML-KEM-1024 as NamedGroup values for TLS 1.3 key establishment — without combining them with a classical algorithm. This is "pure" or "standalone" ML-KEM: the confidentiality of the TLS session rests entirely on the lattice scheme, with no ECC fallback.

The hybrid counterpart, draft-ietf-tls-ecdhe-mlkem (currently at version -05, May 2026), defines X25519MLKEM768 — the code point already deployed by Chrome, Cloudflare, AWS, and Apple. It is on the standards track with Recommended=Y in the IANA TLS Supported Groups registry.

The dispute in three acts

The pure ML-KEM draft has been fought over at every stage:

Who opposed and why

The sustained opposition came from cryptographers who argue that shipping a standalone PQ option in the internet's default encryption protocol is a bet nobody was forced to make:

• Daniel J. Bernstein (UIC / Academia Sinica): Has fought the document since adoption. His argument: a solo PQ handshake fails completely if ML-KEM has an undiscovered weakness, while a hybrid remains secure as long as either component holds. His blog series ("NSA and IETF," parts 1–8) and his "Understanding lattice risks" post (June 30, 2026) provide the technical foundation. He has called for volunteers to oppose.
• Tanja Lange (TU Eindhoven): Wrote on July 6 that none of her concerns had been addressed and she does not support publication. Anticipated the exact failure mode: readers will treat an RFC as IETF endorsement regardless of the Recommended=N marking.
• Nadim Kobeissi (Symbolic Software): Blocking objection centered on compositional security. His updated ProVerif model of TLS 1.3 supports results showing hybrid groups stay secure even when one component is compromised — the property pure deployment gives up.

Not every earlier critic stayed opposed: Muhammad Usama Sardar, who pressed for formal-analysis reports in previous rounds, wrote that draft -08 resolved his technical objections.

The counting controversy

Hours after the July 19 determination, Fabiana Da Pieve, Team Leader for Post-Quantum Cryptography at the European Commission's DG CNECT, asked the chairs on the record for the numbers behind the call and the method used to weigh responses. Chair Joseph Salowey replied on July 20: the mail is public, no specific threshold defines rough consensus, and the chairs "do not intend to release any further detailed analysis" of numbers, weights, or methods.

This is significant. The chairs introduced the "7/10" fraction themselves — once you publish a number, you own the question of how it was produced. Declaring roughly seven in ten among a chair-selected cohort, then telling a European Commission official that nothing further will be released, is Exhibit A for any future appeal.

The demand side

Three standards bodies filed liaison statements supporting publication: - 3GPP: Asked for stable references for its post-quantum work - IEEE 802.11: Supporting publication - O-RAN: Supporting publication

The chairs cited all three as evidence that downstream standards bodies need a stable normative reference — the draft will be cited by procurement regimes (especially CNSA 2.0) that prescribe standalone ML-KEM.

What happens after August 13

After the comment window closes, the IESG decides whether to publish. Objectors may appeal. The intended status is Informational RFC — not Standards Track. The code points are already in the IANA registry with Recommended=N. The key distinction:

Read the pair together: the IETF is documenting what it declines to endorse. Procurement officers tend to read "RFC" and stop. Auditors and architects should read the registry instead.

Freedom-tech relevance

For decentralized systems using TLS (Nostr over wss, ENS-connected services, mesh network gateways): the recommendation is unchanged. Deploy hybrid X25519MLKEM768. Treat pure ML-KEM as a compliance profile for CNSA 2.0-style regimes that prescribe it, once the RFC ships. Build crypto-agility to flip modes per deployment environment. The harvest-now-decrypt-later threat means the consequences of betting on pure ML-KEM are retroactive: a break that recovers shared secrets from recorded handshakes would expose every pure-ML-KEM session captured since deployment.

Sources: IETF TLS mailing list archives (mailarchive.ietf.org/arch/msg/tls/); IETF Datatracker (datatracker.ietf.org/doc/draft-ietf-tls-mlkem/); PostQuantum.com analysis (Ivezic, July 30, 2026); Bernstein blog (blog.cr.yp.to/20260630-risk.html); freenode.net analysis; LWN.net.

2. RFC 9980 — Post-Quantum Cryptography in OpenPGP

On June 30, 2026, the IETF published RFC 9980 ("Post-Quantum Cryptography in OpenPGP") as a Proposed Standard, extending RFC 9580 (the 2024 OpenPGP revision). This is the post-quantum extension the OpenPGP WG has been building since mid-2022.

What it specifies

Notably: OpenPGP went hybrid-only. The mandatory signature algorithm is a composite construction combining ML-DSA-65 with Ed25519 — the system is only broken if both components fail. This is the opposite of what TLS is getting with the pure ML-KEM draft. The OpenPGP WG made the deliberate choice that no standalone PQ option would be defined.

The RFC was a joint effort by MTG AG, the German Federal Office for Information Security (BSI), and Proton AG. The first version was published as an Internet Draft in December 2022.

The GnuPG problem

The new signature algorithms require v6 keys with no v4 carve-out. GnuPG — the engine inside most of the world's package verification, Debian/Ubuntu apt, RPM, and Git commit signing — currently has no post-quantum signature support at all. Werner Koch (GnuPG maintainer) has been open about the ordering: encryption first, signatures later.

GnuPG has diverged onto a separate LibrePGP track, which has its own ML-KEM key and signature formats based on SHA-3 — incompatible with RFC 9980's v6 key structure. This means the OpenPGP ecosystem is split:

For freedom-tech: OpenPGP is the backbone of decentralized trust for software distribution, encrypted email, and key verification. The standard now has PQ support, but the implementation gap means practical quantum-safe email and package signing remain years away for most users. The GnuPG/LibrePGP split is the single biggest obstacle.

Sources: RFC 9980 (rfc-editor.org/rfc/rfc9980); IETF Datatracker; MTG AG announcement (July 29, 2026); PostQuantum.com analysis; OpenPGP.org standard page; GnuPG mailing list archives.

3. Bernstein's "Exploiting ML-DSA bugs" — The Quantitative Case for Hybrid

Daniel J. Bernstein's 59-page paper (June 1, 2026, cr.yp.to/papers.html#mldsa) provides the strongest evidence yet that deploying solo ML-DSA without retaining ECC as a safety layer creates measurable, quantifiable risk.

The attacks

Two open-source attack demonstrations, each targeting a different class of ML-DSA software bug:

Attack 1 — The "AABBCC" bug: Coefficients in the secret polynomial end up repeating in pairs. This is an ML-DSA-specific version of a vulnerability announced in 2018 by Dilithium co-designer Vadim Lyubashevsky, who said it "can easily be exploited to recover the secret key." Lyubashevsky never published a working demo. Bernstein does. The attack inspects a public key and two signatures, solves a system of linear equations over the polynomial ring, and recovers the four secret polynomials needed to forge signatures on arbitrary messages. Ran successfully on 50 consecutive randomly generated keys. Completes in under one second on a single laptop core.

Attack 2 — Nonce repetition: The ML-DSA analog of the Sony PlayStation 3 ECDSA disaster (2010). If ML-DSA signature software accidentally reuses the secret nonce, the attacker recovers the secret key by simple polynomial division. Works ~80% of the time from two signatures.

Both attacks produce universal forgeries — the attacker can sign any message under the victim's public key.

Why these bugs pass all tests

The critical insight: these bugs are invisible to standard testing. An ML-DSA signature generated with the AABBCC bug is a valid ML-DSA signature. It interoperates with correct verifiers. It passes known-answer tests if those tests were generated by code with the same bug (which is exactly what happened with both official Dilithium 1.0 implementations in 2017). The only tests that reliably catch these bugs are cross-implementation checksum comparisons using derandomized RNGs — and Bernstein documents how inconsistently such tests are applied.

The Wycheproof test suite, cited by some as evidence of "better testing infrastructure," does not include ML-DSA key-generation tests and uses a nonstandard interface for signature-generation tests that many implementations will skip.

The quantitative model

Bernstein builds a statistical model from published CVE data:

• Blessing, Specter, Weitzner (2021): 0.45–1.19 CVEs per 1,000 lines of code added across 8 major crypto libraries; average exploitable lifetime 5.13 years.
• ML-DSA ecosystem: ~50 libraries, each with 2,000–4,000 lines of ML-DSA-specific code → 100,000–200,000 lines aggregate.
• Prediction: ~100 new vulnerabilities ecosystem-wide (~2 per library). If 1/8 are severe: ~25% of ML-DSA libraries ship with at least one severe vulnerability at initial release.
• Ed25519 comparison: 1–2 severe vulnerabilities across ~100 libraries over 10+ years → ~2% severe-vulnerability rate.
• 2027 estimate: Ed25519 keys face ~2% probability of running on vulnerable software; ML-DSA keys face ~18%.
• Bottom line: Solo ML-DSA produces roughly an order of magnitude more breakable keys than hybrid Ed25519+ML-DSA for at least the next five years.

What it challenges

The paper directly challenges two positions staked out in April 2026: - Filippo Valsorda argued hybrid ECC+ML-DSA signatures are unnecessary and would slow PQC deployment. - Sophie Schmieg (Google) argued hybrid signatures are less necessary than hybrid key exchange because signature forgery damage is bounded by key revocation.

Bernstein dismantles both. The code required for Ed25519+ML-DSA is almost entirely the same code required for solo ML-DSA. Adding Ed25519 to an ML-DSA-44 signature increases size by 64 bytes (2,420 → 2,484 bytes = 2.6%). DigiNotar compromised hundreds of thousands of users before revocation — revocation bounds the visibility of forgery, not the consequence.

Sources: Bernstein, "Exploiting ML-DSA bugs" (cr.yp.to/papers.html#mldsa, June 2026); PostQuantum.com analysis (Ivezic, June 4, 2026); PQC Migration Brief (Ivezic, June 6, 2026); Blessing, Specter, Weitzner, arXiv:2107.04940.

4. Lattice Cryptanalysis — The Risk Landscape

Three papers reshape the security assessment of lattice-based PQC:

(a) Ogilvie — "Concrete Hardness Gap Between MLWE and LWE" (ePrint 2026/279)

Published February 2026, this paper demonstrates that the widely assumed equivalence between Learning With Errors (LWE) and Module-LWE (MLWE) in power-of-two cyclotomics does not hold at concrete parameters. The gap saves the attacker up to 15 bits compared to generic lattice attacks by exploiting the module structure of ML-KEM.

This directly refutes claims like "there is no known cryptanalysis currently exploiting rank ≥2 module structure at these parameters that performs better than generic lattice reduction." As Bernstein noted in his June 30 blog post: "Oops." The module structure that was supposed to be a feature (enabling efficient arithmetic) is also an attack surface.

(b) Luo — "Module Lattice Security" (arXiv, May 2026)

A four-part preprint series by Ming-Xing Luo (Southwest Jiaotong University) claimed to break ML-KEM, Falcon, Hawk, and NTRU at all standardized parameter sets using ~1,400 logical qubits and ~10⁸ gates via an extension of the CDPR quantum attack. If correct, this would be the most consequential PQC result since Shor's algorithm.

Status: fatally flawed, not peer-reviewed. By May 25, 2026, two experts independently confirmed fatal problems:

• Daniel Apon (Anduril, former NIST cryptographer): The attack target is independent of the secret key. The determinant ideal being attacked is identical for any two ML-KEM instances sharing the same public matrix, regardless of the secret. Whatever the attack extracts has nothing to do with what it's trying to recover.
• Thomas Espitau (co-author of the EUROCRYPT 2025 Hawk paper Luo cites): The reduction is dimensionally wrong — the algorithm outputs a single ring element, but Module-SVP requires a short vector in a rank-d module. He also confirmed the Hawk section fabricates a result from his own paper.

The resource estimate is also internally inconsistent: the algorithm's own precision formula requires ~2.9 million qubits at the top tower level, three orders of magnitude more than the headline ~1,400 figure.

Assessment: Not a real break. But the episode reinforces that plausible-looking attacks on lattice algebraic structure can appear, and that the cryptographic community's response time matters. The correct response: read the paper, check the math, wait for community verification, and don't change migration plans based on preprints.

(c) Bernstein — "Understanding lattice risks" (blog, June 30, 2026)

Bernstein's blog post dismantles a specific paragraph used to justify solo ML-KEM over hybrid. The paragraph claimed Module-LWE has a "worst-case-to-average-case reduction — something neither RSA nor ECDLP had," implying proactive protection. Bernstein shows:

1. "Known" is a risk-management error — it asks us to react to known failures rather than proactively protect against unknown ones.
2. "Cryptanalysis" excludes timing attacks (KyberSlash 1/2, Clangover — the majority of ML-KEM libraries have issued KyberSlash patches) and implementation bugs.
3. The worst-case-to-average-case reduction is not a protective feature — historically, reductions have been used to build attacks (e.g., square-root discrete-log via worst-case-to-average-case reduction).
4. Module-LWE is harder than ideal-LWE (Langlois-Stehlé 2015), which is why it was chosen. But the Ogilvie paper shows the gap is smaller than assumed.

Freedom-tech implication: The lattice security story is not "proven secure." It is "no known attack currently works at scale, but the mathematical structure is rich and still being explored, and the software is new and buggy." This is exactly why hybrid (ECC+PQ) is the right default. The cost is negligible; the insurance is against both mathematical breaks and software bugs.

Sources: Ogilvie, ePrint 2026/279; Luo, arXiv:2605.17412 (and parts I–III); PostQuantum.com analysis (Ivezic, May 25, 2026); Bernstein, blog.cr.yp.to/20260630-risk.html; Apon and Espitau via LinkedIn (May 2026).

5. Kobeissi's "Verification Theatre" — Formal Verification Isn't a Silver Bullet

Nadim Kobeissi's paper (ePrint 2026/192, first received February 2026, 16 revisions through June 25) examines the gap between formal verification marketing and engineering reality through a case study of Cryspen's libcrux — a Rust library marketed as "formally verified" and "high-assurance," used by Firefox and OpenSSH.

What was found

13 vulnerabilities across libcrux and hpke-rs, including: - A platform-dependent cryptographic output failure in SHA-3 intrinsics (discovered by an independent researcher, November 2025) - Missing mandatory validation for X25519 DH outputs - Nonce reuse vulnerability via integer overflow - ECDSA signature malleability (absent low-S normalization) - An Ed25519 key generation defect - A wrong multiplication specification in ML-DSA that rendered axiomatized AVX2 proofs unsound

Four bugs were inside the formal verification boundary itself — meaning the proofs were checking the wrong thing. If "formally verified" ML-DSA code can ship with exploitable bugs, the prospects for the dozens of unverified implementations are bleak.

The dispute

The findings triggered a public conflict between Kobeissi and Cryspen, and a RustSec moderation controversy (Kobeissi was temporarily banned from RustSec advisory submission). Cryspen initially denied any bugs in verified code, then filed security advisories for the hpke-rs vulnerabilities in March 2026. Cryspen published a response ("The strengths and limits of formal verification," February 12, 2026) acknowledging the verification boundary doesn't cover all code paths.

Relevance: Formal verification is valuable but not sufficient. The verification boundary matters as much as the proofs within it. For PQC code, where the signing procedures are unusually complex and the ecosystem is adding hundreds of thousands of lines of new algorithm-specific code, formal verification should be one layer of testing — not a replacement for cross-implementation checksum comparisons, differential testing, and adversarial code review.

Sources: Kobeissi, ePrint 2026/192; The Register (March 20, 2026); Cryspen blog (February 12, 2026); Symbolic Software blog (February 5, 2026).

6. NIST Additional Signatures Round 3 — The Nine Survivors

On May 14, 2026, NIST released NIST IR 8610, advancing nine candidates to the third round of the Additional Digital Signatures process. Five were eliminated.

Diversity is the point: 4 multivariate, 3 MPC-in-the-head, 1 isogeny, 1 lattice. If any single mathematical family falls, alternatives exist in the pipeline. The third round is expected to last ~2 years (standardization ~2027–2028).

Cloudflare's analysis (July 2026) provides a sober assessment: none of these will be production-ready in time for the first migration wave. ML-DSA is the only game in town for 2026–2028. But the pipeline matters for algorithm agility — if ML-DSA's lattice assumptions weaken, SQIsign (148-byte signatures) or FAEST (AES-based, no lattice assumptions) could replace it.

Sources: NIST IR 8610 (nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8610.pdf); NIST CSRC news (May 14, 2026); PostQuantum.com analysis; Cloudflare blog ("Another look at PQ signatures").

7. Forescout PQC Adoption Data — The Gap in Numbers

Forescout Research / Vedere Labs published updated PQC adoption measurements (July 2026), using Censys, Shodan, and Forescout Device Cloud data:

Key finding: PQC adoption is concentrating in IT and cloud infrastructure (browsers, CDN edges) but lagging severely in operational technology, IoT, and medical devices — exactly the sectors with the longest equipment lifecycles and the most difficulty patching. Manufacturing, oil and gas, and mining have the lowest PQC adoption rates.

Freedom-tech relevance: Mesh networking hardware, embedded devices, and IoT gateways — the backbone of off-grid and decentralized infrastructure — are precisely the categories where PQC adoption is slowest. Anyone building privacy infrastructure on embedded platforms should be testing ML-KEM performance and footprint now (see the RP2040 / Cortex-M0+ benchmarking paper, arXiv:2603.19340).

Sources: Forescout blog ("PQC Adoption Gaps," July 2026); Forescout press release; arXiv:2606.16473 (Measurement Study of Post-Quantum Readiness, 2026).

8. MAS Singapore — Financial-Sector Quantum Resilience

On July 28, 2026, the Monetary Authority of Singapore (MAS) announced it will issue formal supervisory expectations later in 2026 to guide financial institutions' migration toward quantum-resilient cryptography, with the stated aim of achieving quantum resilience across the financial sector before the end of this decade.

MAS is treating quantum migration not as a standalone exercise but as one component of a technology-risk governance mandate covering AI, operational resilience, scam defenses, and third-party risk management. This is consistent with the global regulatory picture:

Sources: MAS FY2025/2026 Annual Report; PostQuantum.com analysis (July 28, 2026); RegTech.com (July 29, 2026); Charter of Trust "Decrypting the Future 2026."

9. Upcoming Conferences — Where the Next Breaks Will Surface

AM-PQC 2026 and Crypto 2026 are the most likely venues for results that could tighten or loosen security estimates for ML-KEM and ML-DSA parameters. The Ogilvie "concrete hardness gap" paper and any follow-up to the Luo preprint would surface here.

Sources: pqcrypto.cs.ru.nl/ampqc; crypto.iacr.org/2026; gsa.gov/events/2026-postquantum-cryptography-summit; pqcc.org/2026-pqc-forum.

10. Implementation Ecosystem Update

Testing infrastructure note: Bernstein's ML-DSA bugs paper highlights that standard interop tests and Wycheproof cannot catch the AABBCC and nonce-reuse bug classes. Cross-implementation checksum comparisons using derandomized RNGs are necessary. Organizations deploying ML-DSA should require vendors to demonstrate this level of testing.

Evidence at a Glance

The Pure vs. Hybrid Decision Matrix

This is the single most important deployment decision for PQC. Updated with Bernstein's quantitative analysis:

PQ Signature Size Reference (Updated with Round 3 Candidates)