On July 28, Anthropic's Frontier Red Team published research showing that its frontier model, Claude Mythos Preview, found a cryptographic weakness that had survived two years of expert human review. The target was HAWK, a digital signature scheme built to resist quantum computers and, at the time, one of the remaining lattice-based candidates in NIST's post-quantum signature standardization process. Mythos found the flaw in about 60 hours. According to a subsequent post from a HAWK co-author to NIST's public mailing list, reported by several outlets, the HAWK team withdrew the scheme from consideration shortly after.
This is worth pausing on, because most of the conversation about quantum risk, including the conversation we have been having with customers all year, has been about a single countdown: the day a cryptographically relevant quantum computer comes online and starts decrypting everything an adversary harvested years earlier. That countdown is real. But last week's news pointed to a second clock, one that has nothing to do with quantum computers at all.
Two Clocks, Not One
The first clock is the one everyone has been watching. Nation-state adversaries are already intercepting and archiving encrypted traffic today, betting that a future quantum computer will let them decrypt it later. This is the Harvest-Now-Decrypt-Later (HNDL) problem, and it is the reason NIST, AWS, and the rest of the industry have spent the last several years pushing organizations toward post-quantum algorithms like ML-KEM.
The second clock started moving faster last week. Anthropic's researchers gave Mythos access to Python, a math library called Sage, and published cryptographic literature, then let it work through the problem largely on its own. It found a structural symmetry in HAWK's underlying lattice that no human reviewer had used in two years of scrutiny and used it to cut the cost of recovering a secret key by roughly 67 million times for the smallest configuration. In a separate result, it invented a technique that sped up an attack on a reduced-round version of AES-128 by 200 to 800 times.
To be precise about what did and did not happen: this was a signature scheme, not the key-exchange standard most organizations are actually deploying. The AES result touched a seven-round research variant, not the full ten-round cipher protecting production traffic and still assumes an attacker can obtain roughly 2 to the 105th chosen plaintexts, a volume with no practical real-world equivalent. Anthropic disclosed the HAWK finding to the scheme's authors in June and coordinated public release with NIST's mailing list and stated explicitly that the attack is specific to HAWK and does not extend to other NIST post-quantum candidates or to lattice-based cryptography generally. The same research noted only marginal progress, under a tenfold improvement, against Poseidon, a different hash function used in zero-knowledge protocols, and similarly limited results against Salsa20 and SHA-1. Nobody's HTTPS session broke last week.
What did happen is that a task requiring two years of specialist attention took 60 hours and about $100,000 in compute, run mostly by a model rather than a person.
That is the part that should change how organizations think about cryptographic risk, independent of whatever a quantum computer eventually does.
Why This Changes the Math on Crypto-Agility
The standard advice on post-quantum readiness has been to inventory your cryptographic assets, adopt NIST-approved algorithms like ML-KEM, and move on with a multi-year migration timeline. That advice is still correct. But it assumed the algorithms themselves would stay put for a while once you adopted them. HAWK had cleared two rounds of the most rigorous public review process in cryptography and still had a flaw waiting for the right kind of scrutiny. If a frontier AI model can supply that scrutiny in days instead of years, the useful lifespan of any single algorithm becomes a moving target.
This is exactly the argument for crypto-agility: the ability to swap a cryptographic algorithm without re-architecting the systems that depend on it. Crypto-agility used to be a hedge against a slow-moving, largely theoretical risk. It is now a hedge against a fast-moving, empirically demonstrated one.
Where Architecture Does What Algorithms Cannot
This is also where I think the industry's framing has been incomplete. Post-quantum cryptography, and now AI-resistant cryptography, both try to answer the same question: how do we make the mathematics harder to break? That is necessary work, and Dispersive® Stealth Networking is moving its own key exchange to ML-KEM as part of it. But it is not the only lever available, and security engineers have had a name for the alternative for decades: defense in depth. No single control, however strong, should be the only thing standing between an adversary and the data. The moment one layer weakens, whether through a quantum computer or a lattice symmetry an AI model finds in 60 hours, the system should still hold because it never depended on that one layer alone.
Dispersive's architecture is one expression of that principle. Communications are split into independently encrypted segments and distributed dynamically across multiple paths, reassembled only at the intended destination. An adversary who wants to exploit a future weakness in any encryption algorithm first has to solve a much older problem. Using the same framing we apply in our own quantum-readiness research, that adversary now has to:
- Discover every path a given communication traveled.
- Identify every segment belonging to that specific session.
- Capture sufficient segments from multiple locations at once.
- Preserve the timing relationships between segments despite differing network latencies.
- Correctly reconstruct the original communication from the pieces.
- Preserve that reconstruction for a future decryption attempt, whatever eventually supplies it.
- Post-quantum migration to algorithms like ML-KEM remains necessary. Nothing about last week's news changes that.
- Crypto-agility, the ability to swap algorithms without rebuilding your network, just became a nearer-term requirement rather than a long-term hedge.
- Architectural approaches that reduce reliance on any single algorithm's strength, including segmentation and multi-path transport, are no longer a nice-to-have layered on top of cryptography. They are an independent line of defense against a category of risk that cryptography alone cannot fully answer.
Failure at any one of those steps means there is nothing coherent left to decrypt later, regardless of what breaks the underlying cipher. That is a structural obstacle, not a mathematical one, and it does not care whether the eventual attacker is a quantum computer, a nation-state cryptanalysis team, or a frontier AI model finding symmetries nobody else thought to look for.
Put differently: strengthening the lock on the door matters, and we are doing that work. But defense in depth also means making sure there is no single door.
Dispersive Stealth Networking is NSA/FIPS 140-3 compliant today, independent of anything discussed above. That baseline matters for the algorithm side of this conversation. The architectural resilience I am describing here is a separate, additional layer on top of it, not a substitute for cryptographic rigor.
The Practical Takeaway
The Anthropic team deserves credit for disclosing this responsibly and building tools, including a new benchmark called CryptanalysisBench, to help the rest of the field study it systematically rather than react to headlines. We will be watching that work closely. The organizations that come out ahead here will be the ones that stop asking whether their encryption is strong enough today and start asking how quickly they could adapt if it turned out not to be.
Get a Crypto-Agility Assessment
If an algorithm you depend on turned out weaker than assumed, from quantum computing or AI cryptanalysis, would your network need to be rebuilt or just reconfigured? Our team can help you find out.
📞 Book a discovery session with Dispersive: www.dispersive.io
Header image courtesy of Elchinator from Pixabay.
