AlphaProof Code : preuve machine‑vérifiée du code libsignal de Signal

Le 10 novembre 2026, DeepMind a présenté AlphaProof Code, un système d’agents IAIntelligence artificielleEnsemble de techniques permettant à des machines d'accomplir des tâches nécessitant habituellement certaines capacités humaines, comme la reconnaissance, la prédiction ou la prise de décision. capables de générer des preuves formelles, vérifiées par le moteur Lean, pour le code compilé de la bibliothèque cryptographique libsignal utilisée par l’application de messagerie Signal. Le travail, mené par une équipe de cinq chercheurs pendant quatre semaines, constitue la première démonstration de preuve de sécurité au niveau du protocole appliquée directement à du code déployé à grande échelle.

Une démarche qui s’appuie sur le code réel

Contrairement aux vérifications qui se limitent à un modèle abstrait du protocole, les chercheurs ont encapsulé les crates libsignal v0.105.4 et SPQR v1.6.0 dans une petite interface en ligne de commande, puis ont compilé un exécutable statiquement lié pour l’architecture AArch64 sous Linux avec le compilateur rustc standard. Le résultat est une preuve formelle couvrant le code « one‑to‑one » responsable de l’établissement de session (handshake PQXDH) et du mécanisme Triple Ratchet pour le chiffrement de messages.

Comment les agents ont partagé la charge

Les cinq chercheurs ont fait tourner en continu des équipes d’agents sur leurs postes de travail. Chaque campagne mobilisait entre 40 et 80 agents pendant 24 à 72 heures, orchestrés par un coordinateur qui gérait les rôles d’architecte, d’intégrateur et de chef d’équipe. Les agents, alimentés par les modèles Gemini 4 Carbon et Claude Opus 5.5, ont rédigé les spécifications, les ont revues (en croisant deux familles de modèles) puis ont généré l’ensemble du code de preuve – environ 6,5 millions de lignes Lean – sans qu’aucun auteur n’écrive manuellement une ligne de preuve.

Les humains sont intervenus aux points critiques : choix des propriétés de sécurité, résolution des ambiguïtés, validation finale des spécifications et approbation de toute modification des hypothèses de confiance. Un « gatekeeper » acceptait une preuve uniquement après que le noyau Lean l’avait vérifiée et qu’un comparateur confirmait la concordance avec la spécification humaine approuvée, y compris chaque définition transitive.

Portée des garanties obtenues

Les preuves couvrent quatre propriétés essentielles :

• Confidentialité permanente (forward secrecy) : les messages précédents restent protégés même si l’état actuel est compromis.
• Authentification du partenaire de communication.
• Sécurité post‑compromission : capacité du protocole à récupérer après une fuite de clés.
• Secret du handshake : même après une éventuelle rupture future du Diffie‑Hellman, le secret du premier échange reste préservé.

Deux arguments distincts soutiennent ces propriétés : dix théorèmes symboliques sous des hypothèses cryptographiques idéalisées, et une preuve computationnelle qui borne l’avantage d’un attaquant selon les hypothèses classiques. Les chercheurs ont également testé la capacité du cadre à détecter des erreurs réelles en réintroduisant deux bugs déjà corrigés dans libsignal (faible état et petit sous‑groupe). Dans les deux cas, la preuve symbolique a échoué, confirmant que les spécifications pouvaient identifier des vulnérabilités.

Limites et perspectives

Les garanties restent circonscrites : elles ne couvrent pas la génération de clés, la messagerie de groupe, les canaux auxiliaires (side‑channels) ni la synchronisation multi‑appareils. Certaines primitives cryptographiques de bas niveau et quelques routines de la bibliothèque sont traitées comme des contrats de confiance, ce qui signifie que la validité finale dépend de ces hypothèses, du noyau Lean et de la sémantique AArch64.

De plus, les preuves ne valident pas le renforcement post‑quantique apporté par SPQR — la preuve computationnelle se limite aux attaquants classiques, tandis que les théorèmes symboliques laissent l’attaquant choisir les clés SPQR.

Les prochaines étapes annoncées visent à réduire la base de confiance (vérifier davantage de routines, relier les contrats cryptographiques à des implémentations formellement vérifiées) et à étendre la couverture aux communications de groupe, à l’envoi scellé (sealed‑sender) et aux protocoles côté serveur. L’objectif à plus long terme est de pouvoir vérifier chaque nouvelle version de libsignal avant sa mise en production, mais cela reste pour l’instant un projet de recherche, pas une promesse de déploiement immédiat.

Pourquoi cela compte pour les utilisateurs de Signal

En publiant les spécifications, les artefacts de vérification et les procédures de reconstruction, DeepMind offre à la communauté un point d’ancrage pour auditer indépendamment la sécurité du code. Le directeur technique de Signal, Ehren Kret, a souligné que ces travaux renforcent la confiance dans les garanties de confidentialité de l’application. Pour les développeurs et les analystes de sécurité, il s’agit d’un modèle de collaboration homme‑machine où l’IA exécute la partie la plus fastidieuse (la génération de preuves) tandis que la supervision humaineHuman in the LoopApproche intégrant une intervention humaine dans le fonctionnement, la validation ou les décisions d'un système automatisé. garantit la pertinence des hypothèses.

Ainsi, AlphaProof Code montre qu’il est possible d’allier l’efficacité des agents IA à la rigueur des preuves formelles, ouvrant la voie à des vérifications similaires pour d’autres protocoles critiques. Le véritable défi reste de traduire ces garanties théoriques en protections tangibles pour les utilisateurs finaux, notamment en élargissant la portée aux scénarios multi‑appareils et aux futures menaces post‑quantiques.