# AlphaProof Code e Signal: probas de seguridade de código máquina verificadas e suposicións de confianza

Published: 2026-11-11

Google DeepMind informa de probas verificadas por máquina de propiedades de seguridade seleccionadas para un arnés de liña de comandos libsignal compilado. Lean verifica a proba, mentres que os humanos aproban a especificación e as súas suposicións. Un comparador separado verifica o teorema e todas as definicións dependentes co obxectivo aprobado.

Canonical: https://thedailydiff.dev/gl/video/2026-11-10-signal-machine-proof/

## Que abrangue este vídeo

- Os axentes de intelixencia artificial producen probas candidatas; o kernel de Lean verifica se establecen a afirmación formal aprobada por humanos.
- O obxectivo verificado é un arnés CLI de libsignal compilado particular, con semántica de confianza e contratos criptográficos.
- Probar o binario compilado elimina o compilador de Rust da base de confianza para as propiedades declaradas dese binario.
- Os investigadores informan de dúas reintroducións illadas de erros previamente solucionados que violan o seu teorema de seguridade simbólico.
- O comparador verifica o teorema e cada definición dependente fronte a unha especificación aprobada protexida; as modificacións pasan por un proceso de revisión separado.

## Preguntas e respostas

### Que probou AlphaProof Code sobre a implementación de Signal?

Google DeepMind informa de probas verificadas de propiedades de seguridade seleccionadas para un arnés de liña de comandos libsignal compilado. O artigo técnico abrangue a confidencialidade e a autenticación das mensaxes, con segredo cara adiante e seguridade post-compromiso baixo modelos establecidos. O resultado mantén as condicións sobre o atacante, a sesión e as suposicións criptográficas. O seu alcance exclúe unha garantía xeral para cada aplicación ou instalación de Signal.

### Quen decide que debe establecer unha proba de seguridade xerada por intelixencia artificial?

Os revisores humanos aproban a especificación e as súas suposicións. O artigo técnico de Google DeepMind describe axentes que elaboran especificacións con orientación humana e revisores que proban se as declaracións capturan propiedades de seguridade significativas. Lean verifica a lóxica da proba resultante. Os humanos seguen sendo responsables de elixir un obxectivo forte, revisar as suposicións e xulgar os cambios propostos na especificación aprobada.

### Por que verificar o código máquina compilado en lugar de confiar no compilador de Rust?

Unha proba sobre o binario compilado establece as propiedades declaradas para ese artefacto directamente. O artigo de Google DeepMind explica que un erro do compilador que viole unha desas propiedades faría que o teorema fose falso. Polo tanto, o compilador de Rust deixa a base de confianza para esta afirmación. A proba aínda confía no modelo de instrucións, no kernel de Lean e nos contratos criptográficos especificados.

### Como evita o comparador que un axente de proba debilite o seu obxectivo?

O comparador verifica o teorema e cada definición da que depende fronte a unha especificación aprobada protexida. O artigo de Google DeepMind di que os axentes de proba non poden escribir nesa copia reservada. O verificador tamén verifica os axiomas permitidos e reproduce a proba nun novo kernel. As modificacións propostas á especificación seguen un proceso de revisión separado, mentres que os humanos seguen sendo responsables da forza do obxectivo.

### Cal foi o veredicto de The Daily Diff sobre o fluxo de traballo de proba verificada?

O veredicto de The Daily Diff foi SHIP IT. Niko enviaría o fluxo de traballo de proba verificada porque a afirmación aprobada permanece separada do axente que produce a resposta. Mantería o alcance e as suposicións anexas a cada resultado. O episodio informa do artefacto de proba publicado por Google sen reconstruílo de forma independente e aproba o fluxo de traballo dentro deses límites de evidencia.

## Capítulos

- 0:00 Quen verifica unha proba de seguridade da intelixencia artificial?
- 0:57 Como se converte unha afirmación nun obxectivo de proba?
- 1:39 Por que probar o binario compilado?
- 2:16 Que propiedades de seguridade sobreviviron á brecha de implementación?
- 2:59 Pode a especificación rexeitar o código defectuoso?
- 3:36 Pode unha proba correcta responder á pregunta equivocada?
- 4:13 Que atrapa os obxectivos cambiantes?
- 4:53 Enviaría este fluxo de traballo de proba?

## Transcrición traducida

Traducido da narración orixinal en inglés. O audio e os subtítulos dispoñibles son controlados por YouTube.

### Quen verifica unha proba de seguridade da intelixencia artificial?

0:00 Unha auditoría de seguridade de intelixencia artificial aínda soa como confiar nun chatbot. O novo resultado de Signal de Google vén con probas matemáticas que un kernel separado verifica. Neste vídeo, que probou Google? E como evitan que un axente cambie os obxectivos? Aquí está a resposta útil. Os modelos escriben probas candidatas e Lean verifica as probas con respecto a unha afirmación aprobada por humanos sobre un código compilado seleccionado. Os humanos seguen sendo os propietarios da afirmación e das suposicións.

0:21 Podes verificar o resultado sen crer o discurso de vitoria do modelo. Unha verificación separada detecta o cambio silencioso da pregunta. Seguirémolo ata as definicións. É martes, dez de novembro, e este é The Daily Diff. AlphaProof Code é o marco de Google para escribir especificacións de software con orientación humana e xerar probas verificadas con axentes de intelixencia artificial. Este estudo céntrase en libsignal, a biblioteca de Rust que implementa a protocolo de mensaxería de Signal, dentro dun programa de liña de comandos particular.

0:45 Google anunciou o traballo hoxe. O seu artigo di que cinco investigadores traballaron durante catro semanas. Os axentes escribiron as probas, mentres que os humanos dedicaron a maior parte do seu esforzo ás especificacións. Os requisitos atoparon un xeito de converterse en reunións aínda máis caras. A especificación di o que o programa debe facer,

### Como se converte unha afirmación nun obxectivo de proba?

0:59 o que controla un atacante e as suposicións que o argumento necesita. Os revisores preguntan se captura a seguridade que lles importa á xente. Unha resposta perfectamente verificada a unha pregunta débil deixa esa pregunta intacta. O equipo baséase en investigacións anteriores sobre o handshake de Signal e a súa ratchet de clave de mensaxe. As análises formais xa estudaron eses deseños. A afirmación de Google conecta os seus argumentos de seguridade cunha implementación compilada dunha biblioteca de produción sen modificar, onde o deseño ten que sobrevivir ao contacto con código real. O director de tecnoloxía de Signal, Ehren Kret,

1:27 describe unha expansión máis aló dos alcances máis pequenos da verificación anterior. Os detalles de implementación inclúen mensaxes fóra de orde e sesións arquivadas para mensaxes atrasadas. O software real garda os recibos que o seu elegante diagrama tirou á basura. Os investigadores compilan a biblioteca de Rust sen modificar co compilador

### Por que probar o binario compilado?

1:41 estándar nun executable de Arm sixty-four Linux. Os seus teoremas describen ese binario usando un modelo de instrución formal, abarcando a brecha entre o código fonte e o código máquina optimizado. Un erro do compilador que rompa unha propiedade establecida faría que o seu teorema fose falso. Polo tanto, o compilador deixa a base de confianza para este binario. Segues confiando no modelo de instrucións e no verificador de Lean. O límite de confianza moveuse e ten un enderezo. Cerca de seis millóns e medio de liñas de proba verificada baséanse en aproximadamente vinte e seis mil

2:06 liñas de especificación e semántica de instrución de confianza. Estes son recuentos de artefactos. Tratalos como puntuacións de intelixencia é como clasificar os desenvolvedores polo tamaño da súa carpeta de módulos de nodo.

### Que propiedades de seguridade sobreviviron á brecha de implementación?

2:16 Os argumentos abarcan a confidencialidade e a autenticación das mensaxes, con segredo cara adiante e seguridade post-compromiso baixo modelos establecidos. Esas dúas últimas describen os límites no dano das claves roubadas e a recuperación despois de novos intercambios. Cada garantía ten condicións sobre o atacante e a sesión. As primitivas criptográficas están detrás de contratos de confianza. A proba asume que esas rutinas se comportan como se especifica e baséase en suposicións de seguridade criptográfica. Unha proba idealiza a criptografía; a outra razoa sobre as probabilidades de éxito do atacante. Ambas teñen restricións sobre os escenarios que cobren.

2:42 Pregunta que compilación, que propiedade e que suposicións. Este resultado refírese ao arnés de liña de comandos dos investigadores. A mensaxería de grupo é un traballo futuro, e o modelo computacional exclúe o estado multi-dispositivo. Chamar a cada instalación de Signal libre de erros sae do teorema. Os investigadores reintroduciron dous erros de Signal previamente solucionados en copias illadas e compiláronos.

### Pode a especificación rexeitar o código defectuoso?

3:02 As probas verificadas mostraron que eses binarios violaban o teorema de seguridade simbólico. Isto probou se a especificación podía rexeitar implementacións reais defectuosas. A túa marca de verificación verde necesita unha proba vermella. Google publica as especificacións e as probas con instrucións de verificación. O repositorio di que unha compilación limpa leva horas e unha memoria substancial. Ler o anuncio é considerablemente máis fácil no portátil. O modelo de hardware e os contratos de confianza aínda necesitan revisión. Non reconstruín o enorme artefacto para este episodio.

3:26 Estamos a informar do resultado publicado e dos seus límites. Os forasteiros teñen un camiño para inspeitalo, o que me importa máis que outra volta de vitoria da intelixencia artificial. Agora a trampa. Lean pode aceptar unha proba correcta dunha afirmación que pide case nada.

### Pode unha proba correcta responder á pregunta equivocada?

3:36 As suposicións imposibles poden facer un teorema vacuous. Cambiar unha definición enterrada debaixo do teorema principal pode debilitar o obxectivo. O artigo deseña verificacións contra isto. O gardián mantén unha especificación aprobada reservada á que os axentes de proba non poden escribir. Poden propoñer correccións a través dun proceso de modificación separado. O debilitamento da seguridade escálase como un posible erro. A declaración de éxito do probador non ten autoridade aquí. Os humanos xulgan os cambios nas suposicións de confianza,

4:00 directamente ou a través da súa política, e revisan as modificacións despois de cada campaña. O xuízo experto segue sendo o responsable. O axente pode solicitar unha asignación diferente. Non pode outorgarse unha nota de aprobación. Aquí está a verificación prometida.

### Que atrapa os obxectivos cambiantes?

4:13 O comparador de Lean compara o teorema e todas as definicións das que depende coa copia aprobada protexida. Tamén verifica os axiomas permitidos e reproduce a proba nun novo kernel. Polo tanto, debilitar silenciosamente unha definición auxiliar cambia o que se está comparando. Unha proba aceptada ten que establecer o obxectivo aprobado. Iso aínda deixa aos humanos a responsabilidade de elixir un obxectivo forte e suposicións honestas. Para o teu propio fluxo de traballo de intelixencia artificial, mantén os criterios de aceptación fóra dos permisos de edición do traballador e revisa os cambios propostos por separado.

4:37 O resultado de Google fai que esa separación sexa concreta. O escritor da proba fai o traballo; o límite de verificación decide se conta. Se prefires ler isto que escoitarmo, o diff chega á túa caixa de entrada todas as mañás, de balde en the daily diff dot dev, ligazón a continuación. Así que o veredicto de hoxe é SHIP IT. Eu enviaría este fluxo de traballo de proba verificada porque a afirmación aprobada permanece

### Enviaría este fluxo de traballo de proba?

4:54 separada do axente que produce a resposta. Mantería o alcance e as suposicións anexas a cada resultado. Subscríbete, preme a campá e dime nos comentarios se o terías selado de xeito diferente. E ese é o diff de hoxe. Son Niko de Axrisi. Fusiona de xeito responsable. Unha auditoría de seguridade de intelixencia artificial aínda soa como confiar nun chatbot.

## Fontes

- [AlphaProof Code: Verifying Signal's Security at the Machine-Code Level — technical scope, trusted base and gatekeeping](https://google-deepmind.github.io/code-verification/) — Swarat Chaudhuri and colleagues / Google DeepMind and Google
- [Introducing AlphaProof Code — November 10 announcement and attributed Signal CTO response](https://deepmind.google/blog/introducing-alphaproof-code/) — Pushmeet Kohli and Swarat Chaudhuri / Google DeepMind
- [Code-verification repository — initial commit, public artifacts and checking instructions](https://github.com/google-deepmind/code-verification) — Google DeepMind / GitHub
- [The PQXDH Key Agreement Protocol — older official specification and prior-analysis context](https://signal.org/docs/specifications/pqxdh/) — Ehren Kret and Rolfe Schmidt / Signal
- [The Double Ratchet Algorithm — Triple Ratchet section](https://signal.org/docs/specifications/doubleratchet/) — Trevor Perrin, Moxie Marlinspike and Rolfe Schmidt / Signal
- [Google DeepMind leadership — Demis Hassabis's relevant lab identity](https://deepmind.google/about/) — Google DeepMind
- [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 endorsement](https://commons.wikimedia.org/wiki/File:Demis_Hassabis_in_2025_by_Christopher_Michel.jpg) — Christopher P. Michel / Cmichel67 / Wikimedia Commons
- [Portrait licence — CC BY-SA 4.0; attribution, adaptation disclosure and ShareAlike](https://creativecommons.org/licenses/by-sa/4.0/) — Creative Commons
- [Expanding Brain template — cropped/captioned artifact-count satire, brief transformed &lt;=2s commentary; no benchmark, hosting licence, legal-clearance or blanket reuse claim](https://imgflip.com/memetemplate/Expanding-Brain) — Imgflip / user-uploaded meme template
- [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 claim](https://giphy.com/gifs/boomerangtoons-mad-upset-1gdkNV0hroZjOXSHOU) — Boomerang Official / GIPHY / Tom and Jerry
- [Boomerang GIF source link — uploader-provided provenance](https://boomtn.co/GIPHY) — Boomerang
- [AlphaProof Code discussion — attention context, anonymous opinions excluded from factual proof claims](https://news.ycombinator.com/item?id=50439193) — Hacker News
- [Code-verification licence — Apache 2.0 for Google code, third-party licences retained](https://github.com/google-deepmind/code-verification/blob/808b4b7ffef198e6a91f71ed776d641a1c236882/LICENSE) — Google / GitHub
