Responsible Disclosure with Zero-Knowledge Proofs
Google used a ZK proof to disclose a quantum cryptanalysis result without publishing the exploit. Trail of Bits forged a "better" proof two weeks later. The episode is a stress test of a new disclosure norm, and the technology is stronger for it.
An Early Field Test
On March 30, Google's Quantum AI group published a paper with co-authors from UC Berkeley, the Ethereum Foundation, and Stanford that claimed a substantial improvement in the resource cost of running Shor's algorithm against elliptic curve cryptography. But unlike Google's previous quantum cryptanalysis publications, this one withheld the actual quantum circuits.
Instead, the authors generated a zero-knowledge proof using Succinct's SP1 zkVM and published the proof. Anyone could cryptographically verify that the circuits exist and meet the claimed resource bounds, without learning how to construct them. Google framed the decision as a public-responsibility judgment. Detailed cryptanalytic blueprints that are freely published create weapons-grade material, so the disclosure norm needed to evolve to reflect that.
Two weeks later, on April 17, Trail of Bits published a write-up titled "We beat Google's zero-knowledge proof of quantum cryptanalysis." It included a forged ZK proof claiming better metrics than Google's. The forged proof verified cleanly against Google's unpatched verifier. Cryptographically, it was indistinguishable from a proof of an actual algorithmic improvement. The proof-of-concept code is open-sourced.
This is the most interesting field test of zero-knowledge proofs as a disclosure mechanism so far, and the lesson it teaches is more useful than either "ZK works" or "ZK is broken."
What Google did
A zero-knowledge virtual machine (zkVM) lets a developer write a regular program, run it on private input, and produce a cryptographic proof that the program ran correctly on some input that satisfies a public condition. The verifier learns the public output is correct without learning the input. SP1 is one of several production zkVMs, alongside RiscZero and others. Developers write guest programs in Rust, which compile down to RISC-V binaries that the zkVM then proves the execution of.
In Google's setup, the private input was the quantum circuit, encoded in a custom assembly language called "kickmix." The guest program was a simulator that took the circuit, applied it to many random inputs, and verified that the circuit computed the correct output for each one. In this case, a single elliptic curve point addition, the inner subroutine of Shor's algorithm. The guest program also counted operations, qubits, and Toffoli gates, and the public output of the proof was the upper bounds on those resource counts.
So when Google published the proof, anyone could run the verifier and confirm there exists some quantum circuit, secret to Google, that performs correct elliptic curve point addition with at most this many operations, qubits, and Toffolis.
Responsible vulnerability disclosure has historically required some form of trust between discoverer and defender, with researchers sitting on findings during embargoes and publishing enough detail for defenders to patch, and accepting that the same detail enables some attackers. Zero-knowledge proofs offer the option to publish the fact of a vulnerability with cryptographic confidence while keeping the construction private.
What Trail of Bits did
Keegan Ryan at Trail of Bits ran Google's ZK proof through the kind of analysis any security firm would apply to a high-stakes cryptographic claim.
Ryan didn't attack SP1's proof system. He didn't break the underlying cryptography or the constraints that bind the zkVM's execution to its proof. The proof system did exactly what it was supposed to do: it produced a sound proof that Google's guest program executed faithfully on the input Trail of Bits provided.
The vulnerabilities were in Google's guest program, the Rust simulator code running inside SP1. There were two specific bugs:
The first was a deserialization issue. Google's simulator read circuit operations from outside the zkVM and used an unsafe Rust block to deserialize them without validating that the operation type fields were within the expected range. (The unsafe block was almost certainly added for performance since every additional bounds check inflates the cost of generating a ZK proof, and these checks would have run millions of times.) Trail of Bits reverse-engineered the RISC-V binary and identified that the Rust compiler emitted two jump tables for the operation-handling logic — one to increment the gate counter, one to apply the actual operation. By crafting an out-of-range operation type with a specific offset, they could skip the gate counter entirely while still applying the operation correctly. This let them implement Toffoli-equivalent gates that didn't get counted.
The second was a register aliasing bug. The Toffoli operation handler had no check that input qubits were different from the output qubit. Setting all three to the same qubit produces an immediate zero. This may be useful in classical computing, but it's a violation of quantum reversibility. With this primitive, Trail of Bits could implement arbitrary classical logic gates and build a non-quantum circuit that happens to compute elliptic curve point addition.
Combined with some clever applied math (Proos-Zalka register sharing on top of the binary extended Euclidean algorithm), this got Ryan to a forged proof that beat Google's stated metrics on every dimension.
The lesson
Google patched the code. Their claims about the underlying quantum-circuit improvements they were trying to disclose are unaffected. The patched proof is now the canonical reference. By any reasonable measure, the responsible-disclosure protocol worked: Trail of Bits coordinated with Google, the patches were applied quickly, and the public record was strengthened rather than weakened.
So, zero-knowledge proofs don't eliminate trust, they redistribute it. The original trust framework of peer review, replication, and expert scrutiny gets another option, which is trust in the programming languages, compilers, proof systems, and implementation code that produced the proof.
The zkVM proves what the guest program does. If the guest program has bugs, the proof faithfully proves the buggy execution. Both Succinct's and RiscZero's documented security models say this. RiscZero disclosed a platform-level memory-safety advisory in October 2025 affecting their guest runtime, a different shape of issue than Google's but a reminder that every layer of the zkVM stack including proving system, platform code, and guest program needs ongoing audit attention. The lesson is category-wide and was always going to surface eventually.
What changes is the auditing surface. When a team uses a ZK proof to make a high-stakes claim, the relevant audit isn't of the cryptography (which is well-established and battle-tested) but of the application code that defines what the proof is actually proving. That code needs the same level of review as any other security-critical software: memory safety, input validation, deserialization, edge cases in matched logic. SigmaPrime, 7BlockLabs, and others have begun publishing audit checklists specifically for SP1 and zkVM guest programs.
Why this is a step forward
There's a temptation to read this episode as undermining the case for ZK-based disclosure.
Trail of Bits's analysis was possible because Google open-sourced the simulator and proof-generation instructions. Without that openness, the bugs would have stayed hidden. Google's willingness to publish enough detail for an adversarial audit is what made the whole process work. The guest program is the new attack surface, so making it inspectable is the new disclosure norm. That's a healthy outcome for the category.
Google's underlying scientific contribution is also intact. Trail of Bits notes that achieving Google's stated qubit counts requires solving real problems documented in published literature. Even the most revolutionary scientific breakthroughs build on prior work, and a healthy understanding of what's known and what remains hard helps demystify the result. The actual Google improvement, whatever it is, is built on optimization frameworks (measurement-based uncomputation, register-sharing variants of Kaliski's method) that have an established academic track.
And the disclosure-mechanism precedent is now stronger than before. There's a worked example in the public record: a major research lab making a sensitive cryptanalytic claim, using ZK to publish without revealing the construction, having the claim audited, having the audit catch real implementation issues, and having those issues patched.
What's worth tracking
Guest-program audit practices. Teams shipping ZK-based disclosures will increasingly need to attach formal audits of their guest programs. Trail of Bits, Veridise, Nethermind, Cantina, Zellic, KALOS, and others have all done zkVM-related audit work. Expect this to become a standard part of any high-stakes ZK claim, the way smart-contract audits did for production DeFi.
Embargo norms. Trail of Bits raised a substantive point that hasn't been adequately addressed in the responsible-disclosure literature: ZK proofs can communicate the importance of a patch, but they don't substitute for the eventual fuller disclosure that academic publishing and coordinated vulnerability disclosure depend on. The 30-day embargo norm exists for reasons (patch adoption, defender benefit, replication). ZK-based disclosure may transform the embargo period.
Formal verification of the prover stack. Succinct has been investing in formal verification of SP1 itself, with collaborations with Veridise (using the Picus tool) and Nethermind (using Lean to verify SP1's RISC-V chips). RiscZero has done similar work. This narrows the trust surface around the proving system, leaving the guest program as the principal residual risk surface, which is exactly where the Google episode landed.
Beyond cryptanalysis. Proving a sensitive claim without revealing the underlying construction generalizes well beyond quantum cryptanalysis. Software vulnerability disclosure, supply-chain attestation, AI model claims (proving an output came from a specific model without revealing weights or input), and certain forms of regulatory compliance all can follow similar models.
The direction of travel
ZK proofs as disclosure had their first public stress test, the test surfaced implementation issues, those issues were patched, and the mechanism survived. Whether the mechanism should be used as a substitute for fuller disclosure in cases more sensitive than this one is unresolved.
Guest-program quality is a critical residual trust surface, and the practitioner ecosystem responded with appropriate audit infrastructure.
This case surfaced the actual trust model as to what ZK proofs do and don't do under live conditions, with real consequences, and produced a sharper public understanding of what production-grade responsible disclosure with ZK looks like.
