AlphaProof Code Verifies Signal’s Core Cryptography

Google DeepMind announced on November 10, 2026, that its AlphaProof Code framework had formally verified key security properties of Signal’s core cryptographic implementation. Human experts guided the work, Gemini Carbon agents generated the proofs, and the Lean proof assistant checked them.

DeepMind says the verification took four weeks, compressing work that would previously have required years of expert effort. Its technical paper reports about 6.5 million lines of Lean proof code, connecting protocol-level security guarantees to compiled code from libsignal, Signal’s reference protocol implementation. These are DeepMind’s reported results, not independently measured performance figures. (Announcement, technical paper)

The important distinction is what those proofs establish. This is a substantial assurance result for specified cryptographic behavior. It is not a certificate that every part of Signal, every supported platform, or every future release is free of bugs.

What AlphaProof Code Actually Proved

The technical paper identifies two covered protocol components: the PQXDH handshake and Triple Ratchet. The handshake establishes a secure session; the ratchet updates cryptographic state as communication progresses.

The proofs connect their security properties to AArch64 machine code, the 64-bit Arm instruction-set architecture. That is a much more concrete target than an abstract description of how an encrypted messaging protocol should work.

The paper names four established properties:

These descriptions explain the goals. The formal specifications define the exact conditions, permitted attacker capabilities, and guarantees. For example, post-compromise security should not be read as protection against an attacker who retains continuing access to a device.

A formal proof establishes that the modeled implementation satisfies its mathematical specification under the stated assumptions. Choosing a specification that captures the intended security promise is therefore a central part of the work.

That is why the human role matters. DeepMind says researchers worked with models to translate Signal’s security goals into formal specifications, with experts reviewing every specification before the proof work proceeded. (DeepMind announcement)

Why Proving Machine Code Is the Significant Step

A protocol can have a sound design while its implementation gets something wrong. Developers must turn mathematical operations into state management, branching logic, data representations, and executable instructions. A proof about an abstract protocol cannot automatically settle whether those implementation details preserve its guarantees.

DeepMind’s paper says earlier work covered abstract protocol models, verification-friendly reimplementations, implementations modified to simplify verification, or narrower properties such as crash-freedom. AlphaProof Code instead targets protocol-level security guarantees for an unmodified production implementation.

Its workflow compiles libsignal’s Rust code using the standard compiler, loads the executable into Lean, and reasons about its behavior using a formal description of AArch64 instructions. DeepMind describes the result as the first connection of this kind between protocol-level security guarantees and the unmodified code of a widely used cryptographic protocol implementation. That priority claim comes from the researchers. (Technical paper)

My view is that the executable target matters more than the headline proof-line count. Millions of generated lines show the scale of the proof work. Connecting a security theorem to the instructions a processor executes addresses a specific assurance gap between a correct design and a correct implementation.

The architecture also sets a boundary: an AArch64 executable proof should not automatically be treated as a proof of every build for every processor.

How Gemini Agents and Lean Divide the Work

AlphaProof Code combines a specification-writing process, autonomous prover agents, and a machine-checking gate. The AI proposes mathematical arguments; Lean determines whether those arguments are valid against the approved statement.

The paper’s workflow separates those responsibilities:

That last check is easy to overlook. An agent could produce a mathematically valid proof of an easier or irrelevant theorem. Comparing the result with a held-out specification helps prevent that mismatch.

The framework also allows provers to propose specification amendments if they encounter a vacuous or otherwise incorrect statement. Those changes require approval through the user-set policy or explicit judgment. Specification changes are therefore part of a controlled process, not something a proof agent can silently use to claim success.

The approximately 6.5 million generated proof lines rest on about 26,000 lines of trusted specifications and AArch64 semantics, according to the paper. Those numbers represent different responsibilities: proof steps are checked, while the trusted definitions establish what program behavior and security mean inside the system.

DeepMind also says agents audited the work and flagged roughly 1% of the codebase for further human attention. That reported review figure should not be confused with the size of the trusted specification layer. (Technical paper, announcement)

Lean reduces the need to trust an AI-generated argument. Human judgment remains essential in deciding whether the checked statement is useful and whether its model matches the intended system.

Two Reintroduced Bugs Tested the Framework

DeepMind reports a useful check beyond proving properties of the current implementation: researchers reintroduced two real, previously fixed bugs into an isolated version of Signal’s code.

For both modified versions, AlphaProof Code produced machine-checked proofs that the code was insecure. (DeepMind announcement)

This matters because a weak specification can be easy to satisfy while missing the behavior that makes software unsafe. Demonstrating that the framework can establish insecurity for known-bad variants provides evidence that it distinguishes at least those failures.

I would treat this as a meaningful check, with a bounded conclusion. Two reintroduced bugs support the system’s ability to reason about those cases. They cannot measure its coverage of every vulnerability class or establish that every important security goal was specified.

The reported result is also different from discovering two new vulnerabilities in the deployed release. These were previously fixed bugs deliberately restored for the experiment.

What Signal Users Should Take From the Result

The proof’s scope is libsignal’s covered cryptographic components and properties. It does not encompass the complete Signal application, the operating system, or every surrounding service.

A memory leak, crash, user-interface flaw, or message-delivery failure is not automatically excluded by the four named security guarantees. Whether a particular defect contradicts a theorem depends on the formal model and what that theorem requires.

That distinction appeared in the Hacker News discussion. Commenter mentalgear emphasized that the work concerned the protocol, “not the Signal App or the surrounding platform OS.” Other participants questioned how broadly readers should interpret the announcement. Those comments document individual reactions; the technical paper supplies the evidence for the verified scope.

For users, the practical benefit is stronger assurance around foundational encryption behavior. It does not remove the need for software updates or endpoint security. A device that exposes messages outside the verified cryptographic boundary remains a separate security problem.

For engineering teams, the result suggests a complementary role for formal proofs alongside testing, code review, and vulnerability discovery. Each answers different questions about the system.

Four Weeks Is a Schedule, Not a Cost Model

DeepMind’s four-week claim is striking because formal verification has historically demanded substantial specialist labor. Its paper cites 20 person-years for verification of the seL4 microkernel and six person-years for the CompCert compiler. Those projects provide historical context, but they are different systems with different proof goals. They are not controlled benchmarks against AlphaProof Code. (Technical paper)

Elapsed time also differs from total effort and cost. A four-week run does not, by itself, reveal the economic balance between model computation, expert specification work, infrastructure, and maintenance.

My reading is that DeepMind has presented a strong case for accelerating this particular verification task. The broader claim that comparable assurance will become economical across production software remains prospective. DeepMind itself says scaling the techniques requires continued research. (Announcement)

Maintenance is a consequential next question. These proofs concern the executable artifacts and specifications used in the verification. A changed implementation or build needs corresponding assurance; an earlier proof cannot simply be carried forward by assumption.

DeepMind has open-sourced the verification artifacts for community use. That makes scrutiny possible at the level that matters: the specifications, executable model, and checked proofs, rather than the announcement alone.