AlphaProof-code bewees dat de crypto van Signal correct was — op het niveau van de gecompileerde binary

Zes en een half miljoen regels Lean, in vier weken geproduceerd door agentteams die geen enkele mens heeft helpen schrijven. Dat is het opvallendste cijfer dat Google DeepMind op 10 november 2026 publiceerde voor AlphaProof Code, een agentisch framework voor formele verificatie dat het lab gebruikte om de cryptografische kern van het Signal-protocol machinaal te controleren — en, ongewoon, om die te controleren op het niveau van de gecompileerde AArch64-binary in plaats van het ontwerpdocument daarboven. De modellen die het werk hebben gedaan, zijn een andere kwestie. één API-sleutel tegen de lijstprijs van de provider met 0% opslag De engine van de bewijsagenten is iets wat wij niet aanbieden.

Het raamwerk is geen model dat je kunt aanroepen. Het is een harnas: menselijke experts beslissen wat waar moet zijn, een mix van modellen zet die doelen om in Lean-specificaties, en dan vullen teams van bewijsschrijvende agenten — de blog noemt G​emini Carbon als de motor — de bewijzen in totdat de kernel van Lean ze accepteert. Wat samen met de aankondiging is uitgebracht, is de artefactset, op github.com/google-deepmind/code-verification, en een technisch artikel dat veel openhartiger is over de grenzen van het resultaat dan de blogpost. Het meeste van wat volgt, komt uit dat artikel, want in dat artikel staan de interessante cijfers.

Wat werd er eigenlijk bewezen, en waartegen?

Het doelwit is libsignal v0.105.4 met spqr v1.6.0, gebouwd door stock rustc 1.98.1, statisch gelinkt tegen musl, en uitgegeven als één enkele AArch64 Linux-executable. Dat detail is belangrijker dan welke benchmark dan ook: de bewijzen gaan over de bytes die op een telefoon zouden draaien, niet over een Rust-functie waarvan men erop vertrouwt dat een compiler die trouw vertaalt. Het team heeft ongeveer 560 KB libsignal-broncode geverifieerd, ongeveer 140.000 AArch64-instructies, en deed dat door een Lean-model van de instructieset te schrijven — 467 instructies en 31 systeemaanroepen, in 7.578 regels — en vervolgens te bewijzen dat het echte ELF-image, geladen en uitgevoerd onder dat model, de veiligheidseigenschappen behoudt.

De eigenschappen zijn precies wat een protocol-engineer zou vragen. Tien symbolische stellingen dekken forward secrecy, post-compromise security, geheimhouding voor initiator en responder, authenticatie, en vijf corollaria van PQXDH's Stelling 1. Het hoofdresultaat heet signal_session_secure_placed. Er is ook een computationeel traject met een concrete grens, en de twee trajecten gebruiken verschillende aanvallersmodellen: de symbolische kant (Dolev–Yao, via het DyLean-framework) dekt zelfs een kwantumaanvaller die Diffie–Hellman na de handshake breekt, terwijl de computationele kant alleen klassieke aanvallers dekt.

Waar de zes miljoen regels naartoe gaan

‘Meer dan zes miljoen regels’ is de formulering van de blog, en die is accuraat maar grof. De uitsplitsing in het paper is de nuttige, en het is de moeite waard die te lezen als een kostentabel in plaats van als opschepperij:

• Bewijzen voor het binaire bestand — 5,3 miljoen regels, het grootste deel van het werk, met de semantiek van de machinecode en de verfijning van het symbolische model tot aan het uitvoerbare bestand.

• Computationele bewijzen — ongeveer 860.000 regels.

• Symbolische bewijzen — ongeveer 350.000 regels.

• Bug-weerleggingsbewijzen — ongeveer 140.000 regels, voor de twee opzettelijk opnieuw geïntroduceerde kwetsbaarheden die hieronder worden beschreven.

• Allocator-bewijzen — ongeveer 70.000 regels.

Bijna zeven miljoen regels als je commentaar en lege regels meetelt, wat het paper wel doet en de blog niet. Hoe dan ook, de verhouding die ertoe doet is die tussen het bewijs en datgene wat bewezen wordt: 6,5 miljoen regels Lean om eigenschappen vast te stellen van een binaire bestand van 560 KB. Die verhouding is de eerlijke maatstaf voor hoe ver deze techniek nog van routine verwijderd is, en het getal dat je moet citeren wanneer iemand vraagt of formele verificatie goedkoop is geworden.

De vertrouwde basis is kleiner dan het bewijs, en dat is nu juist het punt.

Een bewijs is slechts zo goed als wat het veronderstelt. Het artikel is hier specifiek over, en die specificiteit onderscheidt het van een persbericht. De vertrouwde specificaties beslaan ongeveer 18.000 regels (28.000 met documentatie), de AArch64-semantiek ongeveer 8.000, en de Lean-encoding van de machinecode ongeveer 95.000. Zevenendertig routines worden vervangen door contracten in plaats van geverifieerd — SHA-256- en SHA-512-compressie, AES-256-CBC, X25519, de Edwards-curvebewerkingen, Kyber1024 en ML-KEM-768, en libcrux HMAC. Achttien panic-entrypunten worden eveneens verondersteld in plaats van bewezen.

De bewering is dus niet "alles is bewezen". De bewering is dat de logica van het cryptografische protocol, de sessietoestandsmachine en de verfijning van die logica naar de daadwerkelijk uitgevoerde instructies bewezen zijn, terwijl de onderliggende primitieven worden vertrouwd zoals elk verificatieproject zijn primitieven vertrouwt. De Rust-compiler bevindt zich met name niet in de trusted base — het team vermeed de noodzaak om die te vertrouwen door op machinetaalniveau te redeneren, dezelfde truc waarmee ze een geverifieerde compiler volledig omzeilen. Ter context van de schaal noemt het artikel seL4 op ongeveer 20 persoonsjaren en CompCert op ongeveer 6.

Twee bugs, met opzet teruggezet

Een verificatiesysteem dat alleen maar "correct" zegt, is niet te testen. Dus nam het team twee kwetsbaarheden die eerder in Signal's code waren gevonden en verholpen — een zwakke-toestandbug en een kleine-subgroepbug — opnieuw op in een geïsoleerde kopie en voerde de pipeline opnieuw uit. In beide gevallen produceerde AlphaProof Code een machinaal gecontroleerd bewijs dat de versie met de bug niet voldoet aan het beveiligingstheorema: de symbolische uitspraak komt uit op ¬Sec(Asm_bug).

Het artikel voegt een voorbehoud toe dat een marketingpagina zou hebben geschrapt: het weerleggen van de computationele stelling voor die bugs is "veel moeilijker" en werd open gelaten. Met andere woorden, de negatieve test werkt netjes op het symbolische spoor en werkt nog niet op het computationele. Dat is precies het soort asymmetrie dat een lezer zou moeten kennen voordat hij het raamwerk als bugdetector behandelt.

Hoe de agents werden uitgevoerd

Vijf onderzoekers, vier weken lang, die elk agents nonstop lieten draaien. Het schrijven van de bewijzen zelf werd gedaan door teams van 40 tot 80 agents, die tussen 24 en 72 uur draaiden op één machine per team, met een superviserende agent boven de teamorkestrator. Een poortwachteragent controleert elke inzending met comparator tegen een achtergehouden kopie van de specificatie en tegen de kernel van Lean — een verdediging tegen een agent die een subtiel verzwakte versie bewijst van wat gevraagd was.

Het menselijke werk was vooraf geconcentreerd op de specificaties. Elke specificatie werd door een expert beoordeeld voordat het bewijswerk begon, en de eigen auditronde van de agents markeerde ongeveer 1% van de codebase voor menselijke aandacht. Geen mens schreef bewijscode. Het artikel is ook openhartig over de engineering: een schone build kan meerdere uren duren, en vroeg in het traject dwong een kleine broncodewijziging of een opnieuw gecompileerde binary tot omvangrijke bewijsreparaties, en er is "ruime mogelijkheid tot optimalisatie" in zowel de door AI gegenereerde bewijzen als de bewijstechnieken zelf.

Wat de bewijzen niet dekken

De beperkingen zijn lang genoeg om de belangrijkste sectie van het artikel te zijn, en ze worden ronduit vermeld. Er is geen post-kwantumgarantie vastgesteld voor de herstellende eigenschap van SPQR — de ratchet-stellingen gaan ervan uit dat de aanvaller SPQR-sleutels kiest. Payload-privacy is niet bewezen. Responder-authenticatie is niet bewezen voor het eerste bericht van een handshake die nooit wordt gepromoveerd. Het model staat één sessie per promotie toe, vaste berichtlengtes, geen status voor meerdere apparaten, en trust-on-first-use-identiteitssleutels.

Er is ook een grens die nietszeggend wordt. De term voor 8-byte-MAC-vervalsing is minstens 2⁻⁶⁴ per poging en groeit kwadratisch met het aantal berichten en epochs, wat betekent dat de grens niets meer zegt voor één sessie van ongeveer 25.000 berichten, of voor 2²⁰ sessies van 2¹⁰ berichten. En het onderwerp van het bewijs is de build van libsignal-cli door het team, die als een nieuw proces draait — niet de Signal-app op je telefoon. Verschillende omgevingsaannames worden informeel beargumenteerd in plaats van bewezen.

Er is geen API, geen prijs en geen model om aan te roepen

Dit is het onderdeel dat iedereen die via een modelleaderboard binnenkomt, zal teleurstellen. AlphaProof Code is een onderzoeksframework en een gepubliceerde set artefacten. Er is geen endpoint, geen tariefkaart per token, geen wachtlijst en geen gewichten: de repository bevat de Lean-ontwikkeling, de AArch64-semantiek, de libsignal-binding en de specificaties, geen checkpoint. De blog zegt dat de artefacten open source zijn gemaakt; de landingspagina vermeldt geen licentie, wat het controleren waard is voordat iemand van plan is erop voort te bouwen.

De modellen die het werk hebben gedaan, zijn een andere kwestie. Het artikel noemt G​emini 4 Carbon voor de bewijsagenten en zegt dat Claude Opus 5.5 samen met andere modellen werd gebruikt voor het opstellen en beoordelen van specificaties. Claude Opus 5.5 staat vandaag in de catalogus van OrcaRouter voor $4 per miljoen inputtokens en $20 per miljoen outputtokens, waarbij de lijstprijs van de provider wordt doorgegeven tegen 0% markup — dus als de praktische conclusie die je wilt "een specificatie-opstelllus draaien met het model dat het artikel gebruikte" is, dan is dat gewoon een normale API-call, en een prijswijziging van de leverancier komt dezelfde dag nog bij ons terecht. De engine van de bewijsagenten is niet iets wat wij aanbieden, en niets hier impliceert dat wij AlphaProof Code zelf hosten.

Waarom dit een grotere zaak is dan het Signal-resultaat

De Signal-verificatie is op zichzelf indrukwekkend — de eerste formele verificatie van een breed uitgerolde protocolimplementatie met welke methode dan ook, met of zonder AI, volgens DeepMind, en de eerste keer dat AI een uitgerold cryptografisch protocol op dit detailniveau heeft geverifieerd. Maar de overdraagbare claim is de workflow. Een team van vijf, in vier weken, met een specificatiereviewstap en een agent-poortwachter, produceerde een bewijscorpus dat voorheen een project van meerdere jaren zou zijn geweest. Als die verhouding zelfs maar losjes standhoudt, verandert de verzameling systemen die zich verificatie kunnen veroorloven: firmware van medische apparaten, software voor elektriciteitsnetten, het soort code dat momenteel een code review en een gebed krijgt.

{{1}}Of het standhoudt{{/1}} is ongetest. {{2}}De crypto van Signal is uitzonderlijk goed gespecificeerd{{/2}}, het team had {{3}}Signals eigen ingenieurs de methodologie laten beoordelen{{/3}}, en de primitieven werden {{4}}uitbesteed in plaats van geverifieerd{{/4}}. {{5}}Het volgende systeem zal niet zo tegemoetkomend zijn{{/5}}. {{6}}De eigen framing van het paper — formele verificatie combineren met geautomatiseerde verdedigingsagenten zoals CodeMender — is de eerlijke vorm van de pitch{{/6}}: {{7}}verificatie vertelt je wat waar is, en iets anders moet oplossen wat dat niet is{{/7}}.

Wat te kijken

Drie dingen zouden dit van een mijlpaalartikel naar een industriële techniek tillen. Een tweede, onafhankelijke codebase die door iemand buiten G​oogle is geverifieerd, idealiter een waarbij de specificatie vanaf nul moest worden geschreven in plaats van aangepast uit een bestaande analyse. Een kostencijfer — agenturen, acceleratoruren, dollars — omdat vier weken en teams van 40 tot 80 agenten geen eenheid is waar een engineeringmanager tegen kan budgetteren. En de weerlegging van bugs op het computationele spoor, die het artikel openlaat en die het verschil vormt tussen een systeem dat eigenschappen bewijst en een systeem dat je ook computationeel kan vertellen dat een specifiek binair bestand stuk is.

Tot dan: lees de artefactrepository in plaats van de aankondiging. De bewijzen staan daar, Lean controleert ze, en het artikel vertelt je precies wat ze aannemen.