Fiat-Shamir attacks are not misuse — the protocol itself is insecure
Protocols actually deployed, like GKR, can be proven to accept false statements under standard Fiat-Shamir; this is not an implementation oversight, it is a problem with the transform itself.
The video won't play here. Listen to the audio instead:
The argument · tap a timestamp to hear it
A hand-built counterexample fooled everyone
Before Ron's work with Lev and Dmitry, the field already knew there were examples of ‘secure interactive protocol + Fiat-Shamir = total collapse’, but those protocols were deliberately constructed by theorists to show Fiat-Shamir does not always hold, and they looked extremely unnatural. The typical industry reaction was ‘our real protocols would never do something that stupid’. Ron himself had years earlier built a semi-artificial example in which one component was fictional, which kept him doubtful about security. The turning point was the bug bounty the Ethereum Foundation set up while studying Poseidon's security; the final tier of the reward was ‘launch a Fiat-Shamir attack on any protocol of your choice using Poseidon’. Ron did not go for the prize; instead he suggested changing the terms to ‘non-fictional protocols’, which directly prompted the sweep of real deployed protocols.
— Ron RothblumGKR's data-saving property became the attack surface
What actually got broken was the GKR protocol, widely used in practice; Polyhedra's Expander system uses it. The attack exploits a real property of GKR: it allows ‘recording less data’, apparently recording less but implicitly confirming that data — which is exactly why people want to use GKR, and exactly what makes the attack possible. The key condition for the attack to hold is that the depth of the circuit being proven (the scheme) must be at least as deep as the depth of the hash function used by Fiat-Shamir, and implementations at the time placed no restriction on this. Polyhedra made changes and paid the bounty.
— Ron RothblumThe mitigation is just to deepen the hash chain
The mitigation is plain: make the hash function slightly deeper than the circuit being proven. Concretely, chain several Poseidons together — do 10 Poseidons and the circuit is naturally 10 times deeper, and there is no expected trick to get around it. That is what Polyhedra changed. But Ron stresses clearly that this is only a mitigation — we cannot demonstrate an attack, but we also do not know that an attack truly does not exist. This differs from the usual Fiat-Shamir vulnerabilities: those are typically misuse in practice, such as forgetting to include some message the prover sent in the hash; this one is insecure even when Fiat-Shamir is used correctly according to spec.
— Ron RothblumDiagonalization: make the program take itself as input
Ron gives an extremely artificial protocol to illustrate the attack principle: the prover sends a message M, the verifier runs M as program code with M itself as input, waits for it to output a 100-bit string, then compares it against 100 random bits and accepts only if they match. Interactively this protocol is essentially impossible to accept, because once M is sent, M(M) is fully determined, and the probability of hitting a 100-bit random number is 2 to the minus 100. But once Fiat-Shamir is applied, the random number becomes H(M), and the prover only needs to find an M satisfying M(M) = H(M) — take M to be the hash function H itself, since M(M) = H(H) = H(M). This kind of trick is called diagonalization; in essence it forces a program to nest itself.
— Ron RothblumSwap out Reed-Solomon and you can swap in speed
Blaze, Tensor Switch and Bolt are all hash-based polynomial commitment schemes, and they share a reliance on error-correcting codes. FRI, STIR and WHIR are all built on Reed-Solomon codes, while these three projects try to trade a better error-correcting code for a better PCS. Bolt uses a code called a sketched code: first take a non-cryptographic ‘digest’ of the message, apply Reed-Solomon encoding only to the digest, and the overall codeword = the encoding of the digest + the original message. The benefit is that Reed-Solomon acts only on data about one tenth the size, cutting encoding cost by an order of magnitude. The cost may be a larger proof size, but in settings where not everyone needs to read the proof, proving time matters more. Ron points out that this line focuses on proving efficiency, while the WHIR line focuses on verification and proof size, and the two can coexist through proof composition: use Bolt to get an extremely fast proof, then recursively prove its verifier with WHIR to inherit high-quality verification.
— Ron RothblumVeil gives hash-based proofs zero knowledge for free
Veil is a method for making a certain class of hash-based proof systems zero-knowledge (Ron dislikes the name ZK ZK). Traditionally, implementing zero-knowledge in SP1 means recursively composing a succinct proof with Groth16, but Groth16 is not post-quantum secure. What Veil wants is a native, hash-based zero-knowledge scheme. Existing proofs of concept show that the resource overhead is fairly small in both proving time and proof size, and the plan is to implement it directly in SP1.
— Ron RothblumFlock let Ethereum dare to abandon Poseidon
Flock is a proof system for batch verification of Boolean circuits, developed by Ron with Benedict and their student William Lang, pushing the theory toward practicality. Ron believes it brought the industry a ‘second spring’, and more importantly spawned a large number of new ideas and follow-up research. One direct consequence is that the Ethereum Foundation decided to move from Poseidon to some kind of Boolean hash. Before Flock appeared, it was not clear this could be done efficiently; Flock, together with the important earlier influence of Binius, proved it feasible. Ron attributes the shift to two things happening at once: first, the new attacks shook people's confidence in Poseidon, and second, what would have seemed surprising a year earlier, traditional hash functions turned out to be quite efficient to use in proofs.
— Ron RothblumSwapping the prover breaks soundness not at all, only threatens completeness
snark.fast is a collaboration between Zcash, Igalia Labs (leading), the Ethereum Foundation and Espresso; the idea is to keep the Plonk verifier unchanged and replace only the prover, to see how much faster it can get. Ron distinguishes two properties: soundness means no one can convince you to accept a false statement, so no matter how fast a prover you build, a false statement cannot be proven, and in that sense there is no security problem; completeness means true statements must be provable, which is harder to guarantee, and snark.fast only guarantees that proofs are still accepted on random inputs. A more ambitious approach is to prove that the change does not alter the prover's input-output behavior, which is exactly what ZK-Golf and Kobe and others are pursuing, with stronger completeness guarantees. Ron also worries that these projects, driven entirely by AI and lacking oversight, could have AI slip malicious code into the prover.
— Ron RothblumAI found an unused GPU on the Mac
Ron had originally expected this kind of large-scale crowdsourced AI to yield a 10-20% engineering improvement; the actual result was 2.5 to 3 times, and purely engineering optimization, with no change to the protocol. One interesting episode is that the AI noticed early on that the tests ran on a Mac, and that the Mac had a GPU that was not being used — not that it did not know it existed, but that earlier attempts to use it had not worked well; the AI was clearly better at it, and this contributed significantly to the success. Another surprise was the x86 version that appeared later, for instance executing SNARKs on Intel servers without a GPU, more than 3 times faster than their Falcon implementation. One concrete optimization technique is memory scanning: if an algorithm needs to scan memory twice to do two things, changing it to do both in one pass saves a lot of work; they knew this should be done, but the AI did it better.
— Ron RothblumAn AI built a processor emulator to enter the contest
snark.fast targeted specific hardware (roughly an M3 processor), so people without that processor could not participate. So an AI built an emulator of that processor, so that its own work could be accepted. Ron at one point even worried that some AI had hacked the snark.fast website to fake data, because that is exactly what it was programmed to do. The evaluation mechanism itself is the key to making this approach work: someone submits a faster prover, it is run on a large number of random inputs to see whether it can make the original June Flock verifier accept, and if it does it counts as valid, then the time is measured over a large number of experiments, and faster means a new leader. This part is managed by Igalia Labs on the Yukon platform. ZK-Golf takes another path: instead of changing the prover engineering, it changes the scheme itself, expressing the scheme in a Lean-based DSL (Clean) and verifying its soundness and completeness; people have already added binary-field and Flock-style schemes, with large percentage improvements over the scheme in the original Flock paper.
— Ron RothblumProving a hash is only 200 times slower than computing one
Ron's long-term goal is ‘proving as fast as computation’, and back in 2020 he wrote a piece titled Proving as Fast as Computation. Measured with Flock, proving a bunch of hashes is only about 200 times slower than directly computing the hashes — which sounds like a lot, but is far faster than previously thought. He cautions that the meaning of this number needs careful interpretation. The next step is to use the new ideas from snark.fast, ZK-Golf and Flock V2 to keep pushing this multiple down, with the goal of approaching 1x. If that can really be done, it means all computation in the world becomes verifiable: your agent, someone else's agent, any operation by anyone, can be verified at extremely low cost against a baseline as having been done correctly, including machine learning training and inference. Ron also mentions that perhaps the universe has some inherent limit that prevents proving from being as fast as computation, and proving that would be equally cool.
— Ron RothblumIn their own words · checked verbatim
And when I told people about this, their typical reaction was, "Well, you know, our real protocols don't do anything stupid that would break them."
Ron Rothblum13:09
So it's worth noting that this is just a mitigation, so we can't demonstrate the attack, but we also don't know if it doesn't exist.
Ron Rothblum17:09
The reason people want to use GKR is that it allows for less data to be captured. Of course. That is, you seem to be recording less data, but you are implicitly confirming it without necessarily actually recording it. And this is a feature of GKR. This is the reason why you want to use GKR. Mhm. And it was this feature that made it possible to carry out our attack.
Ron Rothblum18:10
It could be the function H itself. Oh. H, so think about it, if M is the function H itself, then M of M is just H of H. And H of M is also H of H, so they're the same.
Ron Rothblum22:10
I claim that, you know, it's night outside, even though it's actually day, and I can give you proof that my false claim is true, and you'll accept it with probability one.
Ron Rothblum23:10
So, Plonk correctness generally means that if you have a false statement, no one should be able to convince you to accept it. Good. Yes? In particular, neither Snark.fast nor Snark.faster nor Snark.fastest—no one should be able to convince you of something that is false.
Ron Rothblum44:12
I thought it was pretty obvious that using such massive crowdsourcing AI would yield better engineering than what we had with our agent and a small number of tokens. And I was expecting, you know, 10-20% or something like that. They actually achieved two and a half or three times better results.
Ron Rothblum45:12
What it means is that all computations in the world become verifiable. Anything that anybody, your agent, anybody else's agent, anything that anybody does -- yeah, that you can compare to a baseline to very cheaply verify that it was done correctly.
Ron Rothblum59:15
Figures
| Length of the random bit string in the Fiat-Shamir attack | 100 bits | 20:10 |
| Probability the interactive protocol is accepted | 2 to the minus 100 | 20:10 |
| Size of the digest relative to the original message in a sketched code | about one tenth | 32:11 |
| Engineering improvement of snark.fast over the original implementation | 2.5 to 3 times | 45:12 |
| Improvement of the no-GPU Intel server version over the Falcon implementation | more than 3 times | 46:12 |
| Factor by which Flock proving a hash is slower than computing a hash | about 200 times | 57:15 |
| When Nvidia added binary field support to its GPUs | this May | 56:15 |
Glossary
- Fiat-Shamir
- A transform that turns an interactive protocol into a non-interactive one, replacing the verifier's random coin flips with a hash function.
- GKR
- An interactive protocol for proving the correctness of circuits, widely used because it allows recording less data.
- diagonalization
- A trick that makes a program nest and run itself as input, thereby constructing an input satisfying a particular equation.
- polynomial commitment scheme
- Captures a large polynomial in a tiny commitment, after which computations on that polynomial can be proven; a core component of SNARKs.
- sketched code
- An error-correcting code that first takes a short digest of the message and applies Reed-Solomon encoding only to the digest, making encoding faster.
- binary fields
- Finite fields with elements 0/1, which Binius pushed into use in proof systems and for which Nvidia GPUs have added support.
How to listen
Engineers building ZK proof systems, SNARKs or ZKVMs, and researchers concerned with Fiat-Shamir security and AI-assisted engineering optimization.
The opening chat about the difference between theorists and practitioners (roughly 3:00-6:00) can be skipped.