Il codice AlphaProof ha dimostrato la correttezza della crittografia di Signal — a livello del binario compilato.

Sei milioni e mezzo di righe di Lean, prodotte in quattro settimane, da team di agenti che nessun essere umano ha aiutato a scrivere. È il numero di punta che Google DeepMind ha pubblicato il 10 novembre 2026 per AlphaProof Code, un framework agentico per la verifica formale che il laboratorio ha usato per verificare automaticamente il nucleo crittografico del protocollo Signal — e, cosa insolita, per verificarlo al livello del binario AArch64 compilato anziché del documento di progettazione che sta sopra. I modelli che hanno svolto il lavoro sono una questione diversa. una chiave API al prezzo di listino del provider con 0% di ricarico Il motore degli agenti di dimostrazione non è qualcosa che forniamo come servizio.

Il framework non è un modello che puoi chiamare. È un harness: esperti umani decidono cosa deve essere vero, un mix di modelli trasforma quegli obiettivi in specifiche Lean, e poi squadre di agenti che scrivono dimostrazioni — il blog indica G​emini Carbon come motore — completano le dimostrazioni finché il kernel di Lean non le accetta. Insieme all'annuncio sono stati rilasciati il set di artefatti, su github.com/google-deepmind/code-verification, e un articolo tecnico che è molto più franco sui limiti del risultato di quanto non sia il post del blog. La maggior parte di quanto segue proviene da quell'articolo, perché è nell'articolo che si trovano i numeri interessanti.

Che cosa è stato effettivamente dimostrato, e contro che cosa

Il target è libsignal v0.105.4 con spqr v1.6.0, compilato con rustc 1.98.1 standard, collegato staticamente a musl e generato come un singolo eseguibile Linux AArch64. Questo dettaglio conta più di qualsiasi benchmark: le dimostrazioni riguardano i byte che verrebbero eseguiti su un telefono, non una funzione Rust di cui ci si fida che il compilatore traduca fedelmente. Il team ha verificato circa 560 KB di codice sorgente di libsignal, circa 140.000 istruzioni AArch64, e lo ha fatto scrivendo un modello Lean del set di istruzioni — 467 istruzioni e 31 chiamate di sistema, in 7.578 righe — e poi dimostrando che l'immagine ELF reale, caricata ed eseguita secondo quel modello, preserva le proprietà di sicurezza.

Le proprietà sono quelle che un ingegnere dei protocolli chiederebbe. Dieci teoremi simbolici coprono la segretezza in avanti, la sicurezza post-compromissione, la segretezza dell'iniziatore e del risponditore, l'autenticazione e cinque corollari del Teorema 1 di PQXDH. Il risultato principale è denominato signal_session_secure_placed. Esiste anche un percorso computazionale con un limite concreto, e i due percorsi usano modelli di avversario diversi: il lato simbolico (Dolev–Yao, tramite il framework DyLean) copre persino un attaccante quantistico che viola Diffie–Hellman dopo l'handshake, mentre il lato computazionale copre solo avversari classici.

Dove finiscono i sei milioni di righe

"Oltre sei milioni di righe" è la formulazione del blog ed è accurata ma grossolana. La ripartizione dettagliata del paper è quella utile, e vale la pena leggerla come una tabella dei costi più che come un vanto:

• Dimostrazioni per il binario — 5,3 milioni di righe, la maggior parte del lavoro, che coprono la semantica del codice macchina e il raffinamento dal modello simbolico fino all'eseguibile.

• Dimostrazioni computazionali — circa 860.000 righe.

• Dimostrazioni simboliche — circa 350.000 righe.

Dimostrazioni di confutazione dei bug — circa 140.000 righe, per le due vulnerabilità reintrodotte deliberatamente descritte di seguito.

• Prove dell'allocatore — circa 70.000 righe.

Quasi sette milioni di righe se si contano i commenti e le righe vuote, cosa che il paper fa e il blog no. In ogni caso, il rapporto che conta è quello tra la dimostrazione e ciò che viene dimostrato: 6,5 milioni di righe di Lean per stabilire proprietà di un binario da 560 KB. Quel rapporto è la misura onesta di quanto questa tecnica sia lontana dall'essere routine, ed è il numero da citare quando qualcuno chiede se la verifica formale è diventata economica.

La base fidata è più piccola della dimostrazione, e questo è il punto

Una dimostrazione vale solo quanto ciò che presuppone. L'articolo è specifico su questo, e la specificità è ciò che lo distingue da un comunicato stampa. Le specifiche fidate sono circa 18.000 righe (28.000 con la documentazione), la semantica AArch64 circa 8.000, e la codifica Lean del codice macchina circa 95.000. Trentasette routine sono sostituite da contratti anziché verificate — la compressione SHA-256 e SHA-512, AES-256-CBC, X25519, le operazioni sulla curva di Edwards, Kyber1024 e ML-KEM-768, e HMAC di libcrux. Diciotto punti di ingresso di panic sono parimenti presupposti anziché dimostrati.

Quindi l'affermazione non è "tutto è dimostrato". L'affermazione è che sono dimostrate la logica del protocollo crittografico, la macchina a stati della sessione e il raffinamento da quella logica alle istruzioni effettivamente eseguite, mentre le primitive sottostanti sono considerate fidate come ogni progetto di verifica si fida delle proprie primitive. Il compilatore Rust, in particolare, non fa parte della base fidata — il team ha evitato la necessità di fidarsi di esso ragionando a livello di codice macchina, che è lo stesso trucco che consente loro di aggirare del tutto un compilatore verificato. Per dare un contesto sulla scala, il paper cita seL4 a circa 20 anni-persona e CompCert a circa 6.

Due bug, reintrodotti di proposito

Un sistema di verifica che dice sempre e solo "corretto" non è testabile. Così il team ha preso due vulnerabilità che erano già state trovate e corrette nel codice di Signal — un bug dello stato debole e un bug del piccolo sottogruppo — le ha reintrodotte in una copia isolata e ha eseguito di nuovo la pipeline. In entrambi i casi AlphaProof Code ha prodotto una prova verificata automaticamente che la versione difettosa non soddisfa il teorema di sicurezza: l'enunciato simbolico si risolve in ¬Sec(Asm_bug).

L'articolo aggiunge un'avvertenza che una pagina di marketing avrebbe tagliato: la confutazione del teorema computazionale per quei bug è "molto più difficile" ed è stata lasciata aperta. In altre parole, il test negativo funziona in modo pulito sul fronte simbolico e non funziona ancora su quello computazionale. È esattamente il tipo di asimmetria che un lettore dovrebbe conoscere prima di trattare il framework come un rilevatore di bug.

Come sono stati eseguiti gli agenti

Cinque ricercatori in quattro settimane, ciascuno ha eseguito agenti senza sosta. La stesura delle dimostrazioni è stata affidata a squadre da 40 a 80 agenti, in esecuzione tra le 24 e le 72 ore su una singola macchina per squadra, con un agente supervisore al di sopra dell'orchestratore della squadra. Un agente guardiano controlla ogni proposta con un comparatore rispetto a una copia della specifica tenuta da parte e rispetto al kernel di Lean — una difesa contro un agente che dimostri una versione sottilmente indebolita di ciò che era stato richiesto.

Il lavoro umano è stato concentrato nella fase iniziale sulle specifiche. Ogni specifica è stata esaminata da un esperto prima che iniziasse il lavoro di dimostrazione, e la passata di audit degli stessi agenti ha segnalato circa l'1% della base di codice per l'attenzione umana. Nessun essere umano ha scritto codice di dimostrazione. L'articolo è anche schietto riguardo all'ingegneria: una build pulita può richiedere diverse ore, all'inizio una modifica minore al sorgente o un binario ricompilato forzava vaste riparazioni delle dimostrazioni, e c'è un "ampio margine di ottimizzazione" sia nelle dimostrazioni generate dall'AI sia nelle tecniche di dimostrazione stesse.

Cosa non coprono le prove

Le limitazioni sono abbastanza estese da costituire la sezione più importante dell'articolo, e sono enunciate chiaramente. Non viene stabilita alcuna garanzia post-quantistica per la proprietà di guarigione di SPQR — i teoremi del ratchet presuppongono che l'attaccante scelga le chiavi SPQR. La privacy del payload non è dimostrata. L'autenticazione del responder non è dimostrata per il primo messaggio di un handshake che non viene mai promosso. Il modello consente una sola sessione per promozione, lunghezze dei messaggi fisse, nessuno stato multi-dispositivo e chiavi di identità trust-on-first-use.

C'è anche un limite che diventa vacuo. Il termine di falsificazione MAC a 8 byte è almeno 2⁻⁶⁴ per tentativo e cresce quadraticamente rispetto a messaggi ed epoche, il che significa che il limite smette di dire qualcosa per una singola sessione di circa 25.000 messaggi, o per 2²⁰ sessioni da 2¹⁰ messaggi. E l'oggetto della dimostrazione è la build del team di libsignal-cli in esecuzione come processo nuovo — non l'app Signal sul tuo telefono. Diverse ipotesi sull'ambiente sono argomentate in modo informale anziché dimostrate.

Non c'è alcuna API, alcun prezzo e alcun modello da chiamare.

Questa è la parte che deluderà chiunque arrivi da una classifica di modelli. AlphaProof Code è un framework di ricerca e un insieme di artefatti pubblicati. Non c'è alcun endpoint, nessun listino prezzi per token, nessuna lista d'attesa e nessun peso: il repository contiene lo sviluppo in Lean, la semantica AArch64, il binding libsignal e le specifiche, non un checkpoint. Il blog afferma che gli artefatti sono open source; la pagina di presentazione non indica alcuna licenza, cosa che vale la pena verificare prima che qualcuno pianifichi di costruirci sopra.

I modelli che hanno svolto il lavoro sono una questione diversa. Il documento cita G​emini 4 Carbon per gli agenti di dimostrazione e afferma che Claude Opus 5.5 è stato usato insieme ad altri modelli per la stesura e la revisione delle specifiche. Claude Opus 5.5 è oggi nel catalogo di OrcaRouter a 4 $ per milione di token di input e 20 $ per milione di output, con il prezzo di listino del fornitore trasferito con un ricarico dello 0% — quindi, se la conclusione pratica che vuoi è «eseguire un ciclo di stesura delle specifiche con il modello usato nel documento», quella parte è una normale chiamata API, e una variazione di prezzo del fornitore si ripercuote su di noi lo stesso giorno. Il motore degli agenti di dimostrazione non è qualcosa che forniamo, e nulla qui implica che ospitiamo AlphaProof Code stesso.

Perché è una questione più importante del risultato di Signal

La verifica di Signal è impressionante di per sé — la prima verifica formale dell'implementazione di un protocollo ampiamente diffuso con qualsiasi metodo, con o senza IA, secondo DeepMind, e la prima volta che l'IA ha verificato un protocollo crittografico in uso a questo livello di profondità. Ma la tesi trasferibile è il flusso di lavoro. Un team di cinque persone, in quattro settimane, con una fase di revisione delle specifiche e un agente guardiano, ha prodotto un corpus di dimostrazioni che prima sarebbe stato un progetto pluriennale. Se quel rapporto regge anche solo approssimativamente, cambia l'insieme dei sistemi che possono permettersi la verifica: firmware di dispositivi medici, software per reti elettriche, il genere di codice che attualmente riceve una revisione del codice e una preghiera.

Che regga non è stato verificato. La crittografia di Signal è insolitamente ben specificata, il team ha fatto revisionare la metodologia dagli stessi ingegneri di Signal, e le primitive sono state affidate a terzi anziché verificate. Il prossimo sistema non sarà così accomodante. L'impostazione stessa del paper — abbinare la verifica formale ad agenti di difesa automatizzati come CodeMender — è la forma onesta della proposta: la verifica ti dice ciò che è vero, e qualcos'altro deve correggere ciò che non lo è.

Cosa guardare

Tre cose farebbero passare questo da paper fondamentale a tecnica industriale. Una seconda codebase indipendente, verificata da qualcuno esterno a G​oogle, idealmente una in cui la specifica sia stata scritta da zero anziché adattata da un'analisi esistente. Una cifra di costo — ore-agente, ore-acceleratore, dollari — perché quattro settimane e team da 40 a 80 agenti non è un'unità sulla quale un engineering manager possa impostare un budget. E la confutazione dei bug nel track computazionale, che il paper lascia aperta e che fa la differenza tra un sistema che dimostra proprietà e un sistema che sa anche dirti, a livello computazionale, che uno specifico binario è rotto.

Fino a quel momento, leggi il repository degli artefatti invece dell'annuncio. Le dimostrazioni sono lì, Lean le verifica, e il paper ti dice esattamente cosa presuppongono.