Security · 2026-08-08

Three 2026 Headlines About ML-DSA, Steelmanned and Corrected

By J. W. Bouckaert

Three 2026 headlines, one question: Is ML-DSA broken?

A document has been circulating that stacks three 2026 research results into a single conclusion: ML-DSA is finished. It cites a Bernstein paper that recovers an ML-DSA secret key in under a second, an AI system that broke a lattice signature scheme, and side-channel attacks that lift ML-DSA keys off hardware. Each of the three is a real piece of 2026 research. None of them is fabricated, and none of them should be dismissed.

The conclusion drawn from them, however, does not follow.

The distinction that the document erases—and the distinction this article insists on—is the difference between a break of a standardized algorithm and a failure of a particular implementation, a particular scheme, or a particular deployment context. ML-DSA (NIST FIPS 204, standardized August 2024) is a mathematical construction resting on Module-LWE and Module-SIS. Two of the three results say nothing about that construction; the third is a genuine but indirect warning that lands on implementation assurance rather than the algorithm. This piece steelmans all three, corrects the specific misframing in each, and then maps each one to what PasskeyBridge actually runs in production—a hybrid envelope where a break of the post-quantum layer alone cannot forge a credential.

We will not overclaim about the papers, and we will not overclaim about our own system. Where our architecture has a soft edge—a legacy envelope, a stubbed test slot, a reference-build implementation that is not side-channel hardened—we say so.

Claim One: Bernstein's "Exploiting ML-DSA Bugs" recovers a key in under a second

The strongest version of this claim is genuinely alarming, and it should be taken seriously. In 2026 Daniel J. Bernstein published work, with open-source demonstrations that recover an equivalent ML-DSA secret key in under one second on a single laptop core, then forge signatures that pass standard verification. The demos are real and the code is public.

What they attack is the load-bearing detail. The paper walks coefficient-unpacking code in three production libraries—the official Dilithium reference implementation, mldsa-native, and OpenSSL's crypto/ml_dsa—and shows how a single-character defect creates an exploitable, test-passing bug. The headline defect is the "AABBCC" bug: secret-polynomial coefficients unpacked so they repeat in pairs, an ML-DSA-specific descendant of a 2018 issue flagged by Dilithium co-author Lyubashevsky. The paper's real thesis is a software-assurance warning. These bugs survive ordinary known-answer tests, because a KAT generated by the same buggy code interoperates with itself. They are reliably caught only by cross-implementation checksum comparison using derandomized RNGs, and Bernstein estimates a large fraction of shipping libraries will carry defects of this class.

That is an important result. It is not a break of FIPS 204.

Every attack in the paper requires a defective implementation to already be present. A correct, spec-conformant ML-DSA implementation is untouched by any of them. The mathematics of the standard is not in question—the correctness of specific unpacking code is. The remedy is not to abandon ML-DSA; the remedy is implementation assurance: cross-implementation KAT comparison, ACVP vectors, and negative tests against malformed keys.

This is the one claim of the three with a real, if indirect, operational implication, so we treat it as an action item rather than a dismissal.

The implementation-bug class at PasskeyBridge

PasskeyBridge runs real ML-DSA (FIPS 204) through the mldsa-wasm WebAssembly package, pinned to exactly version 0.0.4. The pin is enforced in CI by check-pqc-pin.mjs, which fails the build on any range operator or version drift, and it is resolved in deno.lock. A floating dependency is precisely how an upstream unpacking regression would arrive unannounced; a hard pin turns any future change into a reviewed event.

Behind the pin sits a correctness gate, mldsa-kat.test.ts, that runs today. It performs deterministic KeyGen from a fixed FIPS 204 seed (ξ = 0x00..0x1f) and asserts three things: that KeyGen is reproducible, that the produced public key matches a pinned SHA-256, and that signatures are the exact FIPS 204 byte length. The pinned values are concrete:

An "AABBCC"-style unpacking bug changes the bytes a library produces from a fixed seed. If such a defect arrived in a future mldsa-wasm bump, the golden SHA-256 would no longer match and the gate would fail before deploy. The suite also covers a sign→verify roundtrip, tamper rejection, and cross-parameter-set rejection (an ML-DSA-65 signature must not verify as ML-DSA-87).

We will not overstate this gate, because the honest scope is exactly the distinction Bernstein draws. A pin captured from 0.0.4 detects a future regression—a library bump that changes the output of a fixed seed—but it cannot flag a defect already present in the pinned build, because a known-answer test generated by buggy code agrees with itself forever. Catching a pre-existing defect requires comparison against an independent, known-good reference, which is what the authoritative NIST ACVP known-answer vectors provide. That ACVP slot exists in the same file but self-skips with a console warning until fixtures/mldsa-acvp-vectors.json is committed—a tracked follow-up awaiting its fixture. So the honest claim is narrow and true: PasskeyBridge pins its ML-DSA library and gates every deploy on deterministic-output correctness against captured golden values, catching the unpacking-regression direction of the bug class Bernstein describes, while the cross-implementation ACVP check remains the tracked piece that would catch a defect baked into the pinned build itself. It does not yet run the full official ACVP suite in CI, and we do not claim it does.

Claim Two: An AI cracked HAWK, and HAWK is what ML-DSA relies on

The first half of this claim is true and notable. In July 2026 Anthropic disclosed that its Claude "Mythos Preview" model found a previously unknown nontrivial automorphism—a symmetry—in the lattice underlying HAWK, a lattice signature scheme. Building on prior theoretical work by Daniel van Gent and Ludo Pulles, which had shown such an automorphism would enable an attack without yet finding one usable against HAWK, the new symmetry yields a deterministic polynomial-time reduction from HAWK-n key recovery to exact SVP in dimension roughly n/2+1. That roughly halves the effective block size, meaning HAWK would need doubled parameters to survive. The HAWK team withdrew the scheme from NIST's additional-signatures onramp the following day, in late July 2026. This is real cryptanalysis, and machine-assisted cryptanalysis finding a structural symmetry a human team had not is a genuinely significant moment.

The second half of the claim is simply false. ML-DSA does not rely on HAWK. They are different schemes with different hardness assumptions.

HAWK (Ducas-Postlethwaite-Pulles-van Woerden) is built on the module Lattice Isomorphism Problem—the search-module-LIP assumption plus a One-More-SVP assumption—using a rank-2 module lattice with a Gram-matrix public key and no modulus q. It sits in the Falcon/NTRU-adjacent family. ML-DSA (CRYSTALS-Dilithium, FIPS 204) is a Fiat-Shamir-with-aborts scheme whose security rests on Module-LWE and Module-SIS: finding short vectors in module lattices. The Mythos automorphism exploits HAWK's lattice-isomorphism structure specifically, and per the reporting it has no known analogue against Module-LWE. Multiple independent outlets covering the result state explicitly that ML-KEM, ML-DSA, SLH-DSA, and Falcon are unaffected.

There is a second framing error worth naming. HAWK was never standardized or deployed. It was an active candidate in NIST's additional-signatures onramp that its own authors withdrew once the weakness surfaced—the vetting process working as intended. Contrast that with ML-DSA, which is a finalized federal standard. "An AI helped surface a structural weakness in a candidate that was then withdrawn before it shipped" is close to the opposite of "an AI broke the deployed standard."

The HAWK result and the PasskeyBridge envelope

PasskeyBridge signs with ML-DSA-65 as the fleet default; ML-DSA-87 is a higher-security parameter set that is live in code and gated per tenant by pqc_level. Neither uses HAWK—PasskeyBridge has never used HAWK, and HAWK never reached a state where anyone could have deployed it. The post-quantum layer of every PasskeyBridge credential rests on Module-LWE/Module-SIS, the assumption the Mythos result explicitly does not reach.

The deeper point is architectural. Even if a future result did dent ML-DSA, the HAWK episode is the argument for cryptographic agility—NIST's process surfaced a structural weakness in a candidate and removed it before deployment. A platform's job is to be positioned to migrate parameters or schemes when that happens, which is why the parameter set is a per-tenant gate rather than a hardcoded constant.

Claim Three: Single-trace side-channel attacks can steal ML-DSA keys

This one is real, and the demonstrations are impressive. Single-trace and few-trace power and electromagnetic side-channel attacks that recover an ML-DSA/Dilithium secret key were demonstrated across 2024-2026 research. They exploit leakage from NTT operations, secret-key unpacking, and—in 2026 work—both rejected and accepted signing trials. Demonstrations run on an ARM Cortex-M4 microcontroller using real power/EM traces, recovering keys with as few as roughly 300 traces, with some challenge recovery reported in around 96 traces, at high success rates. The papers also note that deterministic and hedged signing modes do not by themselves stop these attacks, and that some machine-learning attacks defeat common masking and jitter countermeasures.

The correcting fact is in the phrase "power and electromagnetic." These are physical side-channel attacks. The attacker must have physical access to the signing device to measure its power consumption or its EM emanations while it signs. They do not break ML-DSA mathematically, and they are not remote. They target implementations running on attacker-accessible hardware—smartcards, microcontrollers, embedded signers—not the FIPS 204 algorithm.

The threat model matters more than the trace count here. To capture a power or EM trace, you need the device.

The server-side signing boundary removes the channel

Every ML-DSA and classical signature in PasskeyBridge is produced server-side, inside a managed Supabase Edge/Deno isolate. The signing key is derived in-memory from SHIELD_ENCRYPTION_KEY through a single domain-separated HMAC-SHA-256 that produces a 32-byte seed, which is expanded into an ML-DSA key per FIPS 204. Keys are deterministic per (domain, level) and are never stored at rest. There is no on-device signing path, no HSM token, no smartcard, and no secure-enclave signer. This is documented as the SDS 14.7 boundary.

That boundary is what makes the single-trace threat model inapplicable to the deployed service. A remote attacker has no power rail to probe and no EM emanation to capture from a signing operation happening inside a cloud isolate. The physical-access precondition the attacks require is absent.

We will be precise about what we are not claiming. The mldsa-wasm build in use is a reference build. It is not masked, constant-time or side-channel-hardened. SDS 14.7 lists masking, constant-time hardening, and hedged/randomized signing as tracked future work, to be added only if signing ever moves on-device. As long as signing stays server-side, the relevant defense is the deployment boundary well ahead of micro-architectural hardening—and we describe it that way rather than claiming a hardening property the current build does not have. If the architecture ever placed a signer on a user's device or a smartcard, this threat would move firmly into scope, and the countermeasure work would move with it.

The threat in each result

Reduced to the question a security engineer actually has—does this let someone forge a PasskeyBridge credential—the three claims line up cleanly.

Three real results. Three overstatements. Zero of them forge a credential in the deployed system.

Defense in depth

Suppose we are wrong about one of these. Suppose a future refinement does weaken ML-DSA in a way that reaches Module-LWE. The PasskeyBridge envelope is built so that a break of the post-quantum layer alone still does not produce a forgery.

The default issuance envelope is hybrid and standards-based: a compact ES256 (P-256 ECDSA) JWS plus a detached ML-DSA proof. Verification requires both. In the standard path, verifyVC sets signature_valid = es256Ok && pqcOk—an independent classical ECDSA signature, publicly verifiable against the DID-published EC key, and a detached ML-DSA signature, independently verifiable against the published AKP (ML-DSA) JWK, must both check out. For the ML-DSA-87 tier the classical layer is ES384 over P-384, aligned to CNSA 2.0.

Hybrid credential envelope (default issuance)
┌─────────────────────────────────────────────┐
│  Classical layer   ES256 (P-256 ECDSA) JWS   │  ← must verify
│                    publicly verifiable        │
├─────────────────────────────────────────────┤
│  PQC layer         detached ML-DSA-65 proof   │  ← must ALSO verify
│                    verifiable vs published AKP │
└─────────────────────────────────────────────┘
        both es256Ok AND pqcOk → signature_valid

The consequence is direct. To forge a credential, an attacker must defeat both layers on the same token: the post-quantum ML-DSA signature and the classical ES256/ES384 ECDSA signature. A hypothetical ML-DSA weakness, by itself, still leaves the classical ECDSA signature standing, and vice versa for a classical break. The hybrid construction is exactly the hedge for a world where any single scheme might weaken.

Two honesty notes, because absolutes fail here. First, this hybrid ES256+ML-DSA envelope is the universal default for new issuance—getTenantProofFormatPreference() returns standard for any tenant whose preference is unset—but it is not every credential in existence. A legacy PQC-HYBRID envelope, whose classical layer is a symmetric server-held HMAC rather than a publicly verifiable ECDSA signature, still exists. It is emitted for tenants that explicitly opt into hmac, and as a safe-degrade fallback when tenant key provisioning fails, so issuance never hard-fails. In that legacy envelope the classical layer is verifiable server-side and closed to third parties. Older credentials were issued under it. Second, the ES256 flip covers credential issuance; Verifiable Presentations (createVP/verifyVP) still hardcode the legacy PQC-HYBRID envelope regardless of tenant preference. Both are known, tracked edges, and neither changes the ML-DSA threat analysis above.

A checklist for this week

Strip the three headlines down and a short, unglamorous checklist remains—and only one item traces back to a genuine ML-DSA implication.

1. Pin and gate your ML-DSA library. The Bernstein result is the actionable one. Confirm the ML-DSA library your stack uses is version-pinned and that CI gates deploys on deterministic-output correctness—ideally the official NIST ACVP vectors, at minimum a captured golden public-key hash and exact FIPS 204 byte lengths, plus negative tests against malformed keys. This is the defense against the implementation-bug class, and it is defense-in-testing, not defense-in-cryptography.

2. Do not swap schemes over the HAWK result. HAWK cryptanalysis has no bearing on an ML-DSA deployment. If anything, it is evidence the standardization process is doing its job. Keep your posture; keep your agility to migrate parameters if the picture ever changes.

3. Know where your keys are signed. The side-channel research is a real threat to on-device, smartcard, and embedded signers, and a non-issue for server-side cloud signing with no attacker-accessible power or EM trace. Map your signing topology before you decide the attack applies to you. For most SaaS-issued credentials, it does not.

4. Prefer hybrid envelopes. The cleanest hedge against any single-scheme surprise—classical or post-quantum—is requiring two independent signatures to verify. A break of one layer alone should not forge anything.

The document that started this made a category error three times: it confused a buggy library with a broken algorithm, a withdrawn candidate with a deployed standard, and a physical-access attack with a remote one. Each of the underlying results deserves attention from the people whose job is implementation assurance, standardization, and hardware security. None of them is a reason to distrust ML-DSA as a standard, and none of them forges a credential in a hybrid, server-side, pinned-and-gated deployment.

The right question is not "should we still trust ML-DSA." It is "does our deployment survive the failure of any one component we depend on." A hybrid envelope that requires both an ES256/ES384 signature and a detached ML-DSA-65/87 signature to verify is a specific, shipped answer to that question—not a roadmap slide with a 2028 target date.

Read the harvest-now, decrypt-later threat model and cryptographic agility as a protocol property for how the same envelope handles the longer-horizon risks. Get started with PasskeyBridge →

Start free · Test the API