On June 4, 2026, Daniel Bernstein posted the work "Exploting ML-DSA bugs" (c.yp.to/papers/mldsa-20260601.pdf) - 59 pages, two working demonstrations key recovery from ML-DSA (FIPS 204). Both attacks end in less than a second on one kernel of a laptop: at the entrance - a public key and two signatures, at the exit - a full secret key and the ability to stamp fake signatures passing the standard verification. In parallel, studies have appeared that systematize the se-channel of the randomness leak in ML-DS as a family of tasks Integer Learning with Errors (ILWE) and show that Belief Propagation spores drop the threshold of one-to-do attack by the number of necessary signatures. In the Russian-speaking space, these results are scattered superficially - we understand from mathematics signatures to specific solovers.
ML-DSA signature procedure: anatomy of a vulnerable component
ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204) is a post-quantum digital signature standard, formerly known as CRYSTALS-Dilithium. The safety of the scheme stands on two legs: durability of the lattice problem Module-LWE / Module-SIS and the secrecy of ephemeral randomness used at each act of signature. The first leg is intact. The second breaks with even a few bits.
Steps Sign by Algorithm 7 FIPS 204
The signature of the M message passes through the rejection loop, and each element of this cycle is critical to understanding the attack vector:
Calculation mu. Hash Mu = H(tr | | | M', 64) - 64-by-byte digest, including tr (public key hash, binding signature to a specific key) and a formatted message M' (Algorithm 7, FIPS 204). The meaning of tr prevents key substitution: the signature is rigidly attached to a specific public key.
Generation of the genus of the wounds p'. In the hedged mode (default) p' = H(K || rnd || mu, 64), where K is the key secret component, rd - 32 bytes of fresh wounds from RNG. In the deterministic mode, rend = 0x00...00. The p' value is the only source of entropy for the generation of the vector y.
Deploying a mask y via ExpandMask(p', k). The vector y ∈ R_q^l contains coefficients in the range [-(Y1-1), Y1). For ML-DSA-44 Y1 = 2^17 (coefficients are represented by 18 bits with a sign), for ML-DSA-65 and ML-DSA-87 Y1 = 2^19 (20 bits with a sign). The meter κ is incremented at each rejection - fresh values of y at each iteration without rediscovering to the RNG.
Calculation w = A*y and decomposition w into the older (w1) and younger bits. Matrix A - public, generated from p (public key component).
Challenge c = H(mu, w1) - spared by a polynomial in R_q with exactly t zero coefficients (+-1). For ML-DSA-44 t = 39, for ML-DSA-65 t = 49, for ML-DSA-87 t = 60.
Response z = y + c*s1. Here s1 is a secret vector made of private key. This is the central equation of the entire scheme: if the attacker knows y, it calculates c*s1 = z − y and restores s1. That's it. The game is over.
Rejection sampling. If ||z|∞ >= Y1 − beta or if the younger bits w − c*s2 go beyond the permissible boundaries, the signature is rejected, κ increases, the algorithm returns to the generation of the new y.
Why you need a replaying
Without sampling rejection, each published signature z = y + c*s1 would carry statistical information about the secret s1 through distribution y. Rejection sampling - a mechanism from the paradigm Fiat-Shamir with Aborts (Lyubashevsky, 2009) - ensures that the distribution of accepted z is indistinguishable from the one-aligned for the permissible set and does not depend on s1.
The invariant lasts exactly as long as y is completely hidden from the observer. Leakage of partial information about y - through side-channel (energy consumption, cache timing, electromagnetic radiation) or through the software bag - turns public signatures into a system of equations with a secret. And then the most interesting thing begins.
Lock of the ML-DSA randomness as an Integer LWE task
"From Regression to Prior-Aware Inference: Solving the ILWE Family in Randomness Leakage Attacks against ML-DSA"arxiv.org/html/2607.059221v1) formalizes the attack through the lack of lack of sleep as a two-stage procedure:
Stage 1 - design of ILWE-instant from leakage and public signatures. Stage 2 - the decision of the Soldier to restore s1.
The previous works were dug the first stage: how to build a system of equations under different leakage models. The systematic analysis of the influence of the sollver in the second stage was absent.
How the Bit Leak Transforms into Equations
Take one signature with a response z = y + c*s1. Let's say the attacker knows k the older beats of each coefficient. Then y = ? ? , + ε, where ?, is a known approxime, |ε| < 2^(b-k) for b-bit coefficients. The substitution gives:
z − ? = ε + c*s1
The left part is known, c is published as part of the signature, s1 - an unknown secret, ε - limited noise. This is the task of Integer LWE. From N signatures with a leak, a system of N of such ratios is built. Beautiful, isn't it?
Three variants of ILWE
According to the classification of arxiv.org/html/2607.059211v1, three options arise from arxiv.org/html/2607.059211v101, depending on the leakage model:
OILWE (Ordinary ILWE) - a basic model with a known matrix, vector and unknown secret and noise. The standard for calibration of salver.
FS-ILWE (Fiat-Shamir ILWE) - occurs with a broken leak of wound y. The leakage of one bit at the position j of the coefficient y through the equation z = y + c*s1 gives one integer ratio with the secret. The difference from OILWE is the heterogeneity of noise: each equation is tied to a specific position of bit and a specific challenge c, the variance dances from line to string.
CILWE (Concealed ILWE) - occurs when leaking information about zero coefficients y. If side-channel allows you to identify the coefficients y equal to zero (through profiling of power consumption), then for such positions z_i = c_i * s1 - an exact equation without noise. But profiling is not perfect: part of the identified “zeros” are actually non-zero (ceater). With a distress rate above 0.9, the problem becomes sharply complicated - false zeros are converted into gross emissions in the system of equations. And here the choice of the solover decides everything.
Solves key recovery: three classes of approaches
The central result of work on arxiv.org/html/2607.0591v1 is the choice of a solover for the ILWE-tisansion determines the practical feasibility of the attack at least the quality of the leakage itself. Previous studies used ad-hoc salver under specific leakage models without systematic comparison. The authors corrected this.
Regression of the smallest squares (OLS and L1-estimators). Solution in real numbers z* = argmin ||Az − b|| followed by rounding to the nearest integers from the permissible set. The approach is simple and cheaply computationally, but requires a significant stock of equations for correct rounding, especially with high noise. Enough to implement numpy.linalg.lstsq and coordinate rounding - nothing exotic.
Robamost regression (Cauhy) Resistant to emissions. In the context of CILWE, emissions are the same false “zero” coefficients that create gross errors in individual equations. Cauchy-regression with its heavy-tailed profile of the loss function is maintained at a partialment rate above 0.9, where OLS and Huber collapse.
Prior-aware (Belif Propagation, greedy search, hill-climbing). A fundamentally different beast. BP works directly in the final discrete secret space – no rounding of real numbers. For ML-DA, the coefficients s1 are in a small length: at n = 2 it is {−2, −1, 0, 1, 2, 2}, at n = 4 - {−4, ..., 4}. BP builds a graph (factor graph), where each node-variable corresponds to the coefficient s1, and each factor knot - one equation from the ILWE-instanus. A priori knowledge of the discreteness and limitation of coefficients is sewn directly into messages that race the graph.
Results: BP reduces the threshold of attack on orders
A decrease of one or two orders of magnitude (10-100 *) in the number of necessary informative relationships is the boundary between "theoretically interesting" and "can be made with your hands." If the broken leak through side-channel gives one informative bit for signature, OLS will require a thousand observations, and BP - dozens. BP also expands the range of attacked positions: OLS works only with a leak of the older bits (high signal/noise ratio), BP pulls the secret when leaking younger positions - where OLS is already on.
Side-channel attacks require physical or micro-architectural access to the sign system. Bernstein’s work (crpress.to/papers/mldsa-20260601.pdf) hits on the other hand: software errors in the implementations of ML-DSSA, leading to a complete (non-partial) leak or structural damage to the wound-wise.
AABBCC bug: paired coefficients in mask y
Error in the dispensing code of polynomial coefficients, at which the coefficients are duplicated by pairs: y = (a, a, b, b, c, c, c, ...) instead (a, b, c, d, e, f, ...). The defect occurs with improper indexation in the chain of bit operations - a typical situation when a copy-paste-modify of one index expression leads to a doubling. According to the analysis on postquantum.com, Bernstein showed that in the OpenSSL implementation of ML-DSA, the bitwise operation chain contains a place where replacing one subtraction with a beaten AND would reset every second coefficient (pattern A0B0C0) - an equally exploited version.
Bernstein attack: from the public key and two signatures, a system of linear equations over the ring of polynomials R_q is built, the solution of which gives four secret polynomial s0, s1, s2, s3. The demonstration worked on 50 consecutively generated random keys - without misfires.
And here’s what’s really unpleasant: signatures with AABBCC-baga are Valid. They undergo standard verification, known-answer tests (if the tests are generated by code with the same bug) and cross-library interop inspections. Both official Dilithium 1.0 in 2017 contained a bug of this class, found only in cross-imprelation comparison with the derandized RNG. Two out of two are 100%.
Nonce reuse: ML-DSA-analogue PS3 ECDSA
The second attack exploits the reuse of the y vector in two signatures - a direct analogue nonce reuse in ECDSA (Sony PlayStation 3, 2010), adapted to the ring of polynomials.
If (z1, c1) and (z2, c2) are signed with the same y, subtraction gives:
z1 - z2 = (c1 - c2) * s1
The secret s1 is restored by polynomial division in R_q provided verbitation (c1 - c2). For random ML-DSA diamonds with τ non-zero coefficients +-1, the difference has coefficients in {−2, −2, −1, 1, 2, 2} and reversible in R_q = Z_q[x]/(x^256 + 1) with a high probability.
Python:
SageMath, q = 8380417 (ML-DSA-44)
Rq = PolynomialRing(GF(8380417), 'x').quotient('x^256 + 1')
delta_z = Rq(z1 - z2)
delta_c = Rq(c1 - c2)
s1_recovered = delta_z * delta_c.inverse_of_unit()
According to postquantum.com, the attack triggers in about 80% of cases out of two signatures; additional signatures with the same nonce cover the rest. Repeating nonce can occur due to an error in calculating the length of the input data of the hash function or truncation of the hash-entrances - bugs, invisible to standard functional tests. The tests are green, the key is in the hands of the attacker.
Forecast of scale: 25% of libraries with critical bug
Bernstein is building a statistical model based on empirical data Blessing, Specter and Wetzner (2021): 312 CVE in eight large cryptographic libraries for 2010-2020, 0.45-1.19 CVE on 1000 rows of added code, the average used lifetime of 5.13. Extrapolation from cr.yp.to/papers/mlds-20260601.pdf: 50 ML-DSA * 2000-4000 lines of specific code = 100 000-200 000 lines. With the observed historical figures - about 100 vulnerabilities. With a share of critical ~1/8, about 25% of libraries will release the first release with at least one vulnerability of the “forgery signature” class.
For comparison: for 10+ years of existence of about 100 libraries Ed25519 recorded 1-2 critical vulnerabilities. The difference is in order.
Additional evidence: an analysis on postquantum.com refers to the work of Kobeissi ("Verification Theatre"), which has found 13 vulnerabilities in Cryspen's libcroux - a library with a declared formal verification used by Firefox and OpenSSH. Four bugs sat inside the perimeter of formal verification, including the incorrect multiplication specification in ML-DSA, which made the axiomatized AVX2-proofs untenable. Formally verified, and the bug - here he is.
Operational context: mapping on MITRE ATT&CK
Attacks on the randomness of ML-DSA form a chain through several techniques.
Main chain: Exploitation for Credential Access (T1212) -> Private Keys (T1552.004). The attacker exploits the cryptographic weakness of the implementation of ML-DSA to restore the private key of the signature. The result is the signature of arbitrary messages on behalf of the victim: certificates, firmware, authentication tokens.
Supply chain script: Reduce Key Space (T1600.001). Purposeful implementation of vulnerable implementation (substitution of the cryptographic library, the introduction of AABBCC-baga when insurged in open-source) is mapped by T1600.001 (Defense Immunation). All keys generated by a compromised library are restored a priori.
Resource Development. PoC development for specific implementation - Exploits (T1587.004) Identification of a vulnerable library in the purpose infrastructure - Vulnerabilities (T1588.006)
The context of applicability: the attack through software bugs works remotely - it is enough to get two signatures from the target system through any public channel (TLS handshake, a signed JWT update). Attack through side-channel leak requires a micro-architectural or physical channel to the signing system: embedded devices, HSM with co-location, cloud installations with a shared tenant model.
What to check in ML-DSA implementations
Hedged vs Deterministic Signature
According to IETF design (draft-connolly-cflg-cflg-cfl-ds-ssa-security-considerations-02), hedged (randomized) signature is the only safe mode in environments with a risk of fault injection or sidenel. In the hedged mode, fresh randomness rnd is mixed with K and μ for generating p', which prevents a complete repetition of non-ce deficiency at injection and masks the dependence of p' on the secret K. If RNG (rnd = all zeros) failures, the hedged mode correctly degrades to a deterministic - compatibility is maintained without catastrophic loss of security.
Key format
The FIPS 204 defines the compact format of the secret key - 32-byte seed ξ, from which all the extended components (ρ, K, tr, s1, s2, t0) are deterministic. As IETF emphasizes, the seed-format excludes the creation of malformed key: the change in one bit, the seed completely changes the entire extended key, preventing the individual secret components independently. Advanced components can be cached for the duration of signature operations, but you need to protect them in the same way as a seed.
Testing strategy
Standard functional and-nowanswer tests do not catch AABBCC and nonce reuse class bugs. Based on the analysis from postquantum.com, only work reliably:
Cross-imprement comparison - the signing of identical (seed, message) with derandized RNG in two independent implementations with a broken comparison of the result
Statistical profiling of coefficients y - checking for pairs-duplicates, zero patterns, anomalies in distribution
Unspave indexing - purposeful mutation of index variables in bitwise operations, most susceptible to error
Suite Wycheproof, according to Bernstein, does not include a key-deeline ML-DSA test and uses a non-standard interface for signature generation tests, which many implementations will simply miss.
Assessment of the leakage threshold
The formula n*(b−l)/l gives an upper grade of the information capacity of the broken leak, where n is the dimension of the secret, b is the bit of coefficients y lump, l is the number of lost bits per coefficient. This is an estimate from above: the actual number of N signatures depends on the BKZ block size at lattice reduction and a particular salver. Taking into account the results of BP (decrease by one or two orders of magnitude relative to OLS), the practical threshold for ML-DSSA-44 with a leak of one senior bit - dozens of signatures instead of thousands.
ML-DSA signature procedure: anatomy of a vulnerable component
ML-DSA (Module-Lattice-Based Digital Signature Algorithm, FIPS 204) is a post-quantum digital signature standard, formerly known as CRYSTALS-Dilithium. The safety of the scheme stands on two legs: durability of the lattice problem Module-LWE / Module-SIS and the secrecy of ephemeral randomness used at each act of signature. The first leg is intact. The second breaks with even a few bits.
Steps Sign by Algorithm 7 FIPS 204
The signature of the M message passes through the rejection loop, and each element of this cycle is critical to understanding the attack vector:
Calculation mu. Hash Mu = H(tr | | | M', 64) - 64-by-byte digest, including tr (public key hash, binding signature to a specific key) and a formatted message M' (Algorithm 7, FIPS 204). The meaning of tr prevents key substitution: the signature is rigidly attached to a specific public key.
Generation of the genus of the wounds p'. In the hedged mode (default) p' = H(K || rnd || mu, 64), where K is the key secret component, rd - 32 bytes of fresh wounds from RNG. In the deterministic mode, rend = 0x00...00. The p' value is the only source of entropy for the generation of the vector y.
Deploying a mask y via ExpandMask(p', k). The vector y ∈ R_q^l contains coefficients in the range [-(Y1-1), Y1). For ML-DSA-44 Y1 = 2^17 (coefficients are represented by 18 bits with a sign), for ML-DSA-65 and ML-DSA-87 Y1 = 2^19 (20 bits with a sign). The meter κ is incremented at each rejection - fresh values of y at each iteration without rediscovering to the RNG.
Calculation w = A*y and decomposition w into the older (w1) and younger bits. Matrix A - public, generated from p (public key component).
Challenge c = H(mu, w1) - spared by a polynomial in R_q with exactly t zero coefficients (+-1). For ML-DSA-44 t = 39, for ML-DSA-65 t = 49, for ML-DSA-87 t = 60.
Response z = y + c*s1. Here s1 is a secret vector made of private key. This is the central equation of the entire scheme: if the attacker knows y, it calculates c*s1 = z − y and restores s1. That's it. The game is over.
Rejection sampling. If ||z|∞ >= Y1 − beta or if the younger bits w − c*s2 go beyond the permissible boundaries, the signature is rejected, κ increases, the algorithm returns to the generation of the new y.
Why you need a replaying
Without sampling rejection, each published signature z = y + c*s1 would carry statistical information about the secret s1 through distribution y. Rejection sampling - a mechanism from the paradigm Fiat-Shamir with Aborts (Lyubashevsky, 2009) - ensures that the distribution of accepted z is indistinguishable from the one-aligned for the permissible set and does not depend on s1.
The invariant lasts exactly as long as y is completely hidden from the observer. Leakage of partial information about y - through side-channel (energy consumption, cache timing, electromagnetic radiation) or through the software bag - turns public signatures into a system of equations with a secret. And then the most interesting thing begins.
Lock of the ML-DSA randomness as an Integer LWE task
"From Regression to Prior-Aware Inference: Solving the ILWE Family in Randomness Leakage Attacks against ML-DSA"arxiv.org/html/2607.059221v1) formalizes the attack through the lack of lack of sleep as a two-stage procedure:
Stage 1 - design of ILWE-instant from leakage and public signatures. Stage 2 - the decision of the Soldier to restore s1.
The previous works were dug the first stage: how to build a system of equations under different leakage models. The systematic analysis of the influence of the sollver in the second stage was absent.
How the Bit Leak Transforms into Equations
Take one signature with a response z = y + c*s1. Let's say the attacker knows k the older beats of each coefficient. Then y = ? ? , + ε, where ?, is a known approxime, |ε| < 2^(b-k) for b-bit coefficients. The substitution gives:
z − ? = ε + c*s1
The left part is known, c is published as part of the signature, s1 - an unknown secret, ε - limited noise. This is the task of Integer LWE. From N signatures with a leak, a system of N of such ratios is built. Beautiful, isn't it?
Three variants of ILWE
According to the classification of arxiv.org/html/2607.059211v1, three options arise from arxiv.org/html/2607.059211v101, depending on the leakage model:
OILWE (Ordinary ILWE) - a basic model with a known matrix, vector and unknown secret and noise. The standard for calibration of salver.
FS-ILWE (Fiat-Shamir ILWE) - occurs with a broken leak of wound y. The leakage of one bit at the position j of the coefficient y through the equation z = y + c*s1 gives one integer ratio with the secret. The difference from OILWE is the heterogeneity of noise: each equation is tied to a specific position of bit and a specific challenge c, the variance dances from line to string.
CILWE (Concealed ILWE) - occurs when leaking information about zero coefficients y. If side-channel allows you to identify the coefficients y equal to zero (through profiling of power consumption), then for such positions z_i = c_i * s1 - an exact equation without noise. But profiling is not perfect: part of the identified “zeros” are actually non-zero (ceater). With a distress rate above 0.9, the problem becomes sharply complicated - false zeros are converted into gross emissions in the system of equations. And here the choice of the solover decides everything.
Solves key recovery: three classes of approaches
The central result of work on arxiv.org/html/2607.0591v1 is the choice of a solover for the ILWE-tisansion determines the practical feasibility of the attack at least the quality of the leakage itself. Previous studies used ad-hoc salver under specific leakage models without systematic comparison. The authors corrected this.
Regression of the smallest squares (OLS and L1-estimators). Solution in real numbers z* = argmin ||Az − b|| followed by rounding to the nearest integers from the permissible set. The approach is simple and cheaply computationally, but requires a significant stock of equations for correct rounding, especially with high noise. Enough to implement numpy.linalg.lstsq and coordinate rounding - nothing exotic.
Robamost regression (Cauhy) Resistant to emissions. In the context of CILWE, emissions are the same false “zero” coefficients that create gross errors in individual equations. Cauchy-regression with its heavy-tailed profile of the loss function is maintained at a partialment rate above 0.9, where OLS and Huber collapse.
Prior-aware (Belif Propagation, greedy search, hill-climbing). A fundamentally different beast. BP works directly in the final discrete secret space – no rounding of real numbers. For ML-DA, the coefficients s1 are in a small length: at n = 2 it is {−2, −1, 0, 1, 2, 2}, at n = 4 - {−4, ..., 4}. BP builds a graph (factor graph), where each node-variable corresponds to the coefficient s1, and each factor knot - one equation from the ILWE-instanus. A priori knowledge of the discreteness and limitation of coefficients is sewn directly into messages that race the graph.
Results: BP reduces the threshold of attack on orders
A decrease of one or two orders of magnitude (10-100 *) in the number of necessary informative relationships is the boundary between "theoretically interesting" and "can be made with your hands." If the broken leak through side-channel gives one informative bit for signature, OLS will require a thousand observations, and BP - dozens. BP also expands the range of attacked positions: OLS works only with a leak of the older bits (high signal/noise ratio), BP pulls the secret when leaking younger positions - where OLS is already on.
Side-channel attacks require physical or micro-architectural access to the sign system. Bernstein’s work (crpress.to/papers/mldsa-20260601.pdf) hits on the other hand: software errors in the implementations of ML-DSSA, leading to a complete (non-partial) leak or structural damage to the wound-wise.
AABBCC bug: paired coefficients in mask y
Error in the dispensing code of polynomial coefficients, at which the coefficients are duplicated by pairs: y = (a, a, b, b, c, c, c, ...) instead (a, b, c, d, e, f, ...). The defect occurs with improper indexation in the chain of bit operations - a typical situation when a copy-paste-modify of one index expression leads to a doubling. According to the analysis on postquantum.com, Bernstein showed that in the OpenSSL implementation of ML-DSA, the bitwise operation chain contains a place where replacing one subtraction with a beaten AND would reset every second coefficient (pattern A0B0C0) - an equally exploited version.
Bernstein attack: from the public key and two signatures, a system of linear equations over the ring of polynomials R_q is built, the solution of which gives four secret polynomial s0, s1, s2, s3. The demonstration worked on 50 consecutively generated random keys - without misfires.
And here’s what’s really unpleasant: signatures with AABBCC-baga are Valid. They undergo standard verification, known-answer tests (if the tests are generated by code with the same bug) and cross-library interop inspections. Both official Dilithium 1.0 in 2017 contained a bug of this class, found only in cross-imprelation comparison with the derandized RNG. Two out of two are 100%.
Nonce reuse: ML-DSA-analogue PS3 ECDSA
The second attack exploits the reuse of the y vector in two signatures - a direct analogue nonce reuse in ECDSA (Sony PlayStation 3, 2010), adapted to the ring of polynomials.
If (z1, c1) and (z2, c2) are signed with the same y, subtraction gives:
z1 - z2 = (c1 - c2) * s1
The secret s1 is restored by polynomial division in R_q provided verbitation (c1 - c2). For random ML-DSA diamonds with τ non-zero coefficients +-1, the difference has coefficients in {−2, −2, −1, 1, 2, 2} and reversible in R_q = Z_q[x]/(x^256 + 1) with a high probability.
Python:
SageMath, q = 8380417 (ML-DSA-44)
Rq = PolynomialRing(GF(8380417), 'x').quotient('x^256 + 1')
delta_z = Rq(z1 - z2)
delta_c = Rq(c1 - c2)
s1_recovered = delta_z * delta_c.inverse_of_unit()
According to postquantum.com, the attack triggers in about 80% of cases out of two signatures; additional signatures with the same nonce cover the rest. Repeating nonce can occur due to an error in calculating the length of the input data of the hash function or truncation of the hash-entrances - bugs, invisible to standard functional tests. The tests are green, the key is in the hands of the attacker.
Forecast of scale: 25% of libraries with critical bug
Bernstein is building a statistical model based on empirical data Blessing, Specter and Wetzner (2021): 312 CVE in eight large cryptographic libraries for 2010-2020, 0.45-1.19 CVE on 1000 rows of added code, the average used lifetime of 5.13. Extrapolation from cr.yp.to/papers/mlds-20260601.pdf: 50 ML-DSA * 2000-4000 lines of specific code = 100 000-200 000 lines. With the observed historical figures - about 100 vulnerabilities. With a share of critical ~1/8, about 25% of libraries will release the first release with at least one vulnerability of the “forgery signature” class.
For comparison: for 10+ years of existence of about 100 libraries Ed25519 recorded 1-2 critical vulnerabilities. The difference is in order.
Additional evidence: an analysis on postquantum.com refers to the work of Kobeissi ("Verification Theatre"), which has found 13 vulnerabilities in Cryspen's libcroux - a library with a declared formal verification used by Firefox and OpenSSH. Four bugs sat inside the perimeter of formal verification, including the incorrect multiplication specification in ML-DSA, which made the axiomatized AVX2-proofs untenable. Formally verified, and the bug - here he is.
Operational context: mapping on MITRE ATT&CK
Attacks on the randomness of ML-DSA form a chain through several techniques.
Main chain: Exploitation for Credential Access (T1212) -> Private Keys (T1552.004). The attacker exploits the cryptographic weakness of the implementation of ML-DSA to restore the private key of the signature. The result is the signature of arbitrary messages on behalf of the victim: certificates, firmware, authentication tokens.
Supply chain script: Reduce Key Space (T1600.001). Purposeful implementation of vulnerable implementation (substitution of the cryptographic library, the introduction of AABBCC-baga when insurged in open-source) is mapped by T1600.001 (Defense Immunation). All keys generated by a compromised library are restored a priori.
Resource Development. PoC development for specific implementation - Exploits (T1587.004) Identification of a vulnerable library in the purpose infrastructure - Vulnerabilities (T1588.006)
The context of applicability: the attack through software bugs works remotely - it is enough to get two signatures from the target system through any public channel (TLS handshake, a signed JWT update). Attack through side-channel leak requires a micro-architectural or physical channel to the signing system: embedded devices, HSM with co-location, cloud installations with a shared tenant model.
What to check in ML-DSA implementations
Hedged vs Deterministic Signature
According to IETF design (draft-connolly-cflg-cflg-cfl-ds-ssa-security-considerations-02), hedged (randomized) signature is the only safe mode in environments with a risk of fault injection or sidenel. In the hedged mode, fresh randomness rnd is mixed with K and μ for generating p', which prevents a complete repetition of non-ce deficiency at injection and masks the dependence of p' on the secret K. If RNG (rnd = all zeros) failures, the hedged mode correctly degrades to a deterministic - compatibility is maintained without catastrophic loss of security.
Key format
The FIPS 204 defines the compact format of the secret key - 32-byte seed ξ, from which all the extended components (ρ, K, tr, s1, s2, t0) are deterministic. As IETF emphasizes, the seed-format excludes the creation of malformed key: the change in one bit, the seed completely changes the entire extended key, preventing the individual secret components independently. Advanced components can be cached for the duration of signature operations, but you need to protect them in the same way as a seed.
Testing strategy
Standard functional and-nowanswer tests do not catch AABBCC and nonce reuse class bugs. Based on the analysis from postquantum.com, only work reliably:
Cross-imprement comparison - the signing of identical (seed, message) with derandized RNG in two independent implementations with a broken comparison of the result
Statistical profiling of coefficients y - checking for pairs-duplicates, zero patterns, anomalies in distribution
Unspave indexing - purposeful mutation of index variables in bitwise operations, most susceptible to error
Suite Wycheproof, according to Bernstein, does not include a key-deeline ML-DSA test and uses a non-standard interface for signature generation tests, which many implementations will simply miss.
Assessment of the leakage threshold
The formula n*(b−l)/l gives an upper grade of the information capacity of the broken leak, where n is the dimension of the secret, b is the bit of coefficients y lump, l is the number of lost bits per coefficient. This is an estimate from above: the actual number of N signatures depends on the BKZ block size at lattice reduction and a particular salver. Taking into account the results of BP (decrease by one or two orders of magnitude relative to OLS), the practical threshold for ML-DSSA-44 with a leak of one senior bit - dozens of signatures instead of thousands.
