Too Much Crypto explained
An LLM's attempt to explain my controversial cryptography paper
After being asked for the ℵ₀th time what my “controversial” 2019 paper Too Much Crypto was about, and inspired by the LLM blogging experiments of my friend Matt, I wondered whether GPT 5.5 could explain it to non-cryptographers. After a few iterations and my feedback it produced the text below, which I heavily edited for clarity, tone, accuracy, and emphasis.
GPT 5.5 on Too Much Crypto
Security is rarely free. More controls usually means more computation, more energy consumption, more latency, and more expensive hardware. Cryptography isn’t much different, and like every engineering discipline it has to balance cost against benefit. Cryptography often forgets this principle.
The reason is understandable. Nobody wants to design the algorithm that gets broken. If adding a few extra rounds makes an attack even less likely, why not?
The problem is that round numbers are never adjusted to the reality of cryptanalysis progress, or lack thereof. After years of analysis, algorithms retain increasingly overgenerous safety margins that reflect their designers’ initial—warranted—conservatism.
The paper Too Much Crypto asks a simple question: have we been too conservative?
Rather than speculating, the paper looks at decades of cryptanalysis of major symmetric primitives. The results are surprisingly consistent. While attacks steadily improve, the distance between the best known attacks and the parameters used in practice often remains huge.
ChaCha is perhaps the clearest example. The version deployed almost everywhere, ChaCha20, uses twenty rounds. Yet the best cryptanalysis remains far from threatening the full design, and even reduced-round variants appear remarkably robust. One naturally wonders whether twenty rounds were ever really necessary, or whether a smaller number could have delivered essentially the same practical security at a lower cost.
Keccak, the algorithm behind SHA-3, tells a similar story. Its permutation was designed with an extremely comfortable security margin—and JP is in part responsible for that—and years of cryptanalysis have only reinforced confidence in the design. This robustness is good news, but it also raises the question of whether some applications are paying for much more security than they actually need.
The argument is not that cryptographers made mistakes. Quite the opposite: conservative design has served the field exceptionally well.
But conservatism has a cost.
A useful comparison is civil engineering. Bridges are built with safety margins because unexpected events happen. Nobody would advocate building a bridge that barely supports its advertised load. On the other hand, designing every highway bridge to support a fleet of aircraft carriers would not be considered good engineering.
Cryptography should be no different.
This philosophy influenced the design of BLAKE3. Instead of simply inheriting the conservative parameters of earlier hash functions, BLAKE3 takes advantage of what decades of cryptanalysis have taught us. Its compression function uses fewer rounds, while its tree structure exploits the parallelism of modern processors to achieve dramatically better performance. The result is a hash function that is significantly faster than SHA-3 or BLAKE2.
Despite not being a NIST standard, BLAKE3 has been adopted in projects such as LLVM, Rust’s Cargo, OpenZFS, CCache, Cloudflare services, blockchains, ZK proof systems, and many other performance-critical systems. The attraction is straightforward: if a design can provide ample security at a fraction of the computational cost, that is simply good engineering.
The point of Too Much Crypto is therefore not that modern cryptography is “too secure”. Security margins are valuable, and predicting future attacks is notoriously difficult.
The point is that security should be treated like every other engineering requirement. Once a design is comfortably beyond any realistic attack, adding another large safety margin should require justification rather than being the default choice. Unhealthy paranoia isn’t good risk management, and it isn’t good cryptographic engineering either. Sometimes, enough crypto is enough.
The controversial claim is not that cryptographers are too cautious, but that the history of cryptanalysis suggests they may be much more cautious than the evidence warrants.