On November 10, 2026, Google DeepMind announced that it had formally verified key properties of libsignal, the reference implementation of the Signal protocol. Researchers compiled a small program that uses libsignal to AArch64 Linux machine code and modeled that code’s execution. Humans reviewed the formal specifications, and Lean’s kernel checked the proofs against them.
That distinction matters. A formal proof can be very strong, but only for the exact code, build, model, and properties that were stated up front. It is not the same thing as saying “the whole app is safe” or “every future release behaves the same way.”
What was covered
According to the paper, the verified scope focuses on the post-quantum PQXDH handshake and the Triple Ratchet. The stated properties include security goals such as forward secrecy, authentication, post-compromise security, and handshake secrecy, though the paper does not imply that every one of those goals applies identically to both protocol pieces in the same way. The important point is that the proofs are about specific protocol behaviors and claims, not a general guarantee about the entire Signal ecosystem.
The model also includes cryptographic primitives and some external calls through contracts. In plain English, that means the proof treats certain lower-level operations as trusted building blocks with declared behavior, rather than re-proving the internals of every primitive from scratch.
What the proof does not cover
The paper lists group messaging, sealed sender and server-side protocols as possible future work. It examines machine code in the research harness, so its findings do not by themselves establish the same properties for a different binary or for an entire phone app.
Suppose you are reviewing the result for a group chat or a particular mobile release. Check whether the paper identifies that feature and build as part of the proof. For group messaging, the paper says coverage remains future work; for a different binary, the reported result does not automatically transfer.
What ‘property’ and ‘assumption’ mean
A property is a claim the code is supposed to satisfy. For example, “if a handshake succeeds, then it meets authentication requirements” is a property. An assumption is something the proof depends on but does not itself establish. For example, if a cryptographic primitive is modeled by contract, the proof assumes that contract is correct. If an external call is abstracted, the proof assumes the modeled behavior matches reality. Those assumptions are not flaws; they are part of how formal verification stays manageable.
Three checks for reading the result
- Which code/build was proved? Look for the exact implementation, architecture, and harness.
- Which properties were stated? Distinguish protocol claims from broader product claims.
- Which boundaries were left out? Note modeled assumptions, future-scope items, and anything outside the proof target.
The safest reading of the result is simple: DeepMind showed a rigorous proof for a narrow, important slice of Signal’s cryptographic machinery. That is valuable, but it is not an exhaustive guarantee about every deployment, device, or feature in the real world.
DeepMind announcement: Introducing AlphaProof Code
DeepMind paper: Formal Verification of Signal
