Klucze wstępne pozwalają odbiorcy być offline podczas ustanawiania sesji. Nie eliminują potrzeby drogi dostarczenia ani starannego zarządzania cyklem życia kluczy prywatnych.
Odbiorca będący offline może otrzymać zaszyfrowaną wiadomość później, ponieważ jego urządzenie wcześniej opublikowało publiczny materiał kluczowy. Nadawca nadal potrzebuje dostępnej usługi dostarczania; „szyfrowanie asynchroniczne” nie oznacza, że wiadomości pokonują awarię sieci albo natychmiast pojawiają się na odłączonym telefonie.
Projekty postkwantowe rozszerzają ten pomysł o mechanizm enkapsulacji klucza. Ważne pytania dotyczą tego, jak ustanawiany jest początkowy sekret, jak wycofuje się stare klucze prywatne i jak późniejsze wiadomości odnawiają bezpieczeństwo.
Klucze wstępne rozwiązują problem synchronizacji w czasie
Wyobraź sobie, że Maya jest offline, gdy Sam rozpoczyna nową rozmowę. Urządzenie Mayi wcześniej przesłało publiczne klucze wstępne. Sam może pobrać ten materiał, wykonać część uzgadniania klucza po stronie nadawcy i wysłać pierwszą zaszyfrowaną wiadomość. Maya przetwarza ją po ponownym połączeniu, używając kluczy prywatnych przechowywanych na swoim urządzeniu.
Serwer dostarcza więc informacje publiczne i kolejkuje zaszyfrowane dane; nie musi posiadać wynikowego sekretu wiadomości. Specyfikacja X3DH firmy Signal stanowi pierwotny opis takiego projektu asynchronicznego. Podpisany klucz wstępny i jednorazowy klucz wstępny mają różne okresy użycia i role; „klucz wstępny” nie oznacza tajnego hasła przesłanego na serwer.
W już ustanowionej rozmowie aplikacja może korzystać z istniejącego stanu sesji zamiast powtarzać konfigurację początkową dla każdej wiadomości. Rozpoczęcie sesji i rozwijanie jej kluczy wiadomości to oddzielne operacje.
Co wnosi postkwantowy KEM
Mechanizm enkapsulacji klucza ma trzy podstawowe operacje: generowanie kluczy, enkapsulację z użyciem klucza publicznego i dekapsulację z użyciem odpowiadającego mu klucza prywatnego. Enkapsulacja tworzy zarówno wspólny sekret, jak i szyfrogram. Szyfrogram można dostarczyć później; sam sekret nie jest przesyłany jawnie.
NIST FIPS 203 standaryzuje ML-KEM. Dla ML-KEM-768 publiczny klucz enkapsulacji ma 1184 bajty, szyfrogram 1088 bajtów, a wspólny sekret 32 bajty. Są to rozmiary na poziomie algorytmu, a nie rozmiar całego pakietu komunikatora. Podpisy, klucze klasyczne, identyfikatory i opakowanie transportowe zwiększają narzut; klucz publiczny zapisany w pamięci podręcznej nie musi towarzyszyć każdej wiadomości.
W konstrukcji hybrydowej protokół łączy klasyczny i postkwantowy materiał sekretny zgodnie z określonym schematem wyprowadzania kluczy. Samo zestawienie nazw algorytmów nie dowodzi bezpieczeństwa ich połączenia. Powiązanie z tożsamością, walidacja, separacja domen i obsługa błędów wymagają specyfikacji i przeglądu.
Przykład: PQXDH, a nie uniwersalny wzorzec
Specyfikacja PQXDH firmy Signal opisuje podpisane jednorazowe postkwantowe klucze wstępne i podpisany klucz ostatniej szansy. Nadawca weryfikuje dostarczone podpisy, przeprowadza uzgadnianie klucza i dołącza szyfrogram KEM oraz identyfikatory kluczy do pierwszej zaszyfrowanej wiadomości. Odbiorca później wyprowadza ten sam sekret i przetwarza wiadomość.
Klucz ostatniej szansy umożliwia ustanowienie sesji, gdy jednorazowe klucze KEM są niedostępne, ale analiza skutków kompromitacji nie jest identyczna. Usuwanie i rotacja kluczy prywatnych wpływają na ochronę wcześniejszych sesji. Specyfikacja rozróżnia też postkwantową poufność w przód i uwierzytelnianie wobec aktywnego napastnika kwantowego. Tych szczegółów nie należy zastępować stwierdzeniem „tryb awaryjny nie ma kosztu dla bezpieczeństwa”.
PQXDH jest jedną określoną konstrukcją. Nie należy przenosić jej konkretnych krzywych, podpisów ani wyborów parametrów do opisu innego produktu, jeśli ten produkt ich nie dokumentuje.
Mechanizm ratchet to nie to samo co pula kluczy wstępnych
Klucze wstępne wspierają ustanawianie sesji. Protokół typu ratchet zmienia sekrety w trakcie rozmowy. Specyfikacja Double Ratchet wyjaśnia ewolucję kluczy wiadomości i nowsze postkwantowe konstrukcje ratchet, w tym projekty, które nie przesyłają pełnej wymiany postkwantowej z każdą wiadomością aplikacji.
Poufność w przód dotyczy wcześniejszych wiadomości po późniejszym przejęciu kluczy. Bezpieczeństwo po kompromitacji dotyczy przywracania ochrony przyszłej komunikacji po utracie dostępu przez napastnika i włączeniu świeżego materiału sekretnego. Żadne z nich nie oznacza, że złośliwe oprogramowanie może bez końca pozostawać na telefonie, podczas gdy kryptografia w jakiś sposób ukrywa przed nim tekst jawny dostępny na tym telefonie.
Usunięcie publicznego klucza wstępnego z serwera uniemożliwia jego zwykłe ponowne użycie; nie jest równoważne usunięciu odpowiadającego mu prywatnego klucza z urządzenia końcowego. Użyteczny audyt sprawdza zarówno reguły cyklu życia, jak i zachowanie opóźnionych wiadomości.
Co dokumentuje Livara — i co nadal wymaga dowodów
Strona bezpieczeństwa Livary opisuje hybrydowe ustanawianie sesji z użyciem jednorazowych kluczy, gdy są dostępne, zwykłe rozwijanie łańcucha wiadomości i okresowe epoki ML-KEM. Różni się to od dawnego twierdzenia, że każda wiadomość wykonuje pełną, świeżą wymianę ML-KEM. Są to stwierdzenia dokumentacji produktu, a nie niezależna weryfikacja implementacji.
Nie wyciągaj z tych stwierdzeń wniosków o konkretnej polityce awaryjnej po wyczerpaniu kluczy, częstotliwości ich uzupełniania ani wartości opóźnienia sieci. Te pytania wymagają dokumentacji protokołu dla konkretnego wydania lub wyników pomiarów. Proof Lab również nie jest kompletnym testem asynchronicznego ustanawiania sesji, wyczerpania kluczy ani odzyskiwania opóźnionych wiadomości.
Jak oceniać deklaracje dotyczące wiadomości offline
Poproś dostawcę lub recenzenta o dowody obejmujące następujące przypadki:
| Przypadek testowy | Co obserwować |
|---|---|
| Pierwsza wiadomość do odłączonego kontaktu | Jakiego publicznego materiału kluczowego użyto i kiedy odbiorca rzeczywiście otrzymuje wiadomość |
| Wyczerpane jednorazowe klucze wstępne | Czy ustanawianie sesji zostaje zatrzymane, czy stosuje udokumentowany tryb awaryjny, oraz jaki kompromis bezpieczeństwa zadeklarowano |
| Odbiorca ponownie instaluje aplikację lub zmienia tożsamość | Czy stare wiadomości w kolejce nadal można odszyfrować i czy zmiany kluczy są widoczne |
| Wiadomości opóźnione lub dostarczone w zmienionej kolejności | Limity przechowywania, obsługa pominiętych kluczy i zrozumiałe błędy |
| Powrót po długiej nieobecności | Bezpieczne odświeżenie kluczy, ograniczony zakres przetwarzania i dokładny status dostarczenia |
| Porównanie wydajności | Urządzenie, wersja aplikacji, sieć, rozmiar danych oraz oddzielne pomiary ustanawiania nowej sesji i sesji już ustanowionej |
Używaj kont testowych i wiadomości bez wrażliwych danych. Udany test dostarczenia demonstruje dany scenariusz, a nie każdą właściwość kryptograficzną. Z kolei nieudane dostarczenie może wynikać z sieci lub cyklu życia, a nie ze złamania szyfru.
Najczęściej zadawane pytania
Czy odbiorca może być offline, gdy wysyłam wiadomość?
Tak, jeśli aplikacja ma wymagany materiał publiczny i infrastrukturę dostarczania oraz przechowywania. Odbiorca nie może przeczytać wiadomości w kolejce, dopóki jego urządzenie nie będzie mogło jej pobrać i przetworzyć.
Czy większe klucze KEM zawsze zauważalnie spowalniają rozmowy?
Z samego rozmiaru klucza nie wynika uniwersalne twierdzenie o czasie. Znaczenie mają częstotliwość ustanawiania sesji, grupowanie operacji, pamięć podręczna, implementacja i warunki sieciowe. Publikuj wyniki testów wydajności zamiast obiecywać zerowy narzut.
Czy podpisany klucz wstępny dowodzi, kto stoi za kontem?
Uwierzytelnia materiał względem tożsamości podpisującej. Powiązanie tej tożsamości z osobą, z którą chcesz się skontaktować, jest oddzielnym zagadnieniem zaufania i weryfikacji.
Czy szyfrowanie postkwantowe działa bez jakiegokolwiek połączenia?
Niektóre obliczenia lokalne można wykonywać offline. Dostarczanie wiadomości nadal wymaga drogi komunikacji; kryptografia jej nie zapewnia.
