Google DeepMind i RSA-1024. Agenci AI znaleźli dwie słabości

Co agenci AI znaleźli w RSA-1024

RSA opiera się na tym, że pomnożenie dwóch dużych liczb pierwszych jest łatwe, a rozłożenie wyniku z powrotem na czynniki bardzo trudne. Kryptografowie od lat sprawdzają, jak duży jest ten zapas bezpieczeństwa, a wycofany standard RSA-1024 służy im za bezpieczny poligon. Tak potraktował go też zespół Google DeepMind.

Badaniami kierowali Dj Dvijotham i Abhradeep Thakurta, a współpracowali z nimi Nadia Heninger (UC San Diego i Inria) oraz Emmanuel Thomé (Inria). Ogłosił je Pushmeet Kohli, główny naukowiec DeepMind. W jego ocenie takie postępy zajmowały dotąd lata lub dekady, więc obrońcy mogli zakładać, że margines bezpieczeństwa zmienia się powoli. Wyniki mają pokazywać, że AI sprawdza te założenia znacznie szybciej.

Dwa wyniki i co oznacza 1600 razy szybciej

Obie prace mierzą coś innego, a podawane mnożniki nie są ze sobą porównywalne. Pierwsza dotyczy fałszowania podpisów w sytuacji, gdy atakujący może podsuwać urządzeniu podpisującemu wybrane dane. Druga dotyczy faktoryzacji, czyli rozkładu na czynniki, wielu kluczy tej samej długości. Tak wyglądają najważniejsze liczby:

• 3,5 razy mniej czasu procesora - zmierzone przy powtórzeniu znanego obliczenia dla klucza 1024-bitowego. Pierwszy pierwiastek wymagał 391 lat pracy rdzenia procesora.
• Poniżej jednej tysięcznej mocy obliczeniowej potrzebnej do złamania samego klucza - tyle według DeepMind wystarczyło do odtworzenia wyniku.
• Około 1600 razy - teoretyczny szacunek dla 1024-bitowych kluczy, gdy atakujący kontroluje tylko krótki, 32-bajtowy skrót wiadomości.
• Około 30 razy - przewaga nad wcześniejszymi metodami wsadowymi przy każdym kolejnym kluczu. To oszacowanie teoretyczne, bo autorzy pomijają w nim składniki niższego rzędu.

Jak pracowali agenci i ile zrobił człowiek

Praca o podpisach opisuje dwóch agentów. Nadzorca przygotował projekt, wyznaczał punkty kontrolne i sprawdzał wyniki, a wykonawca pisał kod, uruchamiał zadania i naprawiał błędy. Powstało około 33,5 tys. wierszy kodu i 336 rozproszonych eksperymentów. Prace nazywają oba modele Model A i Model B, nie podając ich nazw handlowych.

Obliczenie zajęło 3,2 dnia na maksymalnie 300 tys. rdzeni procesorów i 16 kartach graficznych, wobec około pięciu miesięcy w pierwotnym badaniu. Autorzy zastrzegają, że ta różnica wynika głównie z większej równoległości. Oszczędność czasu procesora przypisują przede wszystkim lepszemu kodowi. Przy drugiej pracy jeden model generował dowody, a drugi je weryfikował, zaś tożsamości algebraiczne sprawdzono maszynowo w systemie Lean 4.

Czego te wyniki nie oznaczają

Systemy oparte na kluczach RSA o długości 2048 bitów i większej nie są zagrożone tymi wynikami, zapewniają autorzy obu prac. To ich deklaracja, którą teraz sprawdzi środowisko kryptografów. Oba teksty mają status prac roboczych i nie znaleźliśmy informacji o recenzji naukowej.

Nie jest to też złamanie nowego klucza. DeepMind pisze o symulacji w izolowanym środowisku (sandboxie), bez kontaktu z działającymi systemami, oraz o kluczu rozwiązanym już wcześniej. Sygnał dla branży dotyczy przede wszystkim tempa badań. W naszej ocenie ważniejsza od samego RSA-1024 jest informacja, że dwaj agenci przeprowadzili złożone obliczenie kryptograficzne niemal bez udziału człowieka. W tekście pomijamy szczegóły metod, które nie są potrzebne do oceny ryzyka.

Co sprawdzić w polskiej firmie

Największe ryzyko dotyczy miejsc, o których nikt nie pamięta. Standard NIST SP 800-131A z 2019 roku nie dopuszcza już generowania podpisów RSA kluczami krótszymi niż 2048 bitów, ale stare klucze potrafią przetrwać w infrastrukturze. Dział IT może zrobić prosty przegląd:

1. Spisz klucze i certyfikaty RSA krótsze niż 2048 bitów, także w urządzeniach sieciowych, VPN i modułach podpisujących.
2. Sprawdź długość klucza DKIM w poczcie firmowej. RFC 8301 dopuszcza 1024 bity, ale zaleca co najmniej 2048.
3. Sprawdź, czy systemy podpisujące pozwalają zewnętrznym użytkownikom lub aplikacjom wskazywać podpisywane dane.
4. Wymień znalezione klucze na dłuższe, a w umowach z dostawcami sprzętu zapisz harmonogram tej wymiany.
5. Dopisz do planu migracji datę przeglądu, bo oceny siły kluczy mogą się teraz zmieniać szybciej.

Źródła i metoda

Sprawdziliśmy 7 listopada 2026 roku pełne teksty obu prac oraz wpis Pushmeeta Kohliego. Nie znaleźliśmy osobnego komunikatu na blogu DeepMind, a liczby podajemy za pracami i tym wpisem. Normę NIST i RFC 8301 dodaliśmy jako kontekst redakcji. Lista kroków dla firm to nasza rekomendacja organizacyjna, a nie zalecenie autorów badań.