+− THE DAILY DIFFdev & AI news
SHIP IT

AlphaProof Code and Signal: sprawdzone dowody bezpieczeństwa kodu maszynowego i zaufane założenia

Google DeepMind przedstawia maszynowo sprawdzone dowody wybranych właściwości bezpieczeństwa dla skompilowanej uprzęży linii poleceń libsignal.

Want to see our stories first on Google? Add us to your preferred sources — it helps us grow.

Google DeepMind przedstawia maszynowo sprawdzone dowody wybranych właściwości bezpieczeństwa dla skompilowanej uprzęży linii poleceń libsignal. Lean sprawdza dowody, podczas gdy ludzie zatwierdzają specyfikację i jej założenia. Oddzielny komparator sprawdza twierdzenie i wszystkie zależne definicje z zatwierdzonym celem.

Przeczytaj wydanie pisemne (angielski) ↗

Co obejmuje ten film

  • Agenci AI produkują kandydackie dowody; jądro Lean sprawdza, czy potwierdzają one formalne twierdzenie zatwierdzone przez człowieka.
  • Zweryfikowanym celem jest konkretna, skompilowana uprząż CLI libsignal, z zaufaną semantyką i kontraktami kryptograficznymi.
  • Dowodzenie skompilowanego pliku binarnego usuwa kompilator Rust z zaufanej bazy dla określonych właściwości tego pliku binarnego.
  • Naukowcy zgłaszają dwa izolowane ponowne wprowadzenia wcześniej naprawionych błędów, które naruszają ich symboliczne twierdzenie bezpieczeństwa.
  • Komparator sprawdza twierdzenie i każdą zależną definicję z chronioną, zatwierdzoną specyfikacją; poprawki przechodzą przez oddzielny, recenzowany proces.

Pytania i odpowiedzi

Co AlphaProof Code udowodniło w kwestii implementacji Signal?

Google DeepMind przedstawia sprawdzone dowody wybranych właściwości bezpieczeństwa dla skompilowanej uprzęży linii poleceń libsignal. Artykuł techniczny obejmuje poufność i uwierzytelnianie wiadomości, z poufnością przyszłości i bezpieczeństwem po naruszeniu w ramach określonych modeli. Wynik zachowuje warunki dotyczące atakującego, sesji i założeń kryptograficznych. Jego zakres wyklucza ogólną gwarancję dla każdej aplikacji lub instalacji Signal.

Obejrzyj tę część 2:16 · Swarat Chaudhuri and colleagues / Google DeepMind and Google · Pushmeet Kohli and Swarat Chaudhuri / Google DeepMind · Google DeepMind / GitHub

Kto decyduje, co musi potwierdzać dowód bezpieczeństwa generowany przez AI?

Ludzie recenzujący zatwierdzają specyfikację i jej założenia. Artykuł techniczny Google DeepMind opisuje agentów opracowujących specyfikacje z ludzkim przewodnictwem i recenzentów testujących, czy stwierdzenia oddają znaczące właściwości bezpieczeństwa. Lean sprawdza logikę wynikowego dowodu. Ludzie pozostają odpowiedzialni za wybór silnego celu, przegląd założeń i rozstrzyganie proponowanych zmian w zatwierdzonej specyfikacji.

Obejrzyj tę część 0:57 · Swarat Chaudhuri and colleagues / Google DeepMind and Google

Dlaczego weryfikować skompilowany kod maszynowy zamiast ufać kompilatorowi Rust?

Dowód dotyczący skompilowanego pliku binarnego bezpośrednio potwierdza określone właściwości tego artefaktu. Artykuł Google DeepMind wyjaśnia, że błąd kompilatora naruszający jedną z tych właściwości spowodowałby, że twierdzenie byłoby fałszywe. Kompilator Rust opuszcza zatem zaufaną bazę dla tego twierdzenia. Dowód nadal ufa modelowi instrukcji, jądru Lean i określonym kontraktom kryptograficznym.

Obejrzyj tę część 1:39 · Swarat Chaudhuri and colleagues / Google DeepMind and Google · Google DeepMind / GitHub

Jak komparator powstrzymuje agenta dowodowego przed osłabieniem jego celu?

Komparator sprawdza twierdzenie i każdą definicję, od której ono zależy, z chronioną, zatwierdzoną specyfikacją. Artykuł Google DeepMind mówi, że agenci dowodowi nie mogą zapisywać do tej przechowywanej kopii. Sprawdzarka sprawdza również dozwolone aksjomaty i odtwarza dowód w nowym jądrze. Proponowane poprawki do specyfikacji podlegają oddzielnemu, recenzowanemu procesowi, podczas gdy ludzie pozostają odpowiedzialni za siłę celu.

Obejrzyj tę część 3:36 · Swarat Chaudhuri and colleagues / Google DeepMind and Google · Google DeepMind / GitHub

Jaki był werdykt The Daily Diff w sprawie przepływu pracy dowodowej?

Werdykt The Daily Diff brzmiał SHIP IT. Niko wysłałby sprawdzony przepływ pracy dowodowej, ponieważ zatwierdzone twierdzenie pozostaje oddzielone od agenta produkującego odpowiedź. Zachowałby zakres i założenia dołączone do każdego wyniku. Odcinek przedstawia opublikowany artefakt dowodu Google bez jego niezależnej przebudowy i zatwierdza przepływ pracy w ramach tych granic dowodowych.

Obejrzyj tę część 4:53 · Swarat Chaudhuri and colleagues / Google DeepMind and Google · Pushmeet Kohli and Swarat Chaudhuri / Google DeepMind · Google DeepMind / GitHub

Przetłumaczona transkrypcja

Przetłumaczono z oryginalnej narracji angielskiej. Dostępne audio i napisy są kontrolowane przez YouTube.

Kto sprawdza dowód bezpieczeństwa AI?

0:00 Audyt bezpieczeństwa AI nadal brzmi jak zaufanie chatbotowi. Nowy wynik Google Signal jest poparty dowodami matematycznymi, a oddzielne jądro sprawdza. W tym filmie, co Google udowodniło? I jak powstrzymują agenta przed zmianą celów? Oto przydatna odpowiedź. Modele piszą kandydackie dowody, a Lean sprawdza dowody z twierdzeniem zatwierdzonym przez człowieka na temat wybranego skompilowanego kodu. Ludzie nadal są właścicielami twierdzenia i założeń.

0:21 Możesz sprawdzić wynik, nie wierząc w mowę zwycięstwa modelu. Oddzielne sprawdzenie wykrywa cichą zmianę pytania. Podążymy za tym do definicji. Jest wtorek, dziesiąty listopada, a to jest The Daily Diff. AlphaProof Code to struktura Google do pisania specyfikacji oprogramowania z ludzkim przewodnictwem i generowania sprawdzonych dowodów za pomocą agentów AI. To badanie dotyczy libsignal, biblioteki Rust implementującej protokół wiadomości Signal, w ramach konkretnego programu wiersza poleceń.

0:45 Google ogłosiło dziś tę pracę. W artykule podano, że pięciu badaczy pracowało przez cztery tygodnie. Agenci pisali dowody, podczas gdy ludzie większość wysiłku poświęcili na specyfikacje. Wymagania znalazły sposób, by stać się jeszcze droższymi spotkaniami. Specyfikacja mówi, co program musi zrobić,

Jak twierdzenie staje się celem dowodu?

0:59 co kontroluje atakujący i jakich założeń wymaga argument. Recenzenci pytają, czy oddaje to bezpieczeństwo, na którym ludziom zależy. Pięknie sprawdzona odpowiedź na słabe pytanie pozostawia to pytanie nienaruszone. Zespół bazuje na wcześniejszych badaniach nad uzgadnianiem Signal i jego kluczem wiadomości ratchet. Formalne analizy już badały te projekty. Twierdzenie Google łączy ich argumenty bezpieczeństwa ze skompilowaną implementacją niezmodyfikowanej biblioteki produkcyjnej, gdzie projekt musi przetrwać kontakt z rzeczywistym kodem. Dyrektor ds. technologii Signal, Ehren Kret,

1:27 opisuje rozszerzenie poza mniejsze zakresy wcześniejszej weryfikacji. Szczegóły implementacji obejmują wiadomości poza kolejnością i archiwalne sesje dla opóźnionych wiadomości. Prawdziwe oprogramowanie przechowuje potwierdzenia, które twój elegancki diagram wyrzucił. Badacze kompilują niezmodyfikowaną bibliotekę Rust za pomocą standardowego

Dlaczego dowodzić skompilowany plik binarny?

1:41 kompilatora do pliku wykonywalnego Arm sixty-four Linux. Ich twierdzenia opisują ten plik binarny za pomocą formalnego modelu instrukcji, pokonując lukę między kodem źródłowym a zoptymalizowanym kodem maszynowym. Błąd kompilatora, który narusza określoną właściwość, spowodowałby, że twierdzenie byłoby fałszywe. Kompilator opuszcza zatem zaufaną bazę dla tego pliku binarnego. Nadal ufasz modelowi instrukcji i sprawdzarce Lean. Granica zaufania przesunęła się i ma adres. Około sześć i pół miliona linii sprawdzonego dowodu opiera się na około dwudziestu sześciu

2:06 tysiącach zaufanych linii specyfikacji i semantyki instrukcji. To są liczniki artefaktów. Traktowanie ich jako wyniki inteligencji jest jak ranking deweloperów według rozmiaru ich folderu modułów węzłów.

Które właściwości bezpieczeństwa przetrwały lukę w implementacji?

2:16 Argumenty obejmują poufność i uwierzytelnianie wiadomości, z poufnością przyszłości i bezpieczeństwem po naruszeniu w ramach określonych modeli. Te dwie ostatnie opisują ograniczenia dotyczące szkód spowodowanych skradzionymi kluczami i odzyskiwania po świeżych wymianach. Każda gwarancja ma warunki dotyczące atakującego i sesji. Prymitywy kryptograficzne znajdują się za zaufanymi kontraktami. Dowód zakłada, że te procedury zachowują się zgodnie ze specyfikacją i opiera się na kryptograficznych założeniach bezpieczeństwa. Jeden dowód idealizuje kryptografię; drugi rozważa prawdopodobieństwa sukcesu atakującego.

2:42 Oba mają ograniczenia co do scenariuszy, które obejmują. Zapytaj, która kompilacja, która właściwość i które założenia. Ten wynik dotyczy uprzęży linii poleceń badaczy. Wiadomości grupowe to przyszła praca, a model obliczeniowy wyklucza stan wielu urządzeń. Nazywanie każdej instalacji Signal wolną od błędów wykracza poza twierdzenie. Badacze ponownie wprowadzili dwa wcześniej naprawione błędy Signal do

Czy specyfikacja może odrzucić wadliwy kod?

3:02 izolowanych kopii i skompilowali je. Sprawdzone dowody wykazały, że te pliki binarne naruszyły symboliczne twierdzenie bezpieczeństwa. To przetestowało, czy specyfikacja może odrzucić prawdziwe wadliwe implementacje. Twój zielony znacznik wymaga czerwonego testu. Google publikuje specyfikacje i dowody wraz z instrukcjami sprawdzania. Repozytorium mówi, że czysta kompilacja zajmuje godziny i znaczną ilość pamięci. Czytanie ogłoszenia jest znacznie łatwiejsze na laptopie. Model sprzętu i zaufane kontrakty nadal wymagają przeglądu.

3:26 Nie przebudowałem ogromnego artefaktu dla tego odcinka. Raportujemy opublikowany wynik i jego granice. Osoby z zewnątrz mają drogę do jego sprawdzenia, co jest dla mnie ważniejsze niż kolejna ruda AI. Teraz pułapka.

Czy poprawny dowód może odpowiedzieć na złe pytanie?

3:36 Lean może zaakceptować poprawny dowód twierdzenia, które prawie nic nie wymaga. Niemożliwe założenia mogą sprawić, że twierdzenie będzie puste. Zmiana definicji ukrytej pod nagłówkiem twierdzenia może osłabić cel. Artykuł opisuje kontrole przeciwko temu. Strażnik przechowuje zatwierdzoną specyfikację, do której agenci dowodowi nie mogą zapisywać. Mogą proponować poprawki poprzez oddzielny proces zmian. Osłabienie bezpieczeństwa jest eskalowane jako potencjalny błąd. Deklaracja sukcesu dowodzącego nie ma tu autorytetu.

4:00 Ludzie rozstrzygają zmiany w zaufanych założeniach, bezpośrednio lub poprzez swoją politykę, i przeglądają poprawki po każdej kampanii. Ekspertyza pozostaje pod kontrolą. Agent może zażądać innego zadania. Nie może sobie wystawić oceny pozytywnej.

Co powstrzymuje ruchome cele?

4:13 Oto obiecane sprawdzenie. Komparator Lean porównuje twierdzenie i każdą definicję, od której ono zależy, z tą chronioną, zatwierdzoną kopią. Sprawdza również dozwolone aksjomaty i odtwarza dowód w nowym jądrze. Ciche osłabienie definicji pomocniczej zmienia zatem porównywany obiekt. Zaakceptowany dowód musi ustalić zatwierdzony cel. To nadal pozostawia ludzi odpowiedzialnymi za wybór silnego celu i uczciwych założeń. W przypadku własnego przepływu pracy AI, utrzymuj kryteria akceptacji poza

4:37 uprawnieniami edycji pracownika i oddzielnie przeglądaj proponowane zmiany. Wynik Google uściśla to rozdzielenie. Autor dowodu wykonuje pracę; granica sprawdzania decyduje, czy się liczy. Jeśli wolisz to przeczytać, niż usłyszeć ode mnie, diff trafia do Twojej skrzynki odbiorczej każdego ranka, bezpłatnie na daily diff dot dev, link poniżej. Dzisiejszy werdykt to SHIP IT.

Czy wysłałbym ten przepływ pracy dowodowej?

4:54 Wysłałbym ten sprawdzony przepływ pracy dowodowej, ponieważ zatwierdzone twierdzenie pozostaje oddzielone od agenta produkującego odpowiedź. Zachowałbym zakres i założenia dołączone do każdego wyniku. Subskrybuj, naciśnij dzwonek i powiedz mi w komentarzach, czy stemplowałbyś to inaczej. I to tyle na dziś. Jestem Niko z Axrisi. Łącz odpowiedzialnie.

Źródła

  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

Niko from Axrisi

Nikoloz Turazashvili · Vexrail · Axrisi

LinkedIn · dev.to · GitHub · X · Substack

Powiązane filmy