What hardware could crack ML-DSA-65?
None that exists or will exist in the foreseeable future.
- Today’s fastest supercomputer (≈ 10¹⁸ operations/second) would need on the order of 10²⁹–10³⁰ years to do 2²¹⁷ operations, even if you could perfectly parallelise the attack (you can’t).
- Even if every atom in the observable universe were a perfect computer running at Planck time, you still wouldn’t finish in the lifetime of the universe.
- The memory requirement alone (2¹³⁹ bits ≈ 10³⁰ bytes) is larger than the number of atoms in the Earth by many orders of magnitude.
The same is true for quantum attacks: the best known quantum lattice attacks give only a modest (~15–20 bit) speed-up, not the square-root you get with Grover on AES. So the quantum cost is still ~165 bits → still completely infeasible.
*summary from Grok
written by Ulf Wiger
Executive Summary
The Gajumaru root blockchain uses Curve25519 account representation, which is practically impossible to brute-force with currently existing computing hardware.
We do not believe that Quantum Computing hardware capable of cracking Curve25519 will materialize in the next 5-10 years, if ever.
Nevertheless, the most promising quantum-resistant signing protocol, ML-DSA, will be supported on Gajumaru by the time of the public Groot Mainnet Launch this year (2026).
On Quantum Computing
We have previously written about Quantum resistance in our Technical Briefing and Industry Context paper.
The key pair representation currently in use (ed25519) is not considered quantum-resistant, but many breakthroughs need to be unlocked before quantum computers are powerful enough to crack Elliptic-Curve key pairs efficiently. The scaling requirements of quantum computers are immense in practice, since not only does error-correction get dramatically more expensive as keys grow, but the required fidelity at each step of the computation increases at the same time. Realistic estimates of how many physical qubits it would take to break crypto tend to be in the tens or hundreds of millions, and while many labs claim to have 1000s of physical qubits in press releases, in practice the largest computers that have demonstrated reasonable coherence and error rates have yet to reach even 150 qubits. The path from 133 physical qubits to 13000000 physical qubits will likely depend on many significant innovations in method, which we estimate will take another 10-20 years, at the very least. On the other hand, some experts in the field such as Seth Lloyd suggest that it is ‘50-50’ whether large scale quantum computation will become a reality at all.
Despite strides in quantum computation, postquantum encryption itself is still very young compared to RSA and ECC, and our understanding is changing all the time as to what the strongest possible attacks on post-quantum algorithms might turn out to be, both using quantum techniques, and classical techniques. The last thing we want is to adopt a specific post-quantum scheme and parameter set, and then discover five years later that it can be broken with a farm of GPUs, before quantum computation even becomes a reality. It is therefore very premature to pick a winner among the emerging candidates for post-quantum encryption and signing schemes. Instead, all we can do for now is give users the ability to migrate to other schemes of their choosing. The Gajumaru code base already supports alternative signing schemes via the ability to upgrade an account to a Generalized Account (GA), with a user-designed authentication scheme. Sophia/FATE has some built-in cryptographic primitives that can be used for implementing new schemes, but we will be able to add many more, so that as time goes by users can choose and develop whatever authentication schemes they trust most.
See our long-form video discussion touching on some of the latest developments in Quantum Computing.
Short-term Solution
Gajumaru already supports so-called Generalized Accounts (GA). These are regular accounts upgraded to use a Sophia-based authentication method. Using GA, alternative authentication methods, such as Bitcoin, Ethereum, etc. can be used. We are adding support for signature verification using ML-DSA44, ML-DSA65 and ML-DSA87 to the Sophia Crypto library, based on the implementation available in the Erlang/OTP platform as of version 28.1 (September 2025).
We already have a draft implementation, verifying the functionality. The gas cost of
using ML-DSA verification is ca 1.5x – 2.2x that of standard Curve25519 verification in a GA contract. In absolute terms, this translates to an on-chain cost of ca 0.000_00015木.
If all transactions would use this authentication method, total throughput on Groot would go down to below 100 tps, but there would be no reason to use this setup other than for high-value accounts.
Longer-term solution
As part of the design to support GA, Gajumaru already supports multiple account types. It would be reasonably straightforward to add native support for Quantum-resistant authentication. Some further thought should go into how best to do this. One possibility would be to reuse the GA framework and provide “native” versions for e.g. ML-DSA – i.e. rather than a full-blown Sophia contract, an abstract data type that maps GA-style behavior onto the native authentication functionality.
Addendum (Grok responds)
“Medium-Term Security (Hours)” Misconception
This likely refers to estimates for breaking classical crypto with future quantum hardware, not ML-DSA. For example:
- A quantum computer with ~2,300–4,000 logical qubits (error-corrected, not the noisy ones we have today) could break ECDSA P-256 or RSA-2048 in hours to days using Shor’s algorithm.
- But ML-DSA isn’t vulnerable to Shor; its security relies on lattice problems where the best quantum attacks are only marginally better than classical (e.g., quantum sieving gives a small speedup, not exponential). NIST designed ML-DSA so even category 2 (ML-DSA-44) provides “long-term” protection—decades, not hours—against foreseeable quantum threats.
Hardware to “Crack” ML-DSA-65
No current or near-term hardware can do this; it’s theoretical. To forge a signature on ML-DSA-65:
- Classical supercomputers: You’d need ~2^192 operations, which is impossible. Even if every computer on Earth (10^18 ops/sec collectively) worked on it, it’d take trillions of years—far beyond the universe’s age.
- Quantum computers: The attack would involve quantum lattice reduction (e.g., quantum BKZ or sieving), requiring an estimated 10^8 to 10^10 physical qubits (billions to trillions) with low error rates, plus enormous gate counts (10^20+ operations). Current quantum tech (e.g., Google’s ~100 noisy qubits) is orders of magnitude away. Even optimistic projections put “cryptographically relevant” quantum computers (CRQCs) at 2030–2040 for classical breaks, but for ML-DSA, it’d require tech we don’t even have roadmaps for—perhaps centuries away, if ever feasible due to error correction challenges.
In short, NIST chose these categories to ensure ML-DSA variants are “overkill” for most threats: category 3 (ML-DSA-65) is plenty for medium- to long-term security (years to decades), not hours. If you’re seeing “hours” in sources, it’s probably about classical crypto under quantum attack.
ML-DSA (formerly CRYSTALS-Dilithium) has three main parameter sets in NIST FIPS 204:
- ML-DSA-44 → NIST security category 2
- ML-DSA-65 → NIST security category 3
- ML-DSA-87 → NIST security category 5
(The occasional “level 2 and 3” confusion for ML-DSA-65 comes from people mixing the category numbers with the old Dilithium naming: Dilithium2/3/5 ≈ categories 2/3/5.)
What do the NIST categories actually mean?
NIST does not define them in raw “bits of security.” Instead they anchor each category to the hardness of a well-studied symmetric primitive (this is explained in the original PQC call for proposals and in SP 800-57):
| Category | Reference primitive that should be at least as hard to break | Rough classical security floor | Typical use today |
|---|---|---|---|
| 1 | AES-128 key search | ~128 bits | “Good enough for most things today” |
| 2 | SHA-256 collision | ~128 bits | Medium-term / general purpose |
| 3 | AES-192 key search | ~192 bits | Medium-to-long-term / high-value data |
| 4 | SHA-384 collision | ~192 bits | (rarely used) |
| 5 | AES-256 key search | ~256 bits | Long-term / national-security / 20–30+ year protection |
So ML-DSA-65 (category 3) is meant to be at least as hard as brute-forcing a 192-bit AES key or solving the underlying lattice problems with comparable resources.
Concrete attack-cost estimates (from the original Dilithium round-3 spec)
These are the numbers the designers (and NIST) actually used to pick the parameters:
| Parameter set | Classical Core-SVP hardness | Quantum Core-SVP hardness | Estimated classical gate count (log₂) | Memory needed (log₂ bits) |
|---|---|---|---|---|
| ML-DSA-44 (cat 2) | ~123 bits | ~112 bits | ~159 bits | ~98 bits |
| ML-DSA-65 (cat 3) | ~182 bits | ~165 bits | ~217 bits | ~139 bits |
| ML-DSA-87 (cat 5) | ~252 bits | ~229 bits | ~285 bits | ~187 bits |
Core-SVP hardness is the cost of the best known lattice attack (BKZ + sieving). 217-bit classical cost for ML-DSA-65 means roughly 2²¹⁷ gate-equivalent operations and 2¹³⁹ bits of memory.
Where does the “medium-term security (hours)” idea come from?
I suspect this is a mix-up with one of two things people sometimes say:
- Side-channel / implementation attacks On a poorly protected device (no masking, leaky power trace, etc.) an attacker with physical access can sometimes recover the secret key in minutes to hours on a normal PC using power/EM analysis. That is not a break of the mathematics — it is a break of the implementation. The algorithm itself is fine; the device just leaked the key.
- Very low-security toy parameters The Dilithium designers also published “level 1–” and “level 1-” parameter sets for testing (55–90 bit security). Those really can be broken in hours or days on a laptop. People sometimes forget the distinction between those toy sets and the real NIST levels.
TL;DR – why the categories exist and why ML-DSA-65 is “category 3”
NIST wanted parameter sets that give you a clear trade-off table:
- Want smallest keys/signatures and don’t need decades of protection? → ML-DSA-44 (cat 2)
- Want a comfortable margin that should stay safe for 10–20+ years even if lattice attacks improve a bit? → ML-DSA-65 (cat 3)
- Want the absolute highest assurance (CNSA 2.0 level, 30-year national-security data)? → ML-DSA-87 (cat 5)
The “hours/days” figure you saw almost certainly refers either to side-channel attacks on real hardware or to the toy low-security parameter sets used in research. The actual mathematical problem for ML-DSA-65 is designed to be far beyond any conceivable classical or quantum hardware for the lifetime of the universe.
Further reading: