Tag: NIST

Wprowadzenie do problemu / definicja

Rozwój sztucznej inteligencji coraz mocniej wpływa na obszar cyberbezpieczeństwa, w tym również na badania kryptograficzne. Najnowsze doniesienia wskazują, że model Claude Mythos Preview miał wesprzeć opracowanie ataku odzyskiwania klucza na testowy wariant postkwantowego schematu HAWK-256 oraz przyspieszyć znany atak na zredukowaną, 7-rundową wersję AES-128.

Nie oznacza to natychmiastowego zagrożenia dla powszechnie stosowanych wdrożeń kryptograficznych, ale stanowi ważny sygnał dla branży. Modele AI przestają być wyłącznie narzędziem do analizy kodu i automatyzacji operacji bezpieczeństwa, a zaczynają wspierać zaawansowaną kryptoanalizę.

W skrócie

Najważniejszy wniosek z opublikowanych informacji jest taki, że oba wyniki mają obecnie przede wszystkim znaczenie badawcze. Atak na HAWK-256 dotyczy parametru wyzwaniowego, a nie pełnego przekreślenia całej klasy kryptografii kratowej, natomiast szybsza analiza AES odnosi się tylko do 7 z 10 rund standardowego AES-128.

• Claude Mythos Preview miał pomóc w opracowaniu kompletnego ataku odzyskiwania klucza na HAWK-256.
• W ataku na HAWK wykorzystano wcześniej nieuwzględnioną symetrię w strukturze kratowej algorytmu.
• W przypadku AES-128 badacze opisali szybszy atak typu meet-in-the-middle na wersję 7-rundową.
• Przyspieszenie wobec wcześniejszej techniki ma wynosić od 200 do 800 razy.
• 29 lipca 2026 roku zespół HAWK wycofał projekt z procesu standaryzacji NIST.

Kontekst / historia

HAWK należał do grona kandydatów dopuszczonych przez NIST do trzeciej rundy dodatkowego procesu standaryzacji podpisów cyfrowych odpornych na komputery kwantowe. Projekt wzbudzał zainteresowanie, ponieważ reprezentował podejście kratowe, oferował relatywnie małe podpisy i nie wymagał obliczeń zmiennoprzecinkowych.

Równolegle środowisko kryptograficzne od lat bada zredukowane wersje znanych szyfrów blokowych, takich jak AES. Tego typu analizy nie służą zwykle wykazaniu praktycznego złamania produkcyjnego algorytmu, lecz ocenie jego marginesu bezpieczeństwa i identyfikacji potencjalnych skrótów analitycznych.

Nowością w tej sprawie jest rola AI w generowaniu lub przyspieszaniu nowych pomysłów kryptoanalitycznych. To przesuwa dyskusję z poziomu wsparcia badaczy przez modele językowe do pytania o to, czy wyspecjalizowana AI może realnie przyczyniać się do odkrywania nowych technik ataku.

Analiza techniczna

W przypadku HAWK-256 opisywany atak koncentruje się na odzyskaniu klucza dla wariantu testowego. Zgodnie z publicznymi informacjami badacze mieli wykorzystać dodatkowy automorfizm, czyli symetrię zachowującą strukturę kraty. Taka właściwość może obniżyć trudność problemu do poszukiwania krótkiego wektora w kracie o mniejszym wymiarze niż pierwotnie zakładano.

Praktyczna realizacja ataku miała polegać na zbudowaniu specjalnej kraty pochodnej z klucza publicznego, a następnie użyciu redukcji krat i technik przesiewania do odzyskania krótkich wektorów. Na tej podstawie możliwe staje się odtworzenie sekretu funkcjonalnie równoważnego z oryginalnym materiałem podpisującym, co w praktyce pozwala generować poprawne podpisy dla danego klucza publicznego.

Według opisu opublikowana implementacja miała wspierać wyłącznie HAWK-256 i odrzucać inne parametry wejściowe. Szacowany czas pełnego odzyskania klucza wynosił około 3 godzin i 42 minut na serwerze 96-rdzeniowym, co pokazuje, że dla tego wariantu atak przestaje być wyłącznie konstrukcją teoretyczną.

W przypadku AES-128 chodzi wyłącznie o atak na 7-rundową wersję szyfru. Usprawnienie dotyczy klasycznego schematu meet-in-the-middle, w którym porównuje się stany pośrednie uzyskane podczas obliczeń prowadzonych od różnych stron szyfru. Claude Mythos Preview miał wskazać niezmiennik określony jako Möbius Bridge, który eliminuje jeden z etapów zgadywania wartości pośredniej.

Mimo tego ograniczenia praktyczne znaczenie ataku na AES pozostaje niewielkie. Opisana metoda nadal wymaga około 2^105 wybranych tekstów jawnych zaszyfrowanych pod jednym stałym i nieznanym kluczem, co czyni taki scenariusz skrajnie nierealistycznym w realnych środowiskach operacyjnych.

Konsekwencje / ryzyko

Z perspektywy organizacji korzystających z powszechnie wdrożonych mechanizmów szyfrowania nie ma dziś przesłanek do awaryjnej wymiany AES. Wynik dotyczący 7-rundowego AES-128 nie obejmuje pełnej wersji algorytmu i nie przekłada się na praktyczną podatność produkcyjną.

Znacznie większe znaczenie ma sprawa HAWK. Choć publicznie opisany atak dotyczył wariantu wyzwaniowego HAWK-256, jego wpływ na zaufanie do konstrukcji okazał się istotny na tyle, że projekt został wycofany z procesu standaryzacyjnego NIST. To pokazuje, że nawet częściowy sukces kryptoanalityczny może zmienić ocenę dojrzałości algorytmu postkwantowego.

Szersze ryzyko ma charakter strategiczny. Jeżeli modele AI będą coraz skuteczniej identyfikować symetrie, niezmienniki i skróty obliczeniowe w projektach kryptograficznych, organizacje będą musiały szybciej reagować na zmiany w ocenie bezpieczeństwa algorytmów. Oznacza to większą presję na kryptograficzną elastyczność, sprawne procesy migracyjne i bardziej regularną ocenę zależności od dostawców.

Istotnym problemem pozostaje też walidacja wyników. Nawet jeśli AI generuje obiecujące hipotezy, to ich potwierdzenie wymaga zaawansowanej pracy ekspertów. W praktyce przewaga konkurencyjna może więc zależeć nie tylko od jakości modeli, ale również od zdolności zespołów badawczych do szybkiej weryfikacji odkryć.

Rekomendacje

Organizacje powinny zachować spokój i nadal stosować AES zgodnie z aktualnymi dobrymi praktykami bezpieczeństwa. Kluczowe pozostają poprawna implementacja, bezpieczne zarządzanie kluczami, stosowanie uwierzytelnionych trybów szyfrowania oraz ograniczanie ryzyka wycieku materiału kryptograficznego.

W obszarze kryptografii postkwantowej warto przyjąć podejście oparte na elastyczności architektonicznej. Systemy powinny być projektowane tak, aby wymiana algorytmów, parametrów i bibliotek była możliwa bez kosztownej przebudowy całej infrastruktury.

• monitorować decyzje NIST i zmiany w procesach standaryzacyjnych PQC,
• unikać nadmiernej zależności od eksperymentalnych lub niestandardowych schematów kryptograficznych,
• uwzględniać wpływ AI na tempo badań kryptograficznych w modelach ryzyka,
• rozwijać procesy niezależnej walidacji wyników publikowanych przez laboratoria i dostawców modeli,
• prowadzić inwentaryzację używanej kryptografii, aby szybciej reagować na zmianę oceny bezpieczeństwa algorytmów.

Dla vendorów i środowisk badawczych ważne staje się również testowanie własnych konstrukcji pod kątem zautomatyzowanego wykrywania symetrii i niezmienników. AI może w praktyce stać się nowym narzędziem red teamingu kryptograficznego.

Podsumowanie

Wyniki dotyczące HAWK-256 i 7-rundowego AES-128 nie oznaczają załamania bezpieczeństwa współczesnej kryptografii, ale sygnalizują istotną zmianę jakościową. Sztuczna inteligencja coraz wyraźniej wchodzi w obszar głębokiej kryptoanalizy i może wpływać na tempo odkrywania słabości w nowych konstrukcjach.

Najbardziej namacalnym skutkiem tej sprawy nie jest praktyczne zagrożenie dla pełnego AES-128, lecz wpływ na ocenę schematów postkwantowych i proces standaryzacji. Wycofanie HAWK z procesu NIST pokazuje, że badania prowadzone z udziałem AI mogą szybko przełożyć się na decyzje strategiczne dla całego rynku bezpieczeństwa.

Źródła

1. https://thehackernews.com/2026/07/claude-ai-just-cracked-post-quantum.html
2. https://www.nist.gov/news-events/news/2026/05/nine-candidates-advance-third-round-additional-digital-signatures-pqc
3. https://nvlpubs.nist.gov/nistpubs/ir/2026/NIST.IR.8610.pdf
4. https://www.anthropic.com/claude/mythos
5. https://csrc.nist.gov/Projects/pqc-dig-sig

Wprowadzenie do problemu / definicja

W bibliotece Hugging Face Diffusers wykryto poważne luki bezpieczeństwa, które umożliwiały obejście mechanizmu trust_remote_code. Funkcja ta miała chronić użytkowników przed nieświadomym uruchamianiem niestandardowego kodu pobieranego razem z modelami generatywnymi, jednak w praktyce wybrane ścieżki ładowania pozwalały ominąć tę kontrolę.

Problem jest istotny, ponieważ Diffusers jest szeroko stosowane do uruchamiania modeli obrazu, audio i wideo, a więc w środowiskach badawczych, developerskich i produkcyjnych. W efekcie podatność wpisuje się w rosnące ryzyko związane z bezpieczeństwem łańcucha dostaw dla systemów AI i ML.

W skrócie

Ujawnione podatności dotyczyły wersji Diffusers wcześniejszych niż 0.38.0 i mogły prowadzić do wykonania dowolnego kodu Python podczas ładowania spreparowanych repozytoriów modeli lub lokalnych snapshotów.

• Mechanizm trust_remote_code można było ominąć w kilku scenariuszach ładowania pipeline’ów.
• Atakujący mógł przygotować złośliwy komponent modelu lub niestandardowy pipeline.
• W jednym z wariantów możliwe było automatyczne załadowanie pliku None.py.
• Najważniejszym działaniem naprawczym jest aktualizacja do wersji 0.38.0 lub nowszej.

Kontekst / historia

Ryzyko wykonywania kodu przy ładowaniu modeli nie jest nowym zjawiskiem. Nowoczesne ekosystemy ML coraz częściej traktują model jako zestaw plików zawierających nie tylko wagi, lecz także logikę uruchomieniową, klasy pomocnicze i dodatkowe komponenty.

To podejście zwiększa elastyczność i ułatwia wdrażanie niestandardowych rozwiązań, ale jednocześnie poszerza powierzchnię ataku. W przypadku Diffusers mechanizm trust_remote_code miał być świadomą bramką bezpieczeństwa, która wymaga zgody użytkownika na wykonanie zdalnego kodu. Ujawnione błędy pokazały jednak, że kontrola nie obejmowała wszystkich ścieżek wykonania.

Analiza techniczna

Główna przyczyna problemu miała charakter architektoniczny. Kontrola bezpieczeństwa została osadzona w logice pobierania zasobów, a nie bezpośrednio w miejscu faktycznego ładowania modułów dynamicznych. W praktyce oznaczało to, że ścieżki omijające lub skracające etap pobierania mogły jednocześnie ominąć również walidację bezpieczeństwa.

Pierwszy scenariusz dotyczył użycia parametru custom_pipeline wskazującego inne repozytorium niż główne repo modelu. W takim przypadku weryfikacja odnosiła się do jednego zestawu plików, natomiast wykonywany kod pochodził z innego źródła. Powstawało więc rozdzielenie między obiektem walidowanym a obiektem faktycznie uruchamianym.

Drugi wariant obejmował ładowanie z lokalnego snapshotu przy jednoczesnym użyciu zdalnego custom_pipeline. Ponieważ ścieżka lokalna nie aktywowała pełnego procesu odpowiedzialnego za kontrolę bezpieczeństwa, zdalny kod mógł zostać uruchomiony mimo założonej polityki blokującej.

Trzeci scenariusz dotyczył lokalnych snapshotów zawierających niestandardowe komponenty wskazane w pliku model_index.json, na przykład własne moduły dla wybranych elementów pipeline’u. Również tutaj lokalna ścieżka ładowania omijała kluczowy punkt egzekwowania reguły trust_remote_code.

Osobny, lecz powiązany problem wynikał z obsługi parametru custom_pipeline, gdy nie został on jawnie przekazany. W podatnej logice wartość None mogła zostać przekształcona do postaci None.py. Jeśli taki plik znajdował się w repozytorium wraz z odpowiednio przygotowaną konfiguracją, standardowe wywołanie funkcji ładującej mogło pobrać i uruchomić złośliwy moduł bez dodatkowych argumentów ze strony ofiary.

Z perspektywy bezpieczeństwa są to błędy prowadzące do zdalnego wykonania kodu oraz naruszenia założeń mechanizmu ochronnego. Problem wykracza więc poza pojedynczą bibliotekę i pokazuje szersze wyzwania związane z zaufaniem do artefaktów ML.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem podatności jest możliwość uruchomienia dowolnego kodu Python w środowisku, które ładuje model. Jeżeli taki proces działa z szerokimi uprawnieniami, atak może prowadzić do przejęcia serwera inferencyjnego, kradzieży sekretów, modyfikacji wyników działania modeli lub wdrożenia trwałych mechanizmów obecności.

Ryzyko rośnie szczególnie w organizacjach, które automatycznie pobierają modele z publicznych repozytoriów i traktują je bardziej jak dane niż wykonywalny kod. Dotyczy to zwłaszcza notebooków badawczych, pipeline’ów CI/CD, współdzielonych workerów GPU oraz środowisk bez izolacji kontenerowej i restrykcyjnej kontroli ruchu wychodzącego.

• przejęcie procesu odpowiedzialnego za inferencję,
• wyciek kluczy API, tokenów i innych sekretów,
• modyfikacja zachowania modelu lub wyników jego pracy,
• ruch boczny w infrastrukturze po uzyskaniu dostępu do hosta,
• utrwalenie złośliwej obecności w środowisku produkcyjnym.

Rekomendacje

Podstawowym krokiem naprawczym jest aktualizacja biblioteki Hugging Face Diffusers do wersji 0.38.0 lub nowszej. To najważniejsze działanie ograniczające ryzyko wykorzystania opisanych luk.

Równolegle warto wdrożyć podejście defense-in-depth i potraktować modele oraz pipeline’y jako aktywny element kodu, a nie wyłącznie pasywny artefakt danych.

• ograniczyć ładowanie modeli do zaufanych i zatwierdzonych repozytoriów,
• stosować pinning wersji, hashy i snapshotów zamiast dynamicznego pobierania najnowszych zasobów,
• skanować repozytoria modeli pod kątem dodatkowych plików Python i wpisów w model_index.json,
• uruchamiać pipeline’y w odizolowanych kontenerach lub sandboxach z minimalnymi uprawnieniami,
• blokować zbędny ruch sieciowy wychodzący z workerów obsługujących modele,
• monitorować procesy potomne, nietypowe połączenia i dostęp do sekretów podczas inicjalizacji,
• rozdzielać środowiska testowe i produkcyjne dla eksperymentów z nowymi modelami,
• włączyć przegląd bezpieczeństwa także dla zewnętrznych artefaktów ML.

Podsumowanie

Luki w Hugging Face Diffusers pokazują, że bezpieczeństwo narzędzi AI coraz mocniej przypomina klasyczne problemy software supply chain. Mechanizm trust_remote_code miał pełnić rolę zabezpieczenia przed nieautoryzowanym wykonaniem kodu, jednak błędy implementacyjne umożliwiły jego obejście w kilku scenariuszach.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że repozytoria modeli, snapshoty i niestandardowe pipeline’y wymagają takich samych kontroli jak zależności programistyczne. Aktualizacja biblioteki oraz wdrożenie izolacji, walidacji i monitoringu powinny być traktowane jako priorytet.

Źródła

1. NVD – CVE-2026-44513 — https://nvd.nist.gov/vuln/detail/CVE-2026-44513
2. NVD – CVE-2026-44827 — https://nvd.nist.gov/vuln/detail/CVE-2026-44827
3. Infosecurity Magazine – Bugs in Hugging Face Diffusers Bypass Custom Code Safeguard — https://www.infosecurity-magazine.com/news/hugging-face-diffusers-trust/
4. GitHub – huggingface/diffusers Releases — https://github.com/huggingface/diffusers/releases
5. GitHub – Security considerations for trust_remote_code=True, Discussion #12033 — https://github.com/huggingface/diffusers/discussions/12033

Wprowadzenie do problemu / definicja

Rozwój modeli generatywnych coraz wyraźniej wpływa na obszar cyberbezpieczeństwa, wykraczając poza analizę kodu, wykrywanie błędów implementacyjnych czy automatyzację prostych zadań badawczych. Najnowszy przypadek pokazuje, że AI może wspierać również kryptanalizę, a więc identyfikowanie słabości w samych konstrukcjach kryptograficznych.

Opisane wyniki dotyczą dwóch odrębnych osiągnięć badawczych: skuteczniejszego ataku odzyskiwania klucza na HAWK-256, czyli testowy wariant kandydata do podpisów postkwantowych, oraz znaczącego przyspieszenia znanego ataku na zredukowaną, 7-rundową wersję AES-128. Choć nie oznacza to natychmiastowego zagrożenia dla powszechnie używanych systemów, publikacja ma duże znaczenie dla środowiska kryptograficznego i zespołów odpowiedzialnych za bezpieczeństwo długoterminowe.

W skrócie

• Model Claude miał pomóc w opracowaniu pełnego ataku odzyskiwania klucza dla HAWK-256.
• W ataku na HAWK wykorzystano wcześniej niewykorzystaną symetrię w strukturze kraty.
• Szacowany koszt ataku na HAWK-256 spadł z około 2^64 do około 2^38 operacji.
• Drugi wynik dotyczy nowej optymalizacji ataku meet-in-the-middle na 7-rundowy AES-128.
• Autorzy wskazują na przyspieszenie rzędu 200–800 razy względem wcześniejszego najlepszego podejścia.
• Nie ma obecnie podstaw, by uznać pełny AES-128 za naruszony lub niebezpieczny w produkcji.

Kontekst / historia

HAWK należy do grona schematów rozwijanych w ramach dodatkowego procesu standaryzacyjnego NIST dla podpisów postkwantowych. Bezpieczeństwo tej konstrukcji opiera się na problemach kratowych, które od lat są uznawane za jedną z najważniejszych rodzin mechanizmów odpornych na zagrożenia związane z przyszłymi komputerami kwantowymi.

W badaniach nad HAWK już wcześniej sugerowano, że odnalezienie odpowiedniej automorfii, czyli nietrywialnej symetrii zachowującej strukturę kraty, mogłoby znacząco ułatwić odzyskiwanie materiału tajnego. Przez długi czas nie było jednak jasne, czy taka właściwość może zostać praktycznie wykorzystana w tej konkretnej konstrukcji.

Równolegle środowisko kryptograficzne od lat analizuje także zredukowane wersje AES. Badanie szyfru z mniejszą liczbą rund nie oznacza złamania pełnej wersji algorytmu, ale pozwala mierzyć margines bezpieczeństwa i rozwijać nowe techniki kryptanalityczne. Z tego względu nawet wynik odnoszący się wyłącznie do 7-rundowego AES-128 jest ważnym sygnałem naukowym.

Analiza techniczna

W przypadku HAWK-256 badacze opisali atak odzyskiwania klucza oparty na wykorzystaniu dodatkowej automorfii w kracie HAWK. Taka symetria pozwala przekształcić problem do postaci łatwiejszej obliczeniowo, a następnie użyć technik redukcji krat i przesiewania do odnalezienia krótkich wektorów prowadzących do odtworzenia funkcjonalnie równoważnego materiału klucza tajnego.

To istotne rozróżnienie: opublikowany atak nie musi odzyskiwać pierwotnego ziarna klucza prywatnego. W praktyce wystarczy jednak uzyskać równoważny materiał podpisujący, który umożliwia generowanie poprawnych podpisów dla danego klucza publicznego. Z punktu widzenia bezpieczeństwa oznacza to skuteczne podważenie badanego wariantu schematu.

Według autorów koszt ataku dla HAWK-256 spadł z około 2^64 do około 2^38 operacji. To bardzo znaczące osłabienie parametru testowego, nawet jeśli atak nadal pozostaje wykładniczy. Jednocześnie publicznie udostępniona implementacja dotyczy wyłącznie HAWK-256, a nie większych wariantów HAWK-512 i HAWK-1024.

Drugi wynik dotyczy 7-rundowego AES-128 i rozwija wcześniejsze ataki typu meet-in-the-middle. Metoda ta polega na rozdzieleniu szyfru na etapy, obliczaniu stanów pośrednich z dwóch stron i dopasowywaniu ich przy użyciu tabel pomocniczych oraz odcisków pośrednich. Nowa konstrukcja, określana jako Möbius Bridge, ma umożliwiać usunięcie jednego z kosztownych etapów zgadywania 256 wartości.

Choć sama transformacja pozostaje kosztowna obliczeniowo, autorzy oceniają, że końcowy efekt daje przyspieszenie od 200 do 800 razy względem wcześniejszego najlepszego podejścia. Jednocześnie atak nadal wymaga około 2^105 wybranych tekstów jawnych szyfrowanych pod jednym nieznanym kluczem, co czyni go praktycznie nieosiągalnym poza warunkami czysto akademickimi.

Konsekwencje / ryzyko

Najważniejszy wniosek dla branży nie dotyczy natychmiastowego zagrożenia operacyjnego, lecz rosnącej roli AI w odkrywaniu słabości kryptograficznych. Dotychczas modele językowe kojarzono przede wszystkim z analizą kodu, automatyzacją exploit developmentu czy wsparciem inżynierii wstecznej. Ten przypadek pokazuje, że mogą być również użyteczne przy badaniu matematycznych fundamentów bezpieczeństwa.

Dla HAWK ryzyko ma przede wszystkim wymiar strategiczny. Jeśli wyniki zostaną niezależnie potwierdzone, mogą wpłynąć na ocenę bezpieczeństwa projektu, wymusić rewizję parametrów lub osłabić jego pozycję w procesie standaryzacji postkwantowej. Skuteczny atak na parametr testowy nie przesądza automatycznie o losie całej rodziny, ale stanowi wyraźny sygnał ostrzegawczy.

W przypadku AES praktyczne ryzyko pozostaje niskie. Badanie nie łamie pełnego, 10-rundowego AES-128 i nie wskazuje na konieczność natychmiastowych zmian w produkcyjnych wdrożeniach. Mimo to publikacja ma duże znaczenie badawcze, bo pokazuje, że AI może skracać czas potrzebny na opracowywanie nowych pomysłów kryptanalitycznych.

Rekomendacje

Organizacje nie powinny reagować panicznie, ale powinny potraktować te wyniki jako ważny sygnał dla strategii kryptograficznej i planów migracyjnych.

• Monitorować procesy standaryzacyjne NIST oraz status kandydatów postkwantowych.
• Budować kryptograficzną zwinność, aby możliwa była wymiana algorytmów, parametrów i długości kluczy bez kosztownej przebudowy systemów.
• Zakładać, że modele AI będą coraz skuteczniej wspierały analizę formalną i odkrywanie nietrywialnych zależności matematycznych.
• Zwiększać nacisk na niezależne audyty, walidację założeń bezpieczeństwa i testowanie implementacji.
• Nie wyciągać pochopnego wniosku, że AES-128 przestał być bezpieczny w zastosowaniach produkcyjnych.

Podsumowanie

Nowe badania wskazują, że AI zaczyna odgrywać coraz większą rolę nie tylko w analizie implementacji, ale również w przyspieszaniu właściwej kryptanalizy. Atak na HAWK-256 ujawnia realne osłabienie parametru testowego i może wpłynąć na dalszą ocenę tego schematu w procesie standaryzacji.

Z kolei przyspieszenie ataku na 7-rundowy AES-128 ma obecnie głównie wartość naukową, ale potwierdza, że modele AI mogą wspierać tworzenie nowych metod badawczych w kryptografii. Dla praktyków bezpieczeństwa kluczowy wniosek jest jasny: przyszła odporność algorytmów będzie zależeć nie tylko od klasycznych analiz akademickich, lecz także od tego, jak skutecznie środowisko nauczy się wykorzystywać i kontrolować narzędzia AI.

Źródła

1. https://www.anthropic.com/research/discovering-cryptographic-weaknesses
2. https://www.anthropic.com/document/hawk_key_recovery.pdf
3. https://www.anthropic.com/document/aes_mobius_bridge.pdf
4. https://csrc.nist.gov/projects/pqc-dig-sig/round-3-additional-signatures
5. https://thehackernews.com/2026/07/claude-ai-just-cracked-post-quantum.html