Google DeepMind presentó AlphaProof Code el 10 de noviembre de 2026. Recuperamos hoy este anuncio: combina agentes de IA con revisión humana y el verificador Lean para demostrar propiedades de seguridad del código de libsignal. El resultado se refiere a propiedades y supuestos definidos; no certifica toda la aplicación Signal ni cualquier despliegue que utilice la biblioteca.
Qué aporta frente a revisar el diseño
Según el anuncio, las personas revisan las especificaciones matemáticas y agentes impulsados por Gemini Carbon construyen las pruebas. Lean comprueba esas pruebas. La aportación es conectar garantías del protocolo con código compilado, reduciendo la distancia entre un diseño criptográfico y su implementación.
DeepMind informa también de una comprobación con dos errores históricos ya corregidos, reintroducidos en una versión aislada: el sistema produjo pruebas de que esas versiones vulneraban las propiedades evaluadas. Son resultados del equipo investigador, no pruebas realizadas por Puntoes.
El binario y los supuestos importan
El trabajo técnico describe un pequeño programa de ejecución que enlaza libsignal, compilado con rustc para AArch64 Linux. Las pruebas cubren propiedades como confidencialidad, autenticidad, secreto hacia adelante y seguridad tras un compromiso, dentro de los modelos definidos en el estudio.
Los autores distinguen el modelo simbólico, que idealiza las primitivas criptográficas, del computacional, que formula límites a la ventaja de un atacante. La confianza sigue apoyándose en el núcleo de Lean, las especificaciones, la semántica de la máquina y contratos para determinadas rutinas. Los canales laterales quedan fuera del alcance señalado. Tampoco debe confundirse la garantía simbólica sobre el intercambio inicial frente a un atacante cuántico con protección poscuántica integral de todo el sistema.
Una prueba puede ser válida y dejar preguntas abiertas
Ejemplo hipotético, no ejecutado: un equipo verifica que un componente respeta una propiedad de confidencialidad bajo un modelo de ejecución. Antes de usar esa prueba como argumento sobre su producto, debe comprobar que corresponde a su binario y que las hipótesis representan su entorno. Un error en la gestión de permisos de otra parte de la aplicación seguiría exigiendo su propio análisis.
Para evaluar trabajos así, pediríamos tres cosas juntas: la propiedad demostrada, el artefacto al que se aplica y los supuestos aceptados. Esa lectura complementa lo que explicamos sobre las pruebas de Claude y Theorem sobre software RISC-V; son investigaciones distintas, sin una comparación de rendimiento entre ellas.
El volumen de una prueba generada tampoco indica por sí solo cuánto producto queda protegido. La pregunta útil es qué comportamiento excluye el teorema y qué componentes siguen dependiendo de confianza o revisión. No hemos reproducido AlphaProof Code ni medido sus costes. El anuncio presenta investigación y artefactos de verificación; no lo tratamos como un servicio general listo para verificar cualquier aplicación.