Przesunięcie łańcucha przy każdej wiadomości i odświeżenie epoki postkwantowej rozwiązują różne części problemu mechanizmu zapadkowego.
Hybrydowy postkwantowy mechanizm zapadkowy aktualizuje klucze wiadomości, wykorzystując zarówno materiał klasyczny, jak i postkwantowy. Celem jest zachowanie ochrony przy starannie określonych założeniach, jeśli jeden składnik stanie się podatny na ataki, a zarazem ograniczenie z czasem szkód wynikających z określonych przypadków ujawnienia kluczy.
Livara dokumentuje to podejście w LVR1 z użyciem P-256 i ML-KEM-768. Zrozumienie projektu wymaga rozdzielenia początkowego ustanawiania kluczy, zwykłych aktualizacji łańcucha wiadomości i okresowych odświeżeń postkwantowych. Nie jest to ta sama operacja wykonywana dla każdej wiadomości.
Od wspólnego sekretu do zmieniających się kluczy wiadomości
Mechanizm ustanawiania kluczy daje uczestnikom tajny materiał, którego mogą użyć w harmonogramie wyprowadzania kluczy. Protokół zapadkowy następnie rozwija stan i wyprowadza klucze wiadomości, zamiast zachowywać jeden niezmienny klucz treści przez całą rozmowę.
NIST FIPS 203 określa ML-KEM, w tym zestaw parametrów ML-KEM-768. Ustanawia on wspólny sekret; szyfr z uwierzytelnianiem, taki jak AES-GCM, szyfruje treść wiadomości. Uwierzytelnianie i sposób łączenia składników należą do szerszego protokołu.
Przegląd bezpieczeństwa Livary opisuje hybrydowe ustanawianie, niezależne korzenie klasyczne i postkwantowe, jednokierunkowe łańcuchy wysyłania i odbierania postępujące wraz z wiadomościami oraz okresowe aktualizacje epok ML-KEM. Według tego opisu klucz wiadomości jest łączony z bieżącym korzeniem postkwantowym przed ochroną treści i nagłówka.
Nie należy przerabiać tego opisu na stwierdzenie „dla każdej wiadomości następuje nowa wymiana P-256 i nowa enkapsulacja ML-KEM”. Przesunięcie łańcucha może być stosunkowo niedrogim krokiem wyprowadzania klucza.
Co zmienia epoka
Epoka to okres stanu protokołu powiązany z konkretnym odświeżeniem. Rozłożenie większych komunikatów ustanawiających klucze między epoki może ograniczać powtarzany narzut komunikacyjny, ale sprawia też, że reguły odświeżania mają znaczenie dla bezpieczeństwa.
Osoba oceniająca powinna zapytać:
- Co uruchamia nową epokę: licznik, czas, działanie drugiej strony czy inny warunek?
- Jak uwierzytelniane są identyfikatory epok i materiał kluczowy?
- Co dzieje się z wiadomościami opóźnionymi, zduplikowanymi lub dostarczonymi poza kolejnością?
- Jak klient obsługuje brak aktualizacji lub starszą, niezgodną drugą stronę?
- Które stare sekrety pozostają na potrzeby opóźnionego dostarczenia i kiedy są usuwane?
Implementacja wymaga dokładnych odpowiedzi. Samo słowo „okresowe” nie jest kompletną specyfikacją odzyskiwania ani interoperacyjności.
Określanie rozmiarów prymitywów bez wymyślania benchmarku
FIPS 203 podaje dla ML-KEM-768 rozmiar klucza enkapsulacji 1184 bajty i rozmiar szyfrogramu 1088 bajtów. Są to kodowania prymitywów, a nie całkowity rozmiar wiadomości czy uzgadniania połączenia Livary. Nagłówki protokołu, podpisy, ramkowanie i częstotliwość przesyłania każdej wartości decydują o rzeczywistym ruchu.
Rozmiary kluczy P-256 również zależą od reprezentacji. Na przykład skompresowany i nieskompresowany punkt krzywej mają różne długości zakodowane. Porównanie nieopisanego „rozmiaru klucza P-256” z szyfrogramem ML-KEM nie jest pełną analizą przepustowości.
Aby ocenić koszt mechanizmu zapadkowego, zmierz bajty na rozmowę i epokę, czas CPU, pamięć, wybudzenia modułu radiowego i opóźnienie od końca do końca na reprezentatywnych urządzeniach. Podaj warunki kompilacji i sieci. Bez tych pomiarów nie jest uzasadniony ani „pomijalny wpływ na baterię”, ani uniwersalny czas wykonania poniżej milisekundy.
Poufność w przód i odzyskiwanie ochrony po kompromitacji
Poufność w przód ma chronić wcześniejsze wiadomości po ujawnieniu określonych późniejszych sekretów, pod warunkiem usunięcia wymaganych starych sekretów. Bezpieczeństwo po kompromitacji dotyczy odzyskania ochrony, gdy atakujący nie kontroluje już urządzenia końcowego, a do protokołu trafia nowy tajny materiał nieznany atakującemu.
Specyfikacja Double Ratchet wyjaśnia te rozróżnienia i granice odzyskiwania ochrony po włamaniu. Dalszy dostęp złośliwego oprogramowania, zmanipulowana losowość lub aktywny atakujący kontrolujący odpowiednie wymiany mogą udaremnić oczekiwane odzyskanie ochrony. Wysłanie jeszcze jednej wiadomości nie dowodzi, że skradziona sesja została unieważniona ani że przejęty telefon jest czysty.
Konstrukcja hybrydowa wymaga też poprawnego uwierzytelniania i łączenia składników. „Atakujący musi złamać oba algorytmy” to zamierzona właściwość przy założeniach danej konstrukcji, a nie bezwarunkowe stwierdzenie obejmujące błędy implementacji czy złośliwe urządzenia końcowe.
Zachowaj widoczne granice funkcji
W dokumentacji Livary klucze nadawców grup LGS1 są rozprowadzane przez sesje LVR1 między parami uczestników. Nie oznacza to, że łańcuch nadawcy grupowego jest strukturalnie identyczny z podwójnym mechanizmem zapadkowym czatu bezpośredniego. Aktualna strona bezpieczeństwa wyłącza też starsze, niezgodne grupy z E2EE i wymaga gotowości członków przed utworzeniem nowej szyfrowanej grupy.
Załączniki mają własne klucze treści przenoszone wewnątrz chronionej rozmowy. Połączenia i opcjonalne nagrywanie na serwerze wymagają osobnej oceny; nie wnioskuj o postkwantowej ochronie mediów tylko dlatego, że ścieżka sygnalizacji używa sesji hybrydowej. Kanały publiczne i metadane operacyjne pozostają poza poufnością treści prywatnych.
Co zwiększyłoby zaufanie?
Szukaj wersjonowanej specyfikacji, testów interoperacyjności i przypadków awarii, niezależnej oceny oraz jasnego związku między ocenionym kodem źródłowym a dostarczanym klientem. Standardowe algorytmy stanowią użyteczny dowód dotyczący składników, a nie certyfikację ich połączenia.
Proof Lab Livary demonstruje wybrane prymitywy klasyczne i wyraźnie wyłącza pełną kompozycję LVR1/LGS1 z tego lokalnego stanowiska pomiarowego. Jej model zagrożeń pozostaje niezbędnym kontekstem. Razem materiały te pomagają formułować pytania; nie należy przedstawiać ich jako zamiennika pełnej oceny protokołu i implementacji.



