AI Cryptanalysis: Green's Worst Case vs Schneier's Over-Engineering Bet

What was actually said

On 14 October 2026, Bruce Schneier pointed readers to what he called a 'rather pessimistic series of posts' by Matthew Green. Green's thesis, as Schneier summarises it, is that AI systems could vastly outperform humans at cryptanalysis of both symmetric and public-key ciphers. Schneier says he is more optimistic, because he has 'stronger faith in the over-engineering cryptographers tend to do', and that he is writing the argument up in more detail.

That is the whole of Schneier's post so far. It is a signpost, not a rebuttal, so treat the detailed counter-argument as pending.

How pessimistic is 'pessimistic'?

One of Green's posts, quoted on Simon Willison's weblog, puts numbers on the worst case. He gives a 1% chance that 'we live in Minicrypt', Russell Impagliazzo's hypothetical world in which public-key encryption is impossible. He gives a 15% chance that 'we functionally lose confidence in our existing public-key encryption algorithms'. He describes himself as 'the goofball who raises worst-case possibilities'.

His operational point matters more than the percentages. In his words, 'You only recover from a surprise like this if you do the preparation in advance.' Willison's summary adds Green's argument that AI can produce surprises much faster than humans can replace standards.

Why the two views are less opposed than they look

Schneier's optimism rests on engineering margin: the idea that deployed primitives carry slack beyond the best known attacks. Green's concern is the speed of surprise and the cost of replacing standardised algorithms. Both can be true at once. A large margin makes a sudden break less likely, while a slow replacement process makes any break that does happen more painful.

Neither source reports an actual AI-found weakness in a standard cipher. This is a debate about risk estimates, and it should be read that way. Be wary of viral claims that go further; we have not verified any such claim and do not rely on one here.

What practitioners should do now

You do not need to pick a side to act on Green's preparation point. The work is the same crypto-agility groundwork that post-quantum migration already demands:

• Inventory where public-key and symmetric cryptography is used: TLS, VPNs, code signing, device identity, stored data, and third-party SDKs.
• Separate algorithm choice from application logic, so a primitive can be swapped through configuration or a library update rather than a rewrite.
• Prioritise long-lived assets, such as firmware signing keys and archived data, where replacement takes years and not weeks.
• Track vendor and standards-body guidance, and avoid abandoning well-reviewed protocols on the strength of speculation.

What to watch

Schneier's promised longer piece should show how far he thinks the over-engineering margin extends and for which primitives. Until a concrete result appears, the sound position is uncertainty with a plan: neither assuming that existing cryptography is safe indefinitely nor treating a worst-case estimate as a prediction.