JP Aumasson on Quantum Risk, AI Attacks and Too Much Crypto

JP Aumasson now takes quantum risk more seriously than he did two years ago, when he did not expect a quantum computer to break RSA-2048 in his lifetime. He characterized the chance as low but the impact as high, floating probabilities such as 1 in 1,000 or 1 in 10,000 as possibilities, not firm estimates. He viewed Google’s recent announcement as incremental and said it did not materially change the risk. Its assessment supports upgrading older systems by 2029; it does not mean a cryptographically capable quantum computer will exist by then.

Recent RSA factorizations do not show that production-size RSA is close to being broken. RSA-260, an 862-bit number, was factored with the general number field sieve using an AI company’s GPU infrastructure, not by AI itself; Steve Weiss also published a factorization of RSA-896 using Anthropic GPU capacity and idle time. Aumasson said AI may help tune factoring parameters or optimize implementations, but the precise classical complexity of factoring remains unknown.

Aumasson sees more scope for AI-assisted attacks on asymmetric cryptography than on AES, SHA-3 or Blake3. He argued that the latter’s mix of operations is designed to leave no useful mathematical structure for models to exploit, and that a breakthrough against them would require major progress in complexity theory and a trapdoor function. By contrast, the more explicit mathematical structure of asymmetric systems gives AI more to analyze. China’s commercial cryptography competition, which publishes submissions, specifications and source code, offers researchers a large set of candidates to examine.

In his own test of that competition’s submissions, Aumasson said an LLM assessed about 10 candidates and produced an attack roughly 10 minutes after he asked it to break the ones it had judged weakest. He also said Markoos Arenon used AI models to break 14 of an estimated 50–60 submissions; a site he cited listed 142 active findings across 81 reports, including 49 design findings. Some attacks may not completely break their targets. Improved attacks on Hoke HAAWK also led its designers to withdraw it from the NIST signature-standard competition.

Aumasson said many published AI-generated cryptanalytic attacks appear valid, not hallucinated. He described finding a total break after examining a 200-page cipher paper: some ciphertexts could be produced by encryption but could not be decrypted. In another case, he verified that a cipher’s LFSR feedback polynomial was neither primitive nor irreducible. AI can uncover basic flaws researchers might once have found themselves, but attacks requiring time-consuming empirical statistics may be a poor fit. He expects models to help assess security, clarify attack limits and reduce effort, while doubting they would outperform a top-five-percent cryptographer at cipher design, which requires balancing security, speed and simplicity.

Hash security is under renewed scrutiny because hashes are used in post-quantum signatures and zero-knowledge circuits. Aumasson said research found Poseidon, particularly Poseidon2, less secure than many expected, with reported constant-input, constant-output attacks that find a message connecting fixed values and bypass some foundational arguments. He does not think these attacks meaningfully affect current Poseidon systems, though he is not fully certain. More efficient proof systems for bitwise operations, including Flock, have also made classical hashes such as Blake3 practical in zero-knowledge applications—a shift Justin Drake described as moving from “snark-friendly hash functions” to “hash-friendly snarks.” Aumasson disclosed that he co-designed Blake3 and is biased toward it, while acknowledging concerns that it may use too few rounds.

Aumasson’s “Too Much Crypto” argument is that Blake2, Blake3, ChaCha20 and Keccak use more rounds than necessary. In a paper posted in December 2019 and presented at RWC in 2020, he noted that Keccak increased from 18 to 24 rounds even though the best attacks reach roughly 3–5 rounds and about 10 might suffice. He said Keccak hashing and random generation consume substantial CPU time in ML-KEM and ML-DSA, and that subsequent history has not disproved his argument.