Standardowy komponent jest punktem wyjścia do przeglądu, a nie certyfikatem dla całego komunikatora.
ML-KEM-768 pomaga dwóm stronom ustanowić wspólny sekret, który można następnie wykorzystać do ochrony wiadomości. Jest jednym z elementów systemu komunikacji, a nie kompletnym protokołem czatu, szyfrem wiadomości ani certyfikatem bezpieczeństwa aplikacji.
NIST opublikował FIPS 203 13 sierpnia 2024 roku, standaryzując ML-KEM i jego zestawy parametrów 512, 768 i 1024. Ich bezpieczeństwo opiera się na problemach kratowych uznawanych za odporne na ataki kwantowe. „Uznawane za odporne” to założenie bezpieczeństwa poparte analizą, a nie obietnica, że żadna przyszła słabość nie jest możliwa. NIST FIPS 203.
Gdzie KEM mieści się w szyfrowanym czacie
Przydatnym sposobem czytania deklaracji o szyfrowaniu jest prześledzenie materiału kluczowego:
- Uwierzytelnij zamierzonego rozmówcę. Wymiana kluczy z osobą podszywającą się pod kogoś nadal jest wymianą kluczy z niewłaściwą osobą.
- Ustanów wspólny materiał sekretny. KEM wnosi sekret poprzez enkapsulację i dekapsulację.
- Wyprowadź klucze do ich konkretnych zastosowań. Funkcja wyprowadzania kluczy rozdziela materiał używany przez różne części protokołu.
- Szyfruj i uwierzytelniaj wiadomości. Schemat szyfrowania uwierzytelnionego chroni treść i wykrywa nieuprawnione modyfikacje.
- Zarządzaj sesją w czasie. Rotacja i usuwanie kluczy, zmiany urządzeń i odzyskiwanie określają, co może ujawnić późniejsza kompromitacja.
Te kroki wyjaśniają, dlaczego standard dla kroku drugiego nie może zweryfikować całej aplikacji. FAQ NIST o kryptografii postkwantowej przedstawia kontekst wdrażania nowych standardów.
Po co łączyć ML-KEM z klasycznym uzgadnianiem kluczy?
Projekt hybrydowy wykorzystuje komponent postkwantowy obok klasycznego, takiego jak Diffie–Hellman na krzywych eliptycznych. Zamierzoną korzyścią jest unikanie wyłącznej zależności od jednego z zestawów założeń w okresie przejściowym.
Twierdzenie o bezpieczeństwie dotyczy całego mechanizmu łączenia i protokołu, a nie tylko listy dwóch algorytmów. Recenzenci muszą wiedzieć, które dane wejściowe są uwierzytelniane, jak są kodowane i łączone, jaki kontekst wiąże się z wyprowadzaniem kluczy i co dzieje się w przypadku awarii komponentu. Konkatenacja sekretów bez określonej konstrukcji nie jest argumentem bezpieczeństwa.
Dla użytkowników praktyczne pytanie nie brzmi: „Czy w ustawieniach napisano, że rozwiązanie jest odporne na ataki kwantowe?”. Brzmi ono: „Które rozmowy i wersje rzeczywiście korzystają z tej konstrukcji i jakie dowody potwierdzają to stwierdzenie?”.
Co dokumentuje Livara
Dokumentacja bezpieczeństwa Livary opisuje sesje rozmów bezpośrednich LVR1 korzystające z klasycznego materiału P-256 i ML-KEM-768 oraz AES-256-GCM do ochrony treści. Prywatne grupy LGS1 opisuje jako łańcuchy nadawców rozprowadzane przez sesje LVR1 parami. Są to różne warstwy: zwykła wiadomość grupowa niekoniecznie oznacza nową wymianę ML-KEM dla każdego odbiorcy.
Czytaj tę dokumentację jako opis twórcy. Wymienienie standardowych prymitywów nie dowodzi, że własna kompozycja Livary przeszła niezależny audyt ani że każda zainstalowana kompilacja implementuje ją poprawnie. Proof Lab wyraźnie ogranicza zakres demonstracji w przeglądarce: nie wykonuje ona kompletnych mechanizmów ratchet LVR1/LGS1 i nie stanowi audytu protokołu.
Czego nie obejmuje ochrona postkwantowa
| Pytanie | Dlaczego sam ML-KEM na nie nie odpowiada |
|---|---|
| Czy odbiorca może skopiować moją wiadomość? | Odbiorca otrzymuje czytelną treść. |
| Czy moje urządzenie jest wolne od oprogramowania szpiegującego? | Integralność urządzenia końcowego to osobne założenie zaufania. |
| Czy kopie zapasowe są chronione? | Klucze kopii zapasowych i zasady odzyskiwania wymagają własnego projektu. |
| Czy zmiany członkostwa w grupie są bezpieczne? | Znaczenie mają zasady uwierzytelniania, członkostwa i wymiany kluczy. |
| Czy usługa zachowuje metadane? | Szyfrowanie treści nie ukrywa automatycznie routingu ani czasu komunikacji. |
| Czy połączenie jest chronione tak samo jak czat tekstowy? | Sygnalizacja połączeń i media mogą używać innych protokołów. |
Model zagrożeń Livary również rozróżnia prywatne rozmowy i publiczne kanały oraz uznaje narażenie na poziomie urządzenia. Nie rozszerzaj deklaracji dotyczącej rozmów bezpośrednich na każdy obszar produktu.
Lista kontrolna kupującego dla „komunikatora FIPS 203”
Poproś o dokładny zestaw parametrów i wersję protokołu; opis uwierzytelniania rozmówców i łączenia kluczy; obsługiwane wersje klientów; zachowanie wobec niezgodnych klientów; oraz testy lub wyniki przeglądów powiązane z dostarczoną implementacją. Jeśli dostawca deklaruje walidację FIPS, poproś o odpowiedni wpis walidacyjny i jego zakres. Samo użycie algorytmu opisanego w publikacji FIPS nie jest dowodem walidacji produktu ani modułu.
Nie wnioskuj o czasie pracy baterii, przepustowości ani responsywności aplikacji z nazwy parametrów. Wymagają one pomiarów z udokumentowanym urządzeniem, kompilacją i obciążeniem.
Przydatną zmianą dla komunikacji jest nowe narzędzie długoterminowej poufności. Jego wartość zależy od integracji, implementacji i granic operacyjnych, a nie od zastąpienia jednego hasła marketingowego innym.
