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

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.

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

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