← Back to all posts
News

DeepMind's AlphaProof Code Verifies Signal's Encryption Down to Machine Code

November 11, 2026 · 03:17 UTC · News
On this page 7 sections
DeepMind's AlphaProof Code Verifies Signal's Encryption Down to Machine Code

TL;DR

AlphaProof Code, a multi-agent verification framework from Google DeepMind, has produced machine-checked proofs that Signal's reference cryptography does what it claims, at the level of the compiled binary. Prover agents powered by Gemini Carbon wrote about 6.5 million lines of Lean proof against libsignal v0.105.4, compiled with stock rustc into an AArch64 Linux executable. DeepMind says no method, human or AI, had previously connected protocol-level security guarantees to the unmodified code of a widely deployed cryptographic implementation. The campaign took four weeks, and the specifications and proofs are public.


At a glance
The Signal verification, by the numbers
6.5M
agent-written Lean proof lines, all kernel-checked
26k
lines of spec and CPU semantics humans must trust
4 weeks
campaign length; seL4's proofs took 20 person-years
40-80
prover agents per campaign, one machine, 24-72 hour runs
2
real fixed bugs re-injected; both formally proved insecure
0
new vulnerabilities found in the verified code

What got proven

The target is the one-to-one session code of libsignal: the PQXDH handshake and the Triple Ratchet, including the SPQR post-quantum layer. Variants of this protocol carry messages for billions of people across Signal, WhatsApp, Google Messages, and Meta's Messenger, so the target here is the shipped binary itself, not a paper model of the protocol.

DeepMind ran the verification in the two standard models of protocol security. In the symbolic (Dolev-Yao) model, agents proved ten theorems: forward secrecy, post-compromise security of message keys, handshake authentication, resistance to key-compromise impersonation, and handshake secrecy that survives a future quantum computer breaking Diffie-Hellman. In the computational model, they proved message confidentiality and authenticity as a concrete bound: any classical attacker's advantage reduces to breaking the underlying primitives, namely Gap-DH, XEdDSA, Kyber1024, HKDF, HMAC, and AES-CBC.

Scope
Proven versus not covered
Proven, machine-checked in Lean
forward secrecypost-compromise securitymessage confidentialityauthenticityKCI resistancehandshake secrecy vs a future quantum computer
Not covered
group messagingquantum attacker in the computational modelmulti-device statecomputational bound goes vacuous for many long sessions
Scope per the paper's Table 1. Source: AlphaProof Code technical paper, Nov 10, 2026.

Two prior facts make the first honest. Earlier formal analyses of Signal targeted abstract protocol models or reimplementations written to be verifiable. And landmark artifacts like seL4 (20 person-years of proof engineering) and the CompCert verified compiler (6) verified source code written with verification in mind. AlphaProof Code verified pre-existing production code as an optimizing compiler emits it, the hard case, since nobody rewrote libsignal to make the proofs easier. The paper positions the result as a milestone toward a formal verification grand challenge launched in April 2026.

The pipeline

AlphaProof Code splits verification the way a research group splits a paper. A human-guided specification agent turns the security properties from the literature into Lean theorem statements, reviewer agents attack each draft from a skeptical angle, and a human approves the result before any proof exists. That approved specification becomes a git commit, and the gatekeeper copies it into a held-out directory no agent can write to.

Then the binary. The unmodified crates compile with stock rustc into a statically linked AArch64 executable, and Lean loads it next to a formal semantics of user-mode AArch64 Linux: 467 instructions and 31 system calls, validated in lockstep against two independent models derived from QEMU and from Arm's official specification. A team of 40 to 80 agents then runs 24 to 72 hours on a single machine, with an orchestrator dividing the work, team leads absorbing context churn, an architect keeping the decomposition coherent, and an integrator as the only agent allowed to commit.

How it works
From spec to machine-checked proof
Step 1
Write the spec
agent drafts Lean theorems, human approves
Step 2
Compile the real code
stock rustc, AArch64 binary loaded into Lean
Step 3
Prover team attacks
40-80 agents, 24-72 hours, one machine
Result
Gatekeeper decides
Lean kernel plus comparator against held-out spec
Provers cannot declare a goal done; only the gatekeeper can, and only after a mechanical check.

The one thing an agent cannot do is declare victory. The gatekeeper accepts a proof only if Lean's kernel checks it, the proof uses only Lean's standard axioms, and the comparator tool confirms the theorem and every definition it depends on are identical to the held-out specification. Think of the 6.5 million proof lines as student answers and the 26,000 trusted lines as the exam: the students never touch the answer key, and the grader is a machine that has never once accepted "trust me" as a proof step.

When proof attempts expose a real flaw in the specification, agents propose an amendment to a critic agent that never sees the proof attempts. The critic accepts only with a machine-checked disproof or counterexample, only if the change does not weaken security, and only if it stays small; changes to trusted assumptions go to a human. Agents propose, mechanics verify, humans own the goals.

The receipts

The team stress-tested its own specifications before trusting them. They re-introduced two real, previously fixed libsignal bugs, including one where a prekey message that decrypted only under an archived session still stored the new session's state, complete with a copy of the signed prekey secret. In both cases the agents produced Lean proofs that the mutated binaries violate the symbolic security theorems.

They also ran mutation checks on the spec (inject natural bugs, like skipping ciphertext MAC verification, then prove the theorem false), proved the hypotheses jointly satisfiable to rule out vacuous theorems, and replayed full scenarios on the Lean semantics: 15.6 million instructions across 10 invocations, matching the real binary's behavior including all session state. WIRED reports the analysis turned up no new vulnerabilities in the code it covered.

Trust
Where your trust actually goes
What are you trusting?
the 6.5M proof lines
CHECKEDLean's kernel rejects any error; agents cannot declare done
the ~26k spec + semantics lines
TRUSTEDhuman-reviewed, the part a flaw would weaken
the crypto primitives
ASSUMEDKyber, AES, X25519 enter as contracts, their security is not proved
the Lean kernel itself
TRUSTEDsmall checker, standard axioms only

The catches

  • Scope is one-to-one sessions. Group messaging is future work, multi-device state is not covered, and the verified artifact is a CLI harness around libsignal, not the Signal app. The theorems carry over to the Android and iOS apps only if you trust those environments to preserve the protocol code's behavior.
  • The quantum guarantee lives in the symbolic model. The computational bound covers classical attackers and, per the paper, goes vacuous for multiple long sessions with many epochs.
  • A few dozen routines, the low-level crypto (AES, Kyber, X25519), some libc string functions and file writers, are modeled by contracts instead of verified. Everything else, including the allocator and protobuf serialization, is proved.
  • The semantics models a single-threaded, statically linked process with 1 GiB of memory. Threads, signals, the vDSO, and dynamic linking sit outside it.
  • Google did the work free as research, declined to say what it cost, and would not comment on commercial plans. Cost and scale are the open questions, as Chaudhuri told WIRED: "there is a long distance to go before we are able to scale this to all the software of the world, and we want to do that."

Why builders should care

Signal CTO Ehren Kret called the work "a major breakthrough" and said the verification "gives us even greater confidence in our code's privacy guarantees" as AI-driven threats grow. For everyone else shipping software, the reusable part is the architecture, not the cryptography. An 80-agent artifact is trustworthy precisely because none of its 6.5 million lines are trusted: a mechanical kernel checks every step against a specification the agents cannot edit.

That transfers to any agent system with correctness requirements. Let agents generate volume. Bind acceptance to a checker that cannot be charmed. Keep the goals where the agents cannot write, and route every change to them through a human. Chaudhuri's summary to WIRED is the sharpest version: "We don't want this sort of vibe world where AI is generating the goals and AI is generating the proofs and basically taking tests that are self-written. There's a middle ground."

The economics matter as much as the technique. If four weeks of agent time stands in for person-decades of proof engineering, formal verification stops being a seL4-scale luxury and becomes something a mid-size team can point at the code where correctness pays for itself: payments, auth, crypto, infrastructure. DeepMind names medical device firmware and power grid software as the same class, and pairs the idea with its CodeMender defense agent. Attack tooling got fast and cheap. This defense ships with a proof object attached.

Key Takeaways

  • Google DeepMind's AlphaProof Code produced about 6.5 million lines of machine-checked Lean proof that libsignal v0.105.4's PQXDH handshake and Triple Ratchet deliver forward secrecy, post-compromise security, authentication, and (in the symbolic model) quantum-safe handshake secrecy, at the compiled AArch64 binary level.
  • DeepMind says no method, human or AI, had previously connected protocol-level security guarantees to the unmodified code of a widely deployed cryptographic implementation.
  • The campaign ran four weeks with teams of 40 to 80 prover agents on a single machine, against roughly 26,000 lines of trusted specification and AArch64 semantics. seL4 took 20 person-years; CompCert took 6.
  • Trust is minimized by construction: Lean's kernel checks every proof line, a comparator confirms each theorem matches a held-out specification agents cannot write, and two re-injected historical bugs were formally proved to break the theorems.
  • Limits: one-to-one sessions only, a CLI harness rather than the Signal app, quantum attackers covered in the symbolic model only, and a few dozen crypto and libc routines assumed via contracts.
  • Specifications, semantics, and proofs are open source at google-deepmind/code-verification. Google declined to state the cost or its commercial plans.

Sources: Google DeepMind, Introducing AlphaProof Code (Nov 10, 2026), AlphaProof Code technical paper (PDF), google-deepmind/code-verification on GitHub, WIRED

AIGoogle DeepMindAlphaProof CodeSignalFormal VerificationLeanSecurityCryptography
CONSOLE
$