Porównuj koszt określonej operacji i dowody dla określonego zagrożenia — nie tylko diagram drzewa z diagramem kluczy nadawców.
Messaging Layer Security (MLS) i LGS1 Livary nie są dwoma zamiennymi certyfikatami bezpieczeństwa czatów grupowych. MLS jest standardem protokołu IETF; LGS1 to udokumentowany projekt właściwy dla produktu Livara. Uczciwe porównanie wymaga rozdzielenia architektury, dowodów dotyczących implementacji i zachowania, którego rzeczywiście doświadczają użytkownicy.
Kluczowa różnica to współdzielony stan grupy oparty na drzewie w porównaniu z kluczami nadawców rozprowadzanymi przez sesje parami. Żadna z tych etykiet sama nie mówi, czy konkretna aplikacja poprawnie obsługuje usuniętego członka, urządzenie z nieaktualnym stanem lub przejęty klucz.
Różnica architektoniczna
RFC 9420 określa MLS do asynchronicznego ustanawiania kluczy grupowych. Wykorzystuje drzewo ratchet i epoki grupy, zapewniając poufność w przód i bezpieczeństwo po kompromitacji przy określonych warunkach. Struktura drzewa zmniejsza pewne koszty aktualizacji kluczy wraz ze wzrostem grupy.
Dokumentacja bezpieczeństwa Livary opisuje LGS1 jako podpisany łańcuch nadawcy dla każdego członka, rozprowadzany przez sesje LVR1 parami i rotowany przy zmianach członkostwa. Jest to deklaracja produktu, a nie dowód zgodności LGS1 z MLS ani takiej samej analizy bezpieczeństwa.
| Pytanie | MLS | Dokumentacja Livara LGS1 |
|---|---|---|
| Wspólna struktura | Drzewo ratchet i epoki | Łańcuchy poszczególnych nadawców |
| Aktualizacje kluczy | Zmiany stanu grupy zatwierdzane w nowej epoce | Świeże klucze nadawców rozprowadzane do członków |
| Status specyfikacji | Standard IETF, RFC9420 | Opublikowany opis właściwy dla produktu |
| Co nadal wymaga oceny | Integracja z aplikacją i implementacja | Pełna specyfikacja, implementacja i niezależne dowody |
Tabela opisuje kategorie projektowe. Nie jest testem wydajności ani rankingiem bezpieczeństwa.
Co oznacza „logarytmiczny” — a czego nie oznacza
Aktualizacja kryptograficzna może używać logarytmicznej liczby zaszyfrowanych składników ścieżki drzewa, nie czyniąc całej pracy systemu logarytmiczną. Wiadomości nadal trzeba rozprowadzać, klienci utrzymują stan, a zachowanie zależy od struktury grupy i operacji. Dawne porównanie „MLS potrzebuje O(log N) wiadomości, a wszystko w LGS1 jest szybsze” mieszało różne koszty i nie przedstawiało pomiarów.
Architektura MLS, RFC 9750, traktuje usługę dostarczania oddzielnie od kryptograficznego ustanawiania kluczy. Omawia dystrybucję wiadomości i kolejność zmian w grupie. To rozdzielenie ma znaczenie: obliczenia klienta, bajty w komunikacie commit, łączny ruch rozsyłania przez serwer i ruch przy ponownym połączeniu to różne miary.
Między innymi następujące informacje powinny znaleźć się w miarodajnym raporcie wydajności:
- rozmiar grupy i liczba urządzeń na osobę;
- czy operacja jest zwykłą wiadomością, usunięciem członka, aktualizacją klucza czy ponownym połączeniem;
- bajty wysłane przez inicjującego klienta w porównaniu z całkowitym ruchem dostarczania;
- czas trwania, model urządzenia, wersja implementacji i warunki sieciowe;
- koszt pominiętych aktualizacji i wielokrotnych zmian członkostwa.
Bez tych szczegółów twierdzenia o „milisekundach”, „małym narzucie stanu” lub przewadze przy określonej wielkości grupy nie są ustalone.
Usunięcie członka jest testem cyklu życia
Usunięcie konta przez administratora to tylko część kwestii bezpieczeństwa. Klienci muszą uzgodnić nowy stan członkostwa, używać odpowiednich świeżych kluczy i nie przekazywać ich wykluczonym urządzeniom. Osoba posiadająca już stary tekst jawny lub stare klucze może zachować dostęp do dawnej treści; usunięcie nie sprawi, że jej kopie znikną.
Dla obu systemów przydatny test pyta: czy po zakończeniu usuwania usunięte urządzenie może odszyfrować nową wiadomość testową bez wrażliwych danych? Czy członek, który był offline, bezpiecznie nadrobi zaległości? Czy obsłużono wszystkie urządzenia należące do konta? Czy interfejs uwidacznia błędy lub zmiany członkostwa?
Są to proponowane pytania do oceny, a nie wyniki testów przeprowadzonych w tym artykule. Porównanie produktów powinno publikować obserwowany wynik i testowaną wersję zamiast utożsamiać udane kliknięcie administratora z kryptograficznym wykluczeniem.
Poufność w przód i odzyskiwanie ochrony są warunkowe
Ochrona starych wiadomości po późniejszej kompromitacji zależy od wycofywania starego materiału sekretnego. Przywrócenie ochrony przyszłych wiadomości zależy od włączenia świeżych sekretów po utracie odpowiedniego dostępu przez napastnika. W MLS przetwarzanie aktualizacji grupy jest częścią tego odzyskiwania; samo wysłanie aktualizacji nie jest tym samym, co zastosowanie jej przez każdego członka. Zobacz uwagi o bezpieczeństwie w RFC 9420.
W projekcie opartym na kluczach nadawców pytaj, jak przejęty stan każdego nadawcy jest zastępowany i ponownie rozprowadzany. Samego łańcucha jednokierunkowego nie należy opisywać jako automatycznie odzyskującego bezpieczeństwo przed napastnikiem znającym jego bieżący stan. Ochrona parami stosowana przy redystrybucji jest istotna, ale nie zastępuje pełnej analizy na poziomie grupy.
Twierdzenia postkwantowe wymagają konkretnego zestawu szyfrów i zakresu
Zestawy szyfrów zdefiniowane w podstawowym RFC9420 korzystają z klasycznych mechanizmów klucza publicznego. MLS jest rozszerzalny, więc twierdzenie o konkretnej implementacji powinno wskazywać jej faktyczny zestaw i rozszerzenia, a nie deklarować, że wszystkie wdrożenia MLS pozostaną na zawsze klasyczne.
Udokumentowane wykorzystanie hybrydowej dystrybucji LVR1 w LGS1 to inne twierdzenie niż niezależnie przeanalizowana gwarancja postkwantowa dla każdej operacji grupowej. FIPS 203 standaryzuje ML-KEM; nie certyfikuje całego protokołu grupowego, który go wykorzystuje. Oceniaj łącznie uwierzytelnianie, zmiany członkostwa, przejęcie kluczy i implementację, a nie tylko nazwę KEM.
O co poprosić przed wyborem produktu
Poproś o aktualną specyfikację protokołu, wektory testowe i niezależny przegląd konkretnego wydania, w tym nierozwiązane ustalenia. Następnie porównaj zwykłe wymagania produktowe: obsługiwane urządzenia, zachowanie aktualizacji, odzyskiwanie, role moderacji i dane zachowywane przez serwery.
Architektura MLS wyraźnie uwzględnia usługi aplikacyjne i ich założenia dotyczące zaufania. Podobnie model zagrożeń Livary należy czytać obok deklaracji produktu. Szyfrowanie nie czyni uprawnionych uczestników godnymi zaufania, nie zatrzymuje zrzutów ekranu ani nie usuwa każdej postaci metadanych.
Jeśli brakuje dowodów, zapisz „nie ustalono” zamiast automatycznie uznawać projekt za niebezpieczny lub lepszy. Decyzja powinna odzwierciedlać ryzyka Twojej grupy i jakość dostępnych dowodów.
Najczęściej zadawane pytania
Czy LGS1 jest implementacją MLS?
Opublikowane opisy pokazują różne architektury. Ten artykuł nie identyfikuje LGS1 jako implementacji MLS ani nie deklaruje interoperacyjności.
Czy MLS wymaga, by wszyscy członkowie byli online jednocześnie?
Nie. Asynchroniczne użycie jest częścią jego projektu. Aplikacje nadal potrzebują zasad obsługi opóźnionych aktualizacji, nieaktualnego stanu i członków długo pozostających offline.
Czy postkwantowa dystrybucja kluczy rozstrzyga bezpieczeństwo grupy?
Nie. Dotyczy części ustanawiania kluczy. Tożsamość, członkostwo, cykl życia kluczy, bezpieczeństwo urządzeń końcowych i implementacja nadal wymagają dowodów.
Który projekt jest szybszy?
W tym artykule nie ma testu wydajności wskazującego zwycięzcę. Mierz operacje i wdrożenie, które mają znaczenie dla Twojej grupy.
