O código do AlphaProof provou que a criptografia do Signal está correta — no nível do binário compilado

Six and a half million lines of Lean, produced in four weeks, by agent teams that no human helped write. That is the headline number G​oogle DeepMind published on 10 November 2026 for AlphaProof Code, an agentic framework for formal verification that the lab used to machine-check the cryptographic core of the Signal protocol — and, unusually, to check it at the level of the compiled AArch64 binary rather than the design document above it. The models that did the work are a different question. one API key at provider list price with 0% markup The proof agents' engine is not something we serve.

The framework is not a model you can call. It is a harness: human experts decide what must be true, a mixture of models turns those goals into Lean specifications, and then teams of proof-writing agents — the blog names G​emini Carbon as the engine — fill in the proofs until Lean's kernel accepts them. What shipped alongside the announcement is the artifact set, at github.com/google-deepmind/code-verification, and a technical paper that is far more candid about the boundaries of the result than the blog post is. Most of what follows comes from that paper, because the paper is where the interesting numbers live.

O que foi realmente provado, e contra o quê

O alvo é o libsignal v0.105.4 com spqr v1.6.0, compilado pelo rustc 1.98.1 padrão, ligado estaticamente contra musl e emitido como um único executável Linux AArch64. Esse detalhe importa mais do que qualquer benchmark: as provas são sobre os bytes que seriam executados em um telefone, não sobre uma função Rust cuja tradução fiel se confia ao compilador. A equipe verificou cerca de 560 KB do código-fonte do libsignal, cerca de 140.000 instruções AArch64, e o fez escrevendo um modelo Lean do conjunto de instruções — 467 instruções e 31 chamadas de sistema, em 7.578 linhas — e então provando que a imagem ELF real, carregada e executada sob esse modelo, preserva as propriedades de segurança.

As propriedades são as que um engenheiro de protocolos pediria. Dez teoremas simbólicos cobrem sigilo prospectivo, segurança pós-comprometimento, sigilo do iniciador e do respondedor, autenticação e cinco corolários do Teorema 1 do PQXDH. O resultado principal chama-se signal_session_secure_placed. Há também uma vertente computacional com um limite concreto, e as duas vertentes usam modelos de adversário diferentes: o lado simbólico (Dolev–Yao, por meio do framework DyLean) cobre até um atacante quântico que quebra Diffie–Hellman após o handshake, enquanto o lado computacional cobre apenas adversários clássicos.

Para onde vão as seis milhões de linhas

"Mais de seis milhões de linhas" é a formulação do blog e é precisa, mas grosseira. O detalhamento do artigo é o que é útil, e vale a pena lê-lo como uma tabela de custos, e não como uma ostentação:

• Provas para o binário — 5,3 milhões de linhas, a maior parte do trabalho, cobrindo a semântica do código de máquina e o refinamento do modelo simbólico até o executável.

• Provas computacionais — cerca de 860.000 linhas.

• Provas simbólicas — cerca de 350.000 linhas.

• Provas de refutação de bugs — cerca de 140.000 linhas, para as duas vulnerabilidades reintroduzidas deliberadamente descritas abaixo.

• Provas do alocador — cerca de 70.000 linhas.

Quase sete milhões de linhas, se contarmos comentários e linhas em branco, o que o artigo faz e o blog não. De qualquer forma, a proporção que importa é entre a prova e aquilo que se prova: 6,5 milhões de linhas de Lean para estabelecer propriedades de um binário de 560 KB. Essa proporção é a medida honesta de quão longe essa técnica está de se tornar rotineira, e é o número a citar quando alguém pergunta se a verificação formal se tornou barata.

A base confiável é menor que a prova, e é esse o ponto.

Uma prova vale apenas o que valem suas premissas. O artigo é específico quanto a isso, e a especificidade é o que o distingue de um comunicado à imprensa. As especificações confiáveis têm cerca de 18.000 linhas (28.000 com documentação), a semântica do AArch64 cerca de 8.000, e a codificação em Lean do código de máquina around 95.000. Trinta e sete rotinas são substituídas por contratos em vez de verificadas — compressão SHA-256 e SHA-512, AES-256-CBC, X25519, as operações da curva Edwards, Kyber1024 e ML-KEM-768, e HMAC da libcrux. Dezoito pontos de entrada de panic são igualmente assumidos em vez de provados.

Portanto, a alegação não é "tudo está provado". A alegação é que a lógica do protocolo criptográfico, a máquina de estados da sessão e o refinamento dessa lógica para as instruções efetivamente executadas estão provados, enquanto as primitivas por baixo são confiadas tal como todo projeto de verificação confia em suas primitivas. O compilador Rust, notadamente, não está na base de confiança — a equipe evitou a necessidade de confiar nele ao raciocinar no nível do código de máquina, que é o mesmo truque que lhes permite contornar inteiramente um compilador verificado. Para dar contexto sobre escala, o artigo cita o seL4 em cerca de 20 anos-pessoa e o CompCert em cerca de 6.

Dois bugs, recolocados de propósito

Um sistema de verificação que só diz "correto" é impossível de testar. Então a equipe pegou duas vulnerabilidades que já haviam sido encontradas e corrigidas no código do Signal — um bug de estado fraco e um bug de subgrupo pequeno — reintroduziu-as em uma cópia isolada e executou o pipeline novamente. Nos dois casos, o AlphaProof Code produziu uma prova verificada por máquina de que a versão com bug não satisfaz o teorema de segurança: a declaração simbólica resolve-se para ¬Sec(Asm_bug).

O artigo acrescenta uma ressalva que uma página de marketing teria cortado: refutar o teorema computacional para esses bugs é "muito mais difícil" e ficou em aberto. Em outras palavras, o teste negativo funciona perfeitamente na via simbólica e ainda não funciona na computacional. Esse é exatamente o tipo de assimetria que um leitor deveria conhecer antes de tratar o framework como um detector de bugs.

Como os agentes foram executados

Cinco pesquisadores ao longo de quatro semanas, cada um executando agentes sem parar. A própria escrita das provas foi feita por equipes de 40 a 80 agentes, rodando entre 24 e 72 horas em uma única máquina por equipe, com um agente supervisor acima do orquestrador da equipe. Um agente de controle verifica cada submissão usando o comparador contra uma cópia reservada da especificação e contra o kernel do Lean — uma defesa contra um agente provar uma versão sutilmente enfraquecida do que foi pedido.

O trabalho humano foi concentrado no início, nas especificações. Cada especificação foi revisada por um especialista antes do início do trabalho de prova, e a própria passagem de auditoria dos agentes sinalizou cerca de 1% da base de código para atenção humana. Nenhum humano escreveu código de prova. O artigo também é direto sobre a engenharia: uma compilação limpa pode levar várias horas; no início, uma pequena edição no código-fonte ou um binário recompilado exigia grandes reparos nas provas; e há "bastante espaço para otimização" tanto nas provas geradas por IA quanto nas próprias técnicas de prova.

O que as provas não cobrem

As limitações são extensas o bastante para constituir a seção mais importante do artigo, e são declaradas de forma clara. Nenhuma garantia pós-quântica é estabelecida para a propriedade de healing do SPQR — os teoremas do ratchet assumem que o atacante escolhe as chaves SPQR. A privacidade do payload não é provada. A autenticação do respondente não é provada para a primeira mensagem de um handshake que nunca é promovido. O modelo permite uma sessão por promoção, comprimentos de mensagem fixos, nenhum estado multidispositivo e chaves de identidade trust-on-first-use.

Há também um limite que se torna vazio. O termo de falsificação de MAC de 8 bytes é de pelo menos 2⁻⁶⁴ por tentativa e cresce quadraticamente em mensagens e épocas, o que significa que o limite deixa de dizer qualquer coisa para uma única sessão de aproximadamente 25.000 mensagens, ou para 2²⁰ sessões de 2¹⁰ mensagens. E o objeto da prova é a compilação da equipe do libsignal-cli executada como um processo novo — não o aplicativo Signal no seu telefone. Várias suposições de ambiente são defendidas informalmente em vez de provadas.

Não há API, nem preço, nem modelo para chamar

Esta é a parte que vai decepcionar qualquer pessoa que chegue vinda de um ranking de modelos. O AlphaProof Code é um framework de pesquisa e um conjunto de artefatos publicados. Não há endpoint, nem tabela de preços por token, nem lista de espera, nem pesos: o repositório contém o desenvolvimento em Lean, a semântica AArch64, a integração com o libsignal e as especificações, não um checkpoint. O blog diz que os artefatos têm código aberto; a página inicial não declara licença, o que vale a pena verificar antes de alguém planejar construir em cima disso.

The models that did the work are a different question. The paper names G​emini 4 Carbon for the proof agents and says Claude Opus 5.5 was used alongside other models for drafting and reviewing specifications. Claude Opus 5.5 is on OrcaRouter's catalogue today at $4 per million input tokens and $20 per million output, with provider list price passed through at 0% markup — so if the practical takeaway you want is "run a spec-drafting loop with the model the paper used," that part is a normal API call, and a vendor price change lands on our side the same day. The proof agents' engine is not something we serve, and nothing here implies we host AlphaProof Code itself.

Por que isso é mais importante do que o resultado do Signal

A verificação do Signal é impressionante por si só — a primeira verificação formal da implementaçãode um protocolo amplamente implantado por qualquer método, com ou sem IA, segundo a DeepMind, e a primeira vez que a IA verifica um protocolo criptográfico implantado nesse grau de profundidade. Mas a alegação transferível é o fluxo de trabalho. Uma equipe de cinco pessoas, em quatro semanas, com uma etapa de revisão de especificação e um agente gatekeeper, produziu um corpus de provas que antes teria sido um projeto de vários anos. Se essa proporção se mantiver, ainda que vagamente, o conjunto de sistemas que podem arcar com a verificação muda: firmware de dispositivos médicos, software de redes elétricas, o tipo de código que atualmente passa por uma revisão de código e uma reza.

Não se testou se isso se sustenta. A criptografia do Signal é excepcionalmente bem especificada, a equipe contou com os próprios engenheiros do Signal revisando a metodologia, e as primitivas foram terceirizadas em vez de verificadas. O próximo sistema não será tão favorável. A própria formulação do artigo — combinar verificação formal com agentes automatizados de defesa como o CodeMender — é a forma honesta da proposta: a verificação diz o que é verdadeiro, e outra coisa precisa corrigir o que não é.

O que assistir

Three things would move this from a landmark paper to an industrial technique. A second, independent codebase verified by someone outside G​oogle, ideally one where the specification had to be written from scratch rather than adapted from an existing analysis. A cost figure — agent-hours, accelerator-hours, dollars — because four weeks and 40-to-80-agent teams is not a unit any engineering manager can budget against. And the computational-track bug refutation, which the paper leaves open and which is the difference between a system that proves properties and a system that can also tell you, computationally, that a specific binary is broken.

Até então, leia o repositório de artefatos em vez do anúncio. As provas estão lá, o Lean as verifica, e o artigo diz exatamente o que elas pressupõem.