Código e Sinal AlphaProof: provas de segurança de código de máquina verificadas e suposições fidedignas

O que este vídeo aborda

• Os agentes de IA produzem provas candidatas; o kernel do Lean verifica se estabelecem a reivindicação formal aprovada por humanos.
• O alvo verificado é um "harness" CLI libsignal compilado particular, com semântica e contratos criptográficos fidedignos.
• A prova do binário compilado remove o compilador Rust da base fidedigna para as propriedades declaradas desse binário.
• Os investigadores relatam duas reintroduções isoladas de bugs previamente corrigidos que violam o seu teorema de segurança simbólica.
• O comparador verifica o teorema e todas as definições dependentes em relação a uma especificação aprovada e protegida; as alterações passam por um processo de revisão separado.

Transcrição traduzida

Traduzido da narração original em inglês. Áudio e legendas disponíveis são controlados pelo YouTube.

Quem verifica uma prova de segurança de IA?

0:00 Uma auditoria de segurança de IA ainda soa como confiar num "chatbot". O novo resultado do Signal da Google vem com provas matemáticas que um kernel separado verifica. Neste vídeo, o que provou a Google? E como impedem que um agente mude os objetivos? Aqui está a resposta útil. Os modelos escrevem provas candidatas, e o Lean verifica as provas em relação a uma reivindicação aprovada por humanos sobre código compilado selecionado. Os humanos ainda são responsáveis pela reivindicação e pelas suposições.

0:21 Pode verificar o resultado sem acreditar no discurso de vitória do modelo. Uma verificação separada impede que a pergunta seja silenciosamente alterada. Vamos seguir até às definições. É terça-feira, dez de novembro, e este é o The Daily Diff. AlphaProof Code é o "framework" da Google para escrever especificações de software com orientação humana e gerar provas verificadas com agentes de IA. Este estudo visa o libsignal, a biblioteca Rust que implementa o protocolo de mensagens do Signal, dentro de um programa de linha de comando específico.

0:45 A Google anunciou o trabalho hoje. O seu artigo diz que cinco investigadores trabalharam durante quatro semanas. Os agentes escreveram as provas, enquanto os humanos dedicaram a maior parte do seu esforço às especificações. Os requisitos encontraram uma forma de se tornarem reuniões ainda mais caras. A especificação diz o que o programa deve fazer,

Como uma reivindicação se torna um alvo de prova?

0:59 o que um atacante controla e quais suposições o argumento precisa. Os revisores perguntam se captura a segurança com que as pessoas se preocupam. Uma resposta lindamente verificada a uma pergunta fraca deixa essa pergunta intacta. A equipa baseia-se em pesquisas anteriores sobre o "handshake" do Signal e o seu "ratchet" de chave de mensagem. Análises formais já estudaram esses designs. A reivindicação da Google conecta os seus argumentos de segurança a uma implementação compilada de uma biblioteca de produção não modificada, onde o design tem de sobreviver ao contacto com o código real. O diretor de tecnologia do Signal, Ehren Kret,

1:27 descreve uma expansão para além dos escopos menores de verificação anteriores. Os detalhes de implementação incluem mensagens fora de ordem e sessões arquivadas para mensagens atrasadas. O software real guarda os recibos que o seu diagrama elegante deitou fora. Os investigadores compilam a biblioteca Rust não modificada com o compilador padrão

Porquê provar o binário compilado?

1:41 num executável Arm sixty-four Linux. Os seus teoremas descrevem esse binário usando um modelo de instrução formal, abrindo caminho através da lacuna entre o código-fonte e o código de máquina otimizado. Um erro de compilador que quebre uma propriedade declarada tornaria o seu teorema falso. O compilador, portanto, deixa a base de confiança para este binário. Ainda confia no modelo de instrução e no verificador do Lean. O limite de confiança moveu-se e tem um endereço. Cerca de seis milhões e meio de linhas de prova verificada assentam em aproximadamente vinte e seis

2:06 mil linhas de especificação e semântica de instrução fidedignas. Estas são contagens de artefatos. Tratá-las como pontuações de inteligência é como classificar programadores pelo tamanho da sua pasta de módulos "node".

Quais propriedades de segurança sobreviveram à lacuna de implementação?

2:16 Os argumentos cobrem a confidencialidade e autenticação de mensagens, com sigilo para a frente e segurança pós-comprometimento sob modelos declarados. Essas duas últimas descrevem limites para danos por chaves roubadas e recuperação após novas trocas. Cada garantia tem condições sobre o atacante e a sessão. As primitivas criptográficas estão por trás de contratos fidedignos. A prova assume que essas rotinas se comportam conforme especificado e baseia-se em suposições de segurança criptográficas. Uma prova idealiza a criptografia; a outra raciocina sobre probabilidades de sucesso do atacante.

2:42 Ambas têm restrições sobre os cenários que cobrem. Pergunte qual versão, qual propriedade e quais suposições. Este resultado diz respeito ao "harness" de linha de comando dos investigadores. Mensagens de grupo são trabalho futuro, e o modelo computacional exclui o estado multi-dispositivo. Chamar todas as instalações do Signal de livres de bugs sai do âmbito do teorema. Os investigadores reintroduziram dois bugs do Signal previamente corrigidos em

A especificação pode rejeitar código quebrado?

3:02 cópias isoladas e compilaram-nas. Provas verificadas mostraram que esses binários violavam o teorema de segurança simbólica. Isso testou se a especificação poderia rejeitar implementações reais com falhas. A sua marca de verificação verde precisa de um teste vermelho. A Google publica as especificações e provas com instruções de verificação. O repositório diz que uma construção limpa leva horas e memória substancial. Ler o anúncio é consideravelmente mais fácil no portátil. O modelo de hardware e os contratos fidedignos ainda precisam de revisão.

3:26 Não reconstruí o enorme artefato para este episódio. Estamos a relatar o resultado publicado e os seus limites. Os de fora têm um caminho para inspecioná-lo, o que me importa mais do que mais uma volta da vitória da IA. Agora a armadilha.

Uma prova correta pode responder à pergunta errada?

3:36 Lean pode aceitar uma prova correta de uma declaração que pede quase nada. Suposições impossíveis podem tornar um teorema vazio. Alterar uma definição enterrada sob o teorema principal pode enfraquecer o objetivo. O artigo projeta verificações contra isso. O guardião mantém uma especificação aprovada retida que os agentes de prova não podem escrever. Podem propor correções através de um processo de alteração separado. O enfraquecimento da segurança é escalado como um bug potencial. A declaração de sucesso do provador não tem autoridade aqui.

4:00 Os humanos arbitram mudanças nas suposições fidedignas, diretamente ou através da sua política, e revisam as emendas após cada campanha. O julgamento dos especialistas permanece responsável. O agente pode solicitar uma atribuição diferente. Não pode dar a si mesmo uma nota positiva.

O que impede que os objetivos mudem?

4:13 Aqui está a verificação prometida. O comparador do Lean compara o teorema e todas as definições das quais depende com essa cópia aprovada protegida. Também verifica axiomas permitidos e reproduz a prova num kernel novo. O enfraquecimento silencioso de uma definição auxiliar, portanto, altera o que está a ser comparado. Uma prova aceite tem de estabelecer o alvo aprovado. Isso ainda deixa os humanos responsáveis por escolher um alvo forte e suposições honestas. Para o seu próprio fluxo de trabalho de IA, mantenha os critérios de aceitação fora das

4:37 permissões de edição do trabalhador e revise as alterações propostas separadamente. O resultado da Google torna essa separação concreta. O autor da prova faz o trabalho; o limite de verificação decide se conta. Se preferir ler isto a ouvir-me dizer, o "diff" chega à sua caixa de entrada todas as manhãs, gratuitamente em thedailydiff.dev, link abaixo. Então o veredito de hoje é SHIP IT.

Eu implementaria este fluxo de trabalho de prova?

4:54 Eu enviaria este fluxo de trabalho de prova verificada porque a reivindicação aprovada permanece separada do agente que produz a resposta. Eu manteria o escopo e as suposições anexados a cada resultado. Subscreva, clique no sino e diga-me nos comentários se o teria carimbado de forma diferente. E este é o "diff" de hoje. Eu sou o Niko da Axrisi. Faça a fusão com responsabilidade.

Fontes

1. AlphaProof Code: Verifying Signal's Security at the Machine-Code Level — technical scope, trusted base and gatekeepingSwarat Chaudhuri and colleagues / Google DeepMind and Google
2. Introducing AlphaProof Code — November 10 announcement and attributed Signal CTO responsePushmeet Kohli and Swarat Chaudhuri / Google DeepMind
3. Code-verification repository — initial commit, public artifacts and checking instructionsGoogle DeepMind / GitHub
4. The PQXDH Key Agreement Protocol — older official specification and prior-analysis contextEhren Kret and Rolfe Schmidt / Signal
5. The Double Ratchet Algorithm — Triple Ratchet sectionTrevor Perrin, Moxie Marlinspike and Rolfe Schmidt / Signal
6. Google DeepMind leadership — Demis Hassabis's relevant lab identityGoogle DeepMind
7. Demis Hassabis in 2025 — authentic portrait, cropped/resized/compressed and unflipped; no background removal or generated expression/detail; lab identity only, no authorship, proof writing, current reaction or endorsementChristopher P. Michel / Cmichel67 / Wikimedia Commons
8. Portrait licence — CC BY-SA 4.0; attribution, adaptation disclosure and ShareAlikeCreative Commons
9. Expanding Brain template — cropped/captioned artifact-count satire, brief transformed <=2s commentary; no benchmark, hosting licence, legal-clearance or blanket reuse claimImgflip / user-uploaded meme template
10. Tom and Jerry — Boomerang Official actual animated reaction, silent resized/captioned 1.875s excerpt; brief transformed process commentary, no actual researcher or executive reaction, hosting licence, legal-clearance or blanket reuse claimBoomerang Official / GIPHY / Tom and Jerry
11. Boomerang GIF source link — uploader-provided provenanceBoomerang
12. AlphaProof Code discussion — attention context, anonymous opinions excluded from factual proof claimsHacker News
13. Code-verification licence — Apache 2.0 for Google code, third-party licences retainedGoogle / GitHub