Jämför kostnaden för en definierad operation och beläggen för ett definierat hot – inte bara ett träddiagram med ett diagram över avsändarnycklar.
Messaging Layer Security (MLS) och Livaras LGS1 är inte två utbytbara intyg på gruppchattars säkerhet. MLS är en IETF-protokollstandard; LGS1 är Livaras dokumenterade produktspecifika konstruktion. En rättvis jämförelse skiljer på arkitektur, belägg för implementationen och det beteende användarna faktiskt upplever.
Den viktigaste skillnaden är trädbaserat gemensamt grupptillstånd jämfört med avsändarnycklar som distribueras genom parvisa sessioner. Ingen av etiketterna säger ensam om en viss app hanterar en borttagen medlem, en enhet med föråldrat tillstånd eller en komprometterad nyckel korrekt.
Skillnaden i arkitektur
RFC 9420 specificerar MLS för asynkron etablering av gruppnycklar. Det använder ett ratchetträd och gruppepoker, med framåtsekretess och säkerhet efter kompromettering under angivna villkor. Trädstrukturen minskar vissa kostnader för nyckeluppdateringar när gruppen växer.
Livaras säkerhetsdokumentation beskriver LGS1 som en signerad avsändarkedja för varje medlem, distribuerad genom parvisa LVR1-sessioner och roterad vid medlemsändringar. Detta är ett produktpåstående, inte belägg för att LGS1 följer MLS eller har samma analys.
| Fråga | MLS | Livara LGS1:s dokumentation |
|---|---|---|
| Gemensam struktur | Ratchetträd och epoker | Kedjor per avsändare |
| Nyckeluppdateringar | Ändringar i grupptillståndet fastställs i en ny epok | Nya avsändarnycklar distribueras till medlemmarna |
| Specifikationens status | IETF-standard, RFC9420 | Publicerad produktspecifik beskrivning |
| Vad som återstår att bedöma | Appintegration och implementation | Fullständig specifikation, implementation och oberoende belägg |
Tabellen beskriver konstruktionskategorier. Den är inte ett prestandatest eller en säkerhetsrankning.
Vad ”logaritmisk” betyder – och inte betyder
En kryptografisk uppdatering kan använda ett logaritmiskt antal krypterade komponenter längs trädvägen utan att allt arbete i systemet blir logaritmiskt. Meddelanden måste fortfarande distribueras, klienter håller tillstånd och beteendet beror på gruppstrukturen och operationerna. Den gamla jämförelsen ”MLS behöver O(log N) meddelanden medan allt i LGS1 är snabbare” blandade olika kostnader och saknade mätningar.
MLS-arkitekturen, RFC 9750, behandlar leveranstjänsten separat från kryptografisk nyckeletablering. Den diskuterar meddelandedistribution och ordningen på gruppändringar. Den uppdelningen är viktig: klientberäkning, byte i en commit, serverns totala utskick och återanslutningstrafik är olika mått.
En meningsfull prestandarapport bör ange:
- gruppstorlek och antal enheter per person;
- om operationen är ett vanligt meddelande, medlemsborttagning, nyckeluppdatering eller återanslutning;
- byte skickade av den initierande klienten jämfört med total leveranstrafik;
- förfluten tid, enhetsmodell, implementationsversion och nätverksförhållanden;
- kostnaden för missade uppdateringar och upprepade medlemsändringar.
Utan dessa uppgifter är påståenden om ”millisekunder”, ”låg tillståndsoverhead” eller överlägsenhet vid en viss gruppstorlek inte fastställda.
Att ta bort en medlem är ett livscykeltest
Att en administratör tar bort ett konto är bara en del av säkerhetsfrågan. Klienterna måste enas om det nya medlemstillståndet, använda lämpliga nya nycklar och undvika att lämna dem till uteslutna enheter. En person som redan har gammal klartext eller gamla nycklar kan behålla åtkomsten till äldre innehåll; borttagningen kan inte få kopiorna att försvinna.
För båda systemen frågar ett användbart test: kan den borttagna enheten, när borttagningen är klar, dekryptera ett nytt testmeddelande utan känsliga uppgifter? Kan en medlem som varit offline komma ikapp säkert? Hanteras alla enheter som hör till kontot? Gör gränssnittet fel eller medlemsändringar synliga?
Detta är föreslagna utvärderingsfrågor, inte resultat från tester som utförts här. En produktjämförelse bör publicera observerat utfall och testad version i stället för att likställa ett lyckat administratörsklick med kryptografisk uteslutning.
Framåtsekretess och återhämtning är villkorade
Att hålla gamla meddelanden skyddade efter senare kompromettering beror på att gammalt hemligt material tas ur bruk. Att återställa skyddet för framtida meddelanden beror på att nya hemligheter införlivas efter att angriparen förlorat relevant åtkomst. I MLS är behandlingen av gruppuppdateringar en del av återhämtningen; att bara skicka en uppdatering är inte samma sak som att alla medlemmar har tillämpat den. Se säkerhetsövervägandena i RFC 9420.
För en konstruktion med avsändarnycklar bör du fråga hur varje avsändares komprometterade tillstånd ersätts och distribueras på nytt. En envägskedja bör inte i sig beskrivas som självläkande mot en angripare som känner dess aktuella tillstånd. Det parvisa skyddet vid omdistribution är relevant, men ersätter inte en fullständig analys på gruppnivå.
Postkvantpåståenden kräver en specifik chiffersvit och omfattning
Chiffersviterna i grundversionen av RFC9420 använder klassiska mekanismer för offentlig nyckelkryptografi. MLS är utbyggbart, så ett påstående om en viss implementation bör ange dess faktiska svit och tillägg i stället för att förklara alla MLS-installationer för alltid klassiska.
LGS1:s dokumenterade användning av hybridbaserad LVR1-distribution är ett annat påstående än en oberoende analyserad postkvantgaranti för varje gruppoperation. FIPS 203 standardiserar ML-KEM; det certifierar inte hela grupprotokollet som införlivar det. Bedöm autentisering, medlemsändringar, nyckelkompromettering och implementation tillsammans, inte bara KEM-namnet.
Vad du bör begära innan du väljer produkt
Be om aktuell protokollspecifikation, testvektorer och en versionsspecifik oberoende granskning, inklusive olösta fynd. Jämför sedan vanliga produktkrav: enhetsstöd, uppdateringsbeteende, återställning, modereringsroller och data som servrarna behåller.
MLS-arkitekturen behandlar uttryckligen applikationstjänster och deras tillitsantaganden. På samma sätt bör Livaras hotmodell läsas tillsammans med produktpåståendena. Kryptering gör inte behöriga deltagare pålitliga, stoppar inte skärmbilder och tar inte bort alla former av metadata.
Om belägg saknas, anteckna ”inte fastställt” i stället för att automatiskt kalla konstruktionen osäker eller överlägsen. Beslutet bör spegla gruppens risker och kvaliteten på tillgängliga belägg.
Vanliga frågor
Är LGS1 en implementation av MLS?
De publicerade beskrivningarna visar olika arkitekturer. Artikeln identifierar inte LGS1 som en MLS-implementation och hävdar inte interoperabilitet.
Kräver MLS att alla medlemmar är online samtidigt?
Nej. Asynkron användning ingår i konstruktionen. Appar behöver fortfarande regler för försenade uppdateringar, föråldrat tillstånd och medlemmar som länge varit offline.
Avgör postkvantdistribution av nycklar gruppens säkerhet?
Nej. Den hanterar en del av nyckeletableringen. Identitet, medlemskap, nyckellivscykel, ändpunktssäkerhet och implementation kräver fortfarande belägg.
Vilken konstruktion är snabbast?
Artikeln innehåller inget prestandatest som utser en vinnare. Mät de operationer och den driftsättning som är viktiga för din grupp.
