Post-Quantum Saturday — June 20 2026 Weekly Update

The week-over-week companion to Overview - Post-Quantum Cryptography and PQC Deployment and Libraries Tracker. This note covers the seven days since the May/June PQC additions to this library, with a forward look at the next 7-14 days. The big story this week is not a deployment win — it is Bernstein's June 1 paper "Exploiting ML-DSA bugs", a coordinated CVE cluster in liboqs XMSS, the NIST IR 8610 nine-candidate Round-3 cut for additional signatures, and the maturation of mldsa-native toward v1.0.0. The freedom-tech takeaway: the PQC standards are real, but the implementations are not yet boring, and the diversity of the standards portfolio is finally catching up to the diversity of the threat.

TL;DR — This Week

• Bernstein's "Exploiting ML-DSA bugs" (June 1, 2026) — 59-page paper with two open-source attack demonstrations against ML-DSA (FIPS 204) signature implementations. Both attacks recover the secret key in under one second on a single laptop core, then forge arbitrary signatures that pass standard verification. Bernstein projects ~25% of ML-DSA libraries will ship with severe vulnerabilities; solo ML-DSA produces ~10× more breakable keys than hybrid Ed25519+ML-DSA for the next five years. This is the single most important PQC-implementation finding of 2026.
• NIST IR 8610 (May 14, 2026) — NIST announced 9 third-round candidates for additional post-quantum digital signature schemes, down from 14 second-round: FAEST, HAWK, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, UOV. Five were eliminated. Round 3 is expected to last ~2 years; the 7th NIST PQC Standardization Conference is targeted for late spring/early summer 2027.
• liboqs CVE cluster (May 29, 2026, fixes in 0.16.0) — Three related advisories for stateful hash-based signatures (XMSS/XMSS^MT): CVE-2026-44518 (unvalidated caller-supplied signature_len in wrapper layer), CVE-2026-46344 (OOB read via OID-controlled parameter mismatch in xmss_sign_open), and the original 2025 disclosure. All three fixed in the upcoming v0.16.0 release.
• RustCrypto ml-dsa regression (CVE-2026-24850) — A signature-malleability vulnerability in the RustCrypto ml-dsa crate was reported by Oren Yomtov (Fireblocks): a non-strict monotonic check (<= instead of <) on hint indices allows duplicate indices in ML-DSA signatures, breaking SUF-CMA. Fixed in v0.1.0-rc.4. The bug is a textbook example of the class of "passes KAT, fails spec" issue Bernstein's paper generalizes.
• OpenSSL 4.0.0 (April 14, 2026) + 4.0.1 (June 9, 2026) — OpenSSL 4.0 is the first OpenSSL release with a "TLS only" architecture and FIPS 140-3 module support. New PQC primitives: curveSM2MLKEM768 hybrid KEM, ML-DSA-MU digest algorithm, cSHAKE updates. The 4.0.1 patch (June 9) addresses 17 CVEs across 4.0.0, 3.6.3, 3.5.7, 3.4.6, and 3.0.21. None of the CVEs are PQ-specific, but the platform is now the reference FIPS 140-3 + PQC stack.
• mldsa-native v1.0.0-beta2 (May 27, 2026) — Second beta of the PQCA-maintained ML-DSA implementation. C backend is formally verified with CBMC for memory safety; AArch64 and x86_64 backends have growing HOL Light proofs of functional correctness. AWS adopted mldsa-native in production during the past month.
• NIST 6th PQC Conference status — FN-DSA (FIPS 206) IPD remains in the comment-resolution pipeline. The IETF draft-ietf-cose-falcon-04 (March 2026) tracks FIPS 206 alignment for COSE/JOSE. Final FIPS 206 publication still expected late 2026 / early 2027.
• OpenSSH 10.1 / 10.2 cadence — OpenSSH 10.0 made mlkem768x25519-sha256 the default KEX (April 2025). OpenSSH 10.1+ now warns when a non-PQ KEX is negotiated — the warning is appearing in the wild across macOS, NethSecurity, and Rocky Linux deployments.
• Cloudflare PQ traffic holding >65% — Cloudflare Radar shows PQ-encrypted HTTPS traffic in the 65-70% range through June 2026 across major countries, with India 70.6%, France 67.1%, Malaysia 62.0%, Saudi Arabia 60.1%. The "iOS 26 inflection point" of late 2025 is now a steady state.

The freedom-tech takeaway: the PQC migration of TLS is done. The PQC migration of authentication is the next frontier, and it is harder because implementations are not yet boring.

The Week in Detail

1. Bernstein's "Exploiting ML-DSA bugs" — June 1, 2026

The single most important PQC-implementation finding of 2026. Daniel J. Bernstein (cryptographer behind Ed25519, Curve25519, ChaCha20) published a 59-page paper on 2026-06-01 with two open-source exploit demonstrations against ML-DSA (FIPS 204) signature software. The paper is on his website (cr.yp.to/papers.html#mldsa) with the attack supplement at cr.yp.to/2026/mldsabugs-20260601.tar.gz.

The two attacks, both in <1 second on a single laptop core:

Attack 1 — The "AABBCC" coefficient-repetition bug

The first attack reproduces a 2018 vulnerability in the official Dilithium 1.0 reference implementation, originally announced by Dilithium team member Vadim Lyubashevsky on the NIST PQC forum in 2018. The bug causes consecutive coefficients in the secret polynomial y to repeat in pairs (the "AABBCC" pattern). Lyubashevsky said the bug "can easily be exploited to recover the secret key" — but no working demo existed. Bernstein supplies one.

The attack inspects a public key and two signatures; solves a system of linear equations over the polynomial ring to recover the four secret polynomials s₀, s₁, s₂, s₃. Bernstein ran the attack successfully on 50 consecutive randomly generated keys.

The bug class is copy-paste-modify with a forgotten index update. Bernstein's paper identifies similar vulnerable code patterns in mldsa-native and OpenSSL's crypto/ml_dsa directory, where a single index error produces the exploitable AABBCC pattern. Example: in OpenSSL, accidentally changing one subtraction to a bitwise AND in a chain of bitwise operations would zero out every other polynomial coefficient, producing an A0B0C0 pattern that is equally exploitable.

Attack 2 — Nonce repetition (the "PS3 disaster" of ML-DSA)

The second attack is the ML-DSA analog of the 2010 Sony PlayStation 3 ECDSA disaster (27C3 Console Hacking 2010). It triggers when the same secret nonce is reused — can happen via input-length miscalculation, or truncated hash inputs. Bernstein demonstrates the bug class: if a hash is computed over only part of the inputs, y₀, y₁, y₂, y₃ can repeat. Simple polynomial division recovers the secret key. ~80% success from two signatures; additional signatures resolve the remainder.

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

Why these bugs will ship in production

Bernstein examines three production codebases: official Dilithium reference, mldsa-native, and OpenSSL. Each contains dense, copy-paste-modify code patterns where a single index error produces an exploitable AABBCC pattern. The bugs pass all standard functionality tests:

• ✅ Valid ML-DSA signatures
• ✅ Interoperate with correct verifiers
• ✅ Pass known-answer tests (KATs) — if tests were generated by code with the same bug (as happened with both official Dilithium 1.0 implementations in 2017)
• ✅ Pass cross-library interoperability tests

The only catching method is cross-implementation checksum comparisons using derandomized RNGs — applied inconsistently across the ecosystem.

Quantitative case (Section 7 of the paper)

Based on the Blessing/Specter/Weitzner 2021 analysis of 312 CVEs across 8 major cryptographic libraries (2010-2020):

Figure 9.1.1 results (year 2027 breakable-key estimates):

• Ed25519+ML-DSA hybrid: ~4.09% = 2²⁵·⁴ keys (3.6% via ML-DSA bugs alone, 0.23% via combined, 0.26% via Ed25519 bugs)
• ML-DSA solo: ~18% = 2²⁷·⁵ keys
• Ed25519 solo: ~1.6% = 2²⁴ keys

Main finding: Solo ML-DSA produces ~order of magnitude more breakable keys than Ed25519+ML-DSA for first ~10 years after quantum computers arrive.

Implication for ungovernable systems

Bernstein directly challenges the April 2026 position of Filippo Valsorda ("hybrid ECC+ML-DSA signatures are unnecessary"). The argument is simple: ML-DSA is new code in new threat models, and the new code will have bugs. For high-value signing keys — Nostr npubs, ENS names, code-signing keys, certificate authority keys, blockchain validator keys — hybrid Ed25519+ML-DSA is the only responsible choice until ML-DSA implementations have a multi-year production track record. The Hybrid KEM Migration strategy applies to signatures as well as KEMs.

Reference: Exploiting ML-DSA bugs — Daniel J. Bernstein, 2026-06-01. Companion supplement: cr.yp.to/2026/mldsabugs-20260601.tar.gz. PostQuantum.com summary: Bernstein Demos ML-DSA Key Recovery in 1 Second.

2. NIST IR 8610 — Nine third-round PQC signature candidates

On May 14, 2026, NIST released NIST IR 8610 (full PDF: nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8610.pdf), announcing that nine candidate algorithms advanced to the third round of the Additional Digital Signatures for the NIST PQC Standardization Process. Five second-round candidates were eliminated. Round 3 is expected to last ~2 years, with the 7th NIST PQC Standardization Conference planned for late spring/early summer 2027.

The nine survivors, organized by mathematical family:

MPC-in-the-Head (MPCitH) — 3 candidates

• FAEST — AES-based. Signing key IS an AES key; verification key is input-output pair. Most conservative, established security assumptions. Drawback: signatures in kilobytes.
• MQOM — Best MPCitH performance; smallest combined public-key+signature sizes at all three NIST levels. Security: hardness of solving random multivariate quadratic systems. Caveat: security proofs in ROM and QROM need further maturation.
• SDitH (Syndrome Decoding in the Head) — Security: syndrome decoding problem for random linear codes (studied since 1970s). Slower than MPCitH peers; competitive sizes when tuned.

Multivariate (UOV family) — 4 candidates

The most heavily represented category, despite serious second-round damage.

• UOV — base Unbalanced Oil and Vinegar construction (1999)
• MAYO — "whipping" algorithm to expand seed key
• QR-UOV — Quotient ring mathematics
• SNOVA — MAYO-like whipping + block-ring structure (smallest keys)

Key advantage: signatures as small as 96 bytes at category 1; verification in tens of thousands of CPU cycles. Key cost: public keys in hundreds of kilobytes.

The Wedge Attack (early 2025, Ran): Uses exterior products to expose hidden oil subspace in characteristic-2 fields. Three of UOV's four parameter sets fell below security targets; MAYO2 (cat 1) lost ~30 bits; SNOVA hit hardest. QR-UOV emerged unscathed (uses odd-characteristic fields, immune).

NIST's warning: SNOVA has a "concerning history of cryptanalysis"; multivariate candidates "on a shorter leash"; longer expected timeline; may need further round of evaluation.

Isogeny-based — 1 candidate

• SQIsign — Signature size: 148 bytes at category 1 (fits in single Ethernet frame). Smallest combined public-key+signature size of any PQC candidate. Math: supersingular elliptic curves. Different security assumption class from lattices; critical insurance against a lattice-specific breakthrough.

Lattice-based — 1 candidate

• HAWK — A lattice scheme using different hardness assumptions than ML-DSA (Module-LWE/SIS) and FN-DSA (NTRU). Backup lattice signature if the standard assumptions fail.

Total: 9 third-round candidates across 4 families (lattice, isogeny, multivariate, MPCitH) — deliberate diversity.

Why NIST needs more signatures:

• Lattice concentration: 2 of 3 current standards (ML-DSA, FN-DSA) are lattice-based. Single breakthrough could compromise both. Historical precedents: Rainbow (multivariate, broken 2022 after reaching third round) and SIKE (isogeny KEM, broken over a weekend by Castryck-Decru in mid-2022).
• Signature size constraints — ECDSA P-256: 64 bytes. ML-DSA-44: 2,420 bytes. FN-DSA-512: 666 bytes. SLH-DSA-128 (small): 7,856 bytes. SQIsign (cat 1): 148 bytes. UOV (cat 1): 96 bytes. Constrained use cases that demand compact signatures: 8-bit IoT with 256 KB RAM, DNSSEC (engineered around 512-byte UDP packets), Roughtime, satellite comms, smart cards, TLS certificate chains.

Funnel: 50 submissions → 40 screened → 14 second round → 9 third round.

Reference: NIST CSRC: Nine Candidates Advance to the Third Round of the Additional Digital Signatures for the PQC Standardization Process. NIST IR 8610 PDF. PostQuantum.com analysis: NIST Selects 9 Third-Round PQC Signature Candidates.

3. liboqs CVE cluster — XMSS/XMSS^MT out-of-bounds reads

A cluster of three related advisories for stateful hash-based signatures (XMSS and XMSS^MT) was published on May 29, 2026, all fixed in the upcoming liboqs v0.16.0 release:

Technical details (CVE-2026-46344): When the verification function is called with a correctly-sized signature buffer for the declared algorithm but a public key whose OID bytes (pk[0..3]) reference a different XMSS parameter set with a larger sig_bytes, the implementation re-parses the OID from the public key inside xmss_sign_open / xmssmt_sign_open and uses the resulting (larger) sig_bytes to index the caller-supplied signature buffer. The downstream function xmssmt_core_sign_open discards the caller-supplied smlen ((void) smlen;) and indexes the signature buffer at offset params->sig_bytes - prefix_length, reading out of bounds.

Primary observable effect: process crash (denial of service) if the OOB read crosses into an unmapped page. No oracle exists to leak the OOB bytes — they are consumed only as input to an internal hash computation, and the maintainers have identified no mechanism by which they could influence the verification result.

Reachable from any caller of OQS_SIG_STFL_verify that accepts a public key from an untrusted or tampered source — firmware update metadata, TUF metadata, certificate stores.

Fix: per-variant verify wrappers add an OID consistency check that the public key's OID matches the declared algorithm's compile-time OID constant. The CVE-2026-44518 fix (commit ef70dea) is necessary but not sufficient; CVE-2026-46344 closes the remaining vector.

Operational impact: any system using liboqs to verify XMSS or XMSS^MT signatures with externally-supplied public keys should upgrade to liboqs 0.16.0 immediately upon release. Since v0.16.0 was unreleased as of June 20, 2026, apply the patch on the main branch of the GitHub repo or pin to a vendor-patched fork.

References: GHSA-wf7v-fhxj-73m2, GHSA-2wxh-55qf-c7wg, NVD CVE-2026-46344, NVD CVE-2026-44518.

4. RustCrypto ml-dsa signature malleability (CVE-2026-24850)

Reporter: Oren Yomtov (Fireblocks). Affected: RustCrypto ml-dsa crate v0.1.0-rc.2 and later commits since b01c3b7. Fixed in: v0.1.0-rc.4.

Root cause: A regression bug in the monotonic helper function in ml-dsa/src/hint.rs. Per FIPS 204 / RFC 9881, hint indices within each polynomial must be strictly increasing. The original implementation used strict less-than (<); commit b01c3b7 ("Make ML-DSA signature decoding follow the spec", fixing issue #894) inadvertently changed it to non-strict (<=), accepting duplicate indices.

Impact: Signature malleability — an attacker can take a valid signature and create additional "valid" signatures by duplicating hint indices. This breaks the SUF-CMA (Strong Unforgeability under Chosen Message Attacks) property that ML-DSA is designed to provide.

Affecting all ML-DSA parameter sets.

The PoC uses Wycheproof test vectors that specifically test for this invalid encoding (the invalid vectors should be rejected, the valid ones accepted).

This is the same class of bug Bernstein's paper generalizes: a one-character code change (< → <=) produces an implementation that passes all standard tests but violates the spec. The lesson is that spec compliance is not implementation correctness.

Operational impact: any application using RustCrypto ml-dsa should upgrade to v0.1.0-rc.4 or later. The fix is a one-character change: <= → <.

Reference: GHSA-5x2r-hc65-25f9, NVD CVE-2026-24850.

5. OpenSSL 4.0.0 and 4.0.1 — Major release + security patch day

OpenSSL 4.0.0 — Released April 14, 2026

The first major-version OpenSSL release since 3.0 (2021) and a TLS-only architecture milestone. Breaking changes:

• SSLv2 Client Hello support removed
• SSLv3 support removed (deprecated since 2015)
• Engine support removed — no-engine build option and OPENSSL_NO_ENGINE macro always present
• ASN1_STRING made opaque
• c_rehash script removed — use openssl rehash instead
• BIO_f_reliable() removed without replacement (broken since 3.0)
• Deprecated custom methods removed (EVP_CIPHER, EVP_MD, EVP_PKEY, EVP_PKEY_ASN1)
• Hex dump widths standardized: 24 bytes for signatures, 16 bytes otherwise
• Deprecated TLS EC curves (RFC 8422) disabled by default
• FIPS 140-3 module support — OpenSSL Corporation's FIPS provider was validated against FIPS 140-3
• libcrypto no longer cleans up globally allocated data via atexit() — OPENSSL_cleanup() now runs in global destructor

New PQC primitives: - curveSM2MLKEM768 — hybrid KEM group combining SM2 (China's curve) with ML-KEM-768. Targets Chinese compliance + PQC migration simultaneously. - ML-DSA-MU — digest algorithm for ML-DSA with multi-user / multi-tenant contexts - cSHAKE updates — additional SHAKE256 customization support for KMAC, TupleHash

OpenSSL 4.0.1 — Released June 9, 2026

A coordinated security patch day across five OpenSSL branches: 4.0.1, 3.6.3, 3.5.7, 3.4.6, 3.0.21. Total: 17 CVEs fixed in 4.0.1 alone, with 14 in 3.5.7. The CVEs are not PQ-specific but include:

• CVE-2026-42770 — FFC-DH peer validation uses attacker-supplied q (Bleichenbacher-style)
• CVE-2026-42768 — Multi-RecipientInfo Bleichenbacher Oracle in CMS_decrypt() and PKCS7_decrypt()
• CVE-2026-34182 — CMS AuthEnvelopedData accepts forged messages
• CVE-2026-42764 — NULL pointer dereference in QUIC server initial packet handling
• CVE-2026-42765 — NULL dereference in cert verification with OCSP Checking
• CVE-2026-42766 — NULL dereference in password-based CMS decryption
• CVE-2026-45447 — Heap use-after-free in PKCS7_verify()
• CVE-2026-45445 — AES-OCB IV ignored on EVP_Cipher() path
• CVE-2026-45446 — Incorrect tag processing for empty messages in AES-GCM-SIV and AES-SIV

4.0.1 also fixes two 4.0.0 regressions: - openssl pkey command crash when encrypting private key with interactive password - openssl s_client -adv prematurely terminating session on 16384-byte read() call

Operational impact: any production system using OpenSSL 4.0.0 should upgrade to 4.0.1 immediately. 3.5.x users should move to 3.5.7. The 3.0.21 backport addresses the most severe CVEs in the legacy 3.0 branch.

Reference: OpenSSL Releases on GitHub, Help Net Security: OpenSSL 4.0.0 release.

6. mldsa-native v1.0.0-beta2 — May 27, 2026

The PQCA-maintained, formally verified ML-DSA implementation reached its second beta on May 27, 2026. Key properties:

• C backend: production-ready, formally verified with CBMC (C Bounded Model Checker) for memory safety, type safety, and absence of (certain types of) undefined behavior. This is the most stringent formal assurance available for any production ML-DSA implementation.
• AArch64 and x86_64 backends: growing set of assembly routines carries HOL Light proofs of functional correctness, memory safety, and secret-independent execution (constant-time). Coverage is partial but expanding.
• ACVP test vectors: tested against all official NIST ACVP ML-DSA test vectors.
• Backends: C (default), AArch64 (Neon), x86-64 (AVX2).

The MLD_TOTAL_ALLOC_{44,65,87}_{KEYPAIR,SIGN,VERIFY} constants exposed in mldsa_native.h report the maximum cumulative MLD_ALLOC size for each parameter set and operation.

AWS adopted mldsa-native in production during the past month (per Matthias Kannwischer's LinkedIn post). This is significant because AWS's ML-DSA deployment in KMS and Private CA is now backed by a formally verified implementation.

Path to v1.0.0 stable: the beta releases are converging on stable. The remaining work is mostly additional assembly coverage and additional CBMC proof scope.

For ungovernable systems: mldsa-native is the strongest open-source ML-DSA implementation by formal-verification coverage as of June 2026. Any system that signs high-value, long-lived artifacts (Nostr event signatures, certificate authorities, code-signing, firmware updates) should consider using mldsa-native as a reference and aim for integration before the v1.0.0 stable release.

Reference: pq-code-package/mldsa-native on GitHub, Releases.

7. FN-DSA (FIPS 206) — IPD in comment resolution

The FIPS 206 Initial Public Draft remains in the NIST comment-resolution pipeline. The IETF draft-ietf-cose-falcon-04 (March 2026, expires September 2026) tracks FIPS 206 alignment for COSE/JOSE integration. Open questions at the NIST 6th PQC Conference (September 2025) included:

• SUF-CMA requirements — should FN-DSA be SUF-CMA like ML-DSA, or remain EUF-CMA (which allows the malleability class of bugs Bernstein's paper highlights)?
• Hedged variants — should the standard allow hedged (deterministic + randomized) signing?
• Key/message-recovery mode — should a recovery mode be standardized?
• Fixed-point signing — how to handle the floating-point dependency in Falcon's Gaussian sampling?

These are being resolved in the IPD period before final publication. Final FIPS 206 publication still expected late 2026 / early 2027.

HSM vendors (Utimaco, AWS CloudHSM, YubiHSM) have not yet shipped production FN-DSA support. The likely inflection point is 12-18 months after final FIPS publication.

For Nostr/ENS/identity systems: FN-DSA's compact signatures (FN-DSA-512: 666 bytes vs ML-DSA-44: 2,420 bytes) make it attractive for bandwidth-constrained chains. But the delay in finalization means ML-DSA remains the default for at least another 18 months.

Reference: draft-ietf-cose-falcon-04.

8. OpenSSH 10.0 / 10.1 / 10.2 cadence

• OpenSSH 10.0 (April 2025) — mlkem768x25519-sha256 made the new default KEX.
• OpenSSH 10.1+ — new warning: "WARNING: connection is not using a post-quantum key exchange algorithm" when a non-PQ KEX is negotiated. The two standardized PQ KEXs are mlkem768x25519-sha256 and sntrup761x25519-sha512.
• OpenSSH 10.2 (early 2026) — same PQ-default behavior; no breaking PQC changes.

Operational observation (from NethServer community and Juniper support portal): the warning is appearing in the wild across macOS, NethSecurity, and Rocky Linux deployments. This is the user-facing friction point of PQC migration: the warning is loud enough that end users notice and IT helpdesks field questions. Juniper published a 2026-03 reference advisory specifically addressing the new warning.

For ungovernable systems: when configuring SSH servers, the default mlkem768x25519-sha256 is fine. If you see the "not using PQ KEX" warning as a client, your server hasn't been upgraded.

Reference: OpenSSH Post-Quantum Cryptography, Juniper 2026-03 Reference Advisory.

9. Cloudflare PQ traffic: the iOS 26 inflection point is now steady state

Cloudflare Radar data through June 2026 shows PQ-encrypted HTTPS traffic holding in the 65-70% range across major countries, having settled after the iOS 26 inflection point of late September 2025 (where a single iOS update moved global share from 29% to 52% in about a week).

Country-level PQ adoption (Cloudflare Radar, June 2026):

The 2026 target for full PQ security including authentication remains Cloudflare's stated 2029 milestone (announced April 7, 2026, joining Google's March 25 announcement).

Operational implication for ungovernable systems: hybrid PQ TLS is now the default, not the exception. Any system that only supports classical TLS is increasingly the minority, and the "control" mode is becoming "fallback to classical" rather than "negotiate up to PQ".

10. Rust ecosystem ML-KEM/ML-DSA progress

The RustCrypto organization continues to ship production-ready PQ crates:

• ml-kem v0.3.2 — pure Rust FIPS 203 final, ready for production use
• ml-dsa v0.1.0-rc.4 — pure Rust FIPS 204 final, with the CVE-2026-24850 fix
• slh-dsa — pure Rust FIPS 205 final (Project Eleven analysis notes aws-lc-rs lacks SLH-DSA test vectors; this is improving)

Paragon Initiative Enterprises released ext-pqcrypto in April 2026 — a PHP extension in Rust that wraps the RustCrypto PQ KEMs and signature algorithms. Plus pqcrypto_compat (pure-PHP) for systems that can't install the extension. This is the first production PHP ecosystem path to PQC.

Project Eleven's "The State of Post-Quantum Cryptography in Rust" (2025) provides the comprehensive ecosystem audit. Key finding: as of August 2024 standardization + 1 year, Rust has the most complete production-ready PQ ecosystem of any language, with formal verification paths (mldsa-native, libcrux) leading the way.

11. State of the standards portfolio — June 2026 snapshot

Operational guidance (June 2026):

• TLS key exchange: hybrid X25519+ML-KEM-768 is the default. OpenSSL 3.5+, OpenSSH 10.0+, Go 1.24+, RustCrypto all support this.
• TLS authentication: ECDSA / Ed25519 is still the default because ML-DSA certificate chain support is incomplete. Hybrid Ed25519+ML-DSA in certificates is the near-term target.
• Long-lived code signing: hybrid Ed25519+ML-DSA is the responsible choice per Bernstein's June 1 analysis. SLH-DSA as a conservative backup for ultra-long-archive signatures.
• IoT / constrained: wait for HAWK, UOV, or SQIsign from the Round 3 cohort — none are deployable in 2026.
• Encrypted archives (multi-decade): hybrid ML-KEM-1024 key wrap + AES-256-GCM. The Hybrid KEM Migration playbook is the reference.

Cross-cutting observations

The implementation-maturity problem is the next big risk

The 2024-2025 narrative was "PQC standards are final, deploy hybrid". The 2026 narrative is shifting: the standards are fine, the implementations are not yet boring. Three independent data points in one week:

1. Bernstein's paper — two attack classes, <1 second exploits, ~25% of libraries projected to ship with severe bugs.
2. CVE-2026-24850 (RustCrypto ml-dsa) — a one-character regression (<= → <) in hint-index validation, enabling signature malleability. The bug was introduced in a "fix" commit.
3. liboqs CVE cluster (CVE-2026-44518, CVE-2026-46344) — three related OOB read issues in stateful hash-based signatures, all reachable from external public keys.

The pattern: standardized algorithms + new code + new threat model = exploitable bugs. The 2026 lesson: hybrid is not optional for high-value keys until ML-DSA implementations have a multi-year production track record.

Lattice concentration: 9 candidates for diversity

NIST IR 8610's Round 3 selection deliberately maintains diversity across four families: lattice (HAWK), isogeny (SQIsign), multivariate (UOV, MAYO, QR-UOV, SNOVA), MPCitH (FAEST, MQOM, SDitH). Only one of the nine third-round candidates is lattice-based, and HAWK uses different hardness assumptions than ML-DSA and FN-DSA. This is NIST's hedge against a single cryptanalytic breakthrough compromising the standard lattice problems.

For long-lived deployments (10+ year archives), diversification across families is a sensible architecture: a primary ML-DSA signature with an SLH-DSA or HQC backup provides a second line of defense.

The FN-DSA finalization path is the only remaining "wait"

Every other major standard (ML-KEM, ML-DSA, SLH-DSA) is final and deployable. FN-DSA is the last "wait" — the IPD is in comment resolution, the COSE/JOSE spec is drafted, and HSM vendors are waiting on the final FIPS publication. Once FIPS 206 is final (late 2026 / early 2027), the HSM-and-PKI supply chain will be the next 12-18 months of work.

Standards-aligned attack surface

The fact that NIST-standardized algorithms are now showing up in criminal malware (Kyber ransomware, active since September 2025) and that NIST-standardized algorithms are now showing up in academic attack papers (Bernstein's ML-DSA exploits) is the operationally neutral sign of maturity. The same algorithms are simultaneously the right primitives for defenders, the right primitives for attackers, and the right primitives for academic scrutiny. That is what "mature cryptography" looks like.

Evidence at a Glance

What to Watch in the Next 7-14 Days

• mldsa-native v1.0.0 stable — the beta2 (May 27) is the second beta; a v1.0.0 release is plausible within the next 2-4 weeks if the remaining CBMC and HOL Light proofs close.
• liboqs v0.16.0 release — fixes the XMSS CVE cluster, removes SPHINCS+ in favor of SLH-DSA, drops Dilithium Round 3. Expected within 2-3 weeks of June 20.
• FN-DSA IPD comment-resolution update — NIST typically publishes resolutions after the IPD comment period closes. Any announcement here would push FIPS 206 closer to final.
• CFRG draft on ML-DSA security considerations — draft-connolly-cfrg-ml-dsa-security-considerations-02 (March 2026) is the IETF's operational hardening guide for ML-DSA deployments. Watch for updates incorporating Bernstein's findings.
• Round 3 signature spec publications — the 9 third-round candidates will begin publishing updated spec documents and reference implementations. HAWK, MAYO, and SQIsign are the early standouts for production interest.
• Apple WWDC 2026 (typically early June) — any new PQ announcements (e.g., ML-DSA in CryptoKit, FN-DSA previews) would shift the deployment picture.
• ePrint 2026/1200+ cluster — expect follow-up papers to Bernstein's ML-DSA bugs paper, including additional bug-class analysis and possibly more exploits in other implementations.

Primary Sources

• Bernstein, D. J. Exploiting ML-DSA bugs. 2026-06-01. http://cr.yp.to/papers/mldsa-20260601.pdf
• NIST IR 8610. Status Report on the Second Round of the Additional Digital Signature Schemes for the NIST PQC Standardization Process. May 2026. https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8610.pdf
• NIST CSRC. Nine Candidates Advance to the Third Round of the Additional Digital Signatures for the PQC Standardization Process. 2026-05-14. https://csrc.nist.gov/News/2026/nist-advances-9-candidates-to-the-3rd-round-of-pqc
• OpenSSL Foundation. OpenSSL 4.0.0 / 4.0.1 / 3.6.3 / 3.5.7 / 3.4.6 / 3.0.21 release notes. https://github.com/openssl/openssl/releases
• Open Quantum Safe. liboqs security advisories GHSA-wf7v-fhxj-73m2 and GHSA-2wxh-55qf-c7wg. https://github.com/open-quantum-safe/liboqs/security/advisories
• RustCrypto. GHSA-5x2r-hc65-25f9 — ML-DSA signature verification accepts signatures with repeated hint indices. https://github.com/advisories/GHSA-5x2r-hc65-25f9
• PQCP. mldsa-native v1.0.0-beta2 release. https://github.com/pq-code-package/mldsa-native/releases
• IETF. draft-ietf-cose-falcon-04 — FN-DSA for JOSE and COSE. March 2026. https://www.ietf.org/archive/id/draft-ietf-cose-falcon-04.html
• Cloudflare Research. PQC 2029 target announcement. 2026-04-07. https://blog.cloudflare.com/pqc-2029-target
• Apple Support. Prepare your network for quantum-secure encryption in TLS. https://support.apple.com/en-us/122756
• PostQuantum.com. Bernstein Demos ML-DSA Key Recovery in 1 Second. https://postquantum.com/security-pqc/bernstein-exploiting-mldsa-bugs
• OpenSSH Project. Post-Quantum Cryptography. https://www.openssh.com/pq.html
• Project Eleven. The State of Post-Quantum Cryptography in Rust: The Belt is Vacant. https://www.projecteleven.com/blog/the-state-of-post-quantum-cryptography-in-rust
• Paragon Initiative Enterprises. Post-Quantum Cryptography for the PHP Community. 2026-04. https://paragonie.com/blog/2026/04/post-quantum-cryptography-for-php-community