Een protocolnaam bewijst geen veiligheid: architectuur, implementatie en werkelijk gedrag bij wijzigingen van leden en sleutels zijn doorslaggevend.
Messaging Layer Security (MLS) en Livara’s LGS1 zijn geen twee uitwisselbare certificaten voor veilige groepschats. MLS is een IETF-protocolstandaard; LGS1 is Livara’s gedocumenteerde productspecifieke ontwerp. Een eerlijke vergelijking onderscheidt architectuur, bewijs over de implementatie en het gedrag dat gebruikers daadwerkelijk ervaren.
Het belangrijkste verschil is een gedeelde groepsstatus op basis van een boom tegenover afzendersleutels die via paarsgewijze sessies worden verspreid. Geen van beide namen vertelt op zichzelf of een bepaalde toepassing correct omgaat met een verwijderd lid, een verouderd apparaat of een gecompromitteerde sleutel.
Het architectuurverschil
RFC 9420 specificeert MLS voor het asynchroon opzetten van groepssleutels. Het gebruikt een ratchetboom en groepsepochs, met forward secrecy en post-compromise security onder vastgelegde voorwaarden. De boomstructuur verlaagt bepaalde kosten voor sleutelupdates naarmate de groep groter wordt.
Livara’s beveiligingsdocumentatie beschrijft LGS1 als een ondertekende afzenderketen voor elk lid, verspreid via paarsgewijze LVR1-sessies en geroteerd bij wijzigingen in het lidmaatschap. Dit is een productclaim, geen bewijs dat LGS1 aan MLS voldoet of dezelfde analyse heeft.
| Vraag | MLS | Documentatie van Livara LGS1 |
|---|---|---|
| Gedeelde structuur | Ratchetboom en epochs | Ketens per afzender |
| Sleutelupdates | Wijzigingen in de groepsstatus worden vastgelegd in een nieuwe epoch | Nieuwe afzendersleutels worden onder leden verspreid |
| Status van de specificatie | IETF-standaard, RFC9420 | Gepubliceerde productspecifieke beschrijving |
| Wat nog moet worden beoordeeld | Applicatie-integratie en implementatie | Volledige specificatie, implementatie en onafhankelijk bewijs |
Deze tabel beschrijft ontwerpcategorieën. Het is geen benchmark of veiligheidsranglijst.
Wat ‘logaritmisch’ wel en niet betekent
Een cryptografische update kan een logaritmisch aantal versleutelde boompadcomponenten gebruiken zonder dat al het werk in het systeem logaritmisch wordt. Berichten moeten nog steeds worden verspreid, clients bewaren status en het gedrag hangt af van de groepsstructuur en de bewerkingen. De oude vergelijking ‘MLS heeft O(log N) berichten nodig terwijl alles in LGS1 sneller is’ vermengde verschillende kosten en bood geen metingen.
De MLS-architectuur, RFC 9750, behandelt de bezorgdienst afzonderlijk van het cryptografisch opzetten van sleutels. Ze bespreekt berichtdistributie en de volgorde van groepswijzigingen. Dat onderscheid is belangrijk: clientberekeningen, bytes in een commit, totale serverdistributie en herverbindingverkeer zijn verschillende maatstaven.
Een betekenisvol prestatierapport moet vermelden:
- de groepsgrootte en het aantal apparaten per persoon;
- of het gaat om een gewoon bericht, het verwijderen van een lid, een sleutelupdate of opnieuw verbinden;
- de bytes die de initiërende client verstuurt tegenover het totale bezorgverkeer;
- de verstreken tijd, het apparaatmodel, de implementatieversie en de netwerkomstandigheden;
- de kosten van gemiste updates en herhaalde lidmaatschapswijzigingen.
Zonder deze details zijn claims over ‘milliseconden’, ‘weinig statusoverhead’ of superioriteit bij een bepaalde groepsgrootte niet aangetoond.
Een lid verwijderen is een levenscyclustest
Een beheerder die een account verwijdert, is slechts één onderdeel van het beveiligingsverhaal. Clients moeten het eens worden over de nieuwe lidmaatschapsstatus, geschikte nieuwe sleutels gebruiken en voorkomen dat uitgesloten apparaten die sleutels krijgen. Iemand die al oude leesbare tekst of oude sleutels heeft, kan toegang tot oude inhoud behouden; verwijdering laat diens kopieën niet verdwijnen.
Voor beide systemen stelt een nuttige test de volgende vragen: kan het verwijderde apparaat na voltooide verwijdering een nieuw niet-gevoelig testbericht ontsleutelen? Kan een lid dat offline was veilig bijwerken? Worden alle apparaten van een account meegenomen? Maakt de interface fouten of lidmaatschapswijzigingen zichtbaar?
Dit zijn voorgestelde beoordelingsvragen, geen resultaten van tests die hier zijn uitgevoerd. Een productvergelijking moet de waargenomen uitkomst en de geteste versie publiceren, in plaats van een geslaagde beheerdersklik gelijk te stellen aan cryptografische uitsluiting.
Forward secrecy en herstel zijn voorwaardelijk
Oude berichten beschermd houden na een latere compromittering hangt af van het buiten gebruik stellen van oud geheim materiaal. De bescherming van toekomstige berichten herstellen vereist nieuwe geheimen nadat de aanvaller de relevante toegang verliest. Bij MLS hoort het verwerken van groepsupdates bij dat herstel; alleen een update versturen betekent niet dat elk lid deze heeft toegepast. Zie de beveiligingsoverwegingen in RFC 9420.
Vraag bij een ontwerp met afzendersleutels hoe de gecompromitteerde status van elke afzender wordt vervangen en opnieuw verspreid. Een eenrichtingsketen mag op zichzelf niet worden beschreven als automatisch herstellend tegenover een aanvaller die de huidige status kent. Paarsgewijze bescherming tijdens de herdistributie is relevant, maar vervangt geen volledige analyse op groepsniveau.
Postkwantumclaims vereisen een specifieke cryptografische suite en reikwijdte
De cryptografische suites in de basisversie van RFC9420 gebruiken klassieke openbare-sleutelmechanismen. MLS is uitbreidbaar, dus een claim over een specifieke implementatie moet de werkelijke suite en uitbreidingen noemen, in plaats van alle MLS-toepassingen voor altijd klassiek te verklaren.
Het gedocumenteerde gebruik van hybride LVR1-distributie door LGS1 is een andere claim dan een onafhankelijk geanalyseerde postkwantumgarantie voor elke groepsbewerking. FIPS 203 standaardiseert ML-KEM; het certificeert niet het volledige groepsprotocol waarin het wordt opgenomen. Beoordeel authenticatie, lidmaatschapswijzigingen, sleutelcompromittering en implementatie samen, niet alleen de naam van het KEM.
Wat je moet opvragen voordat je een product kiest
Vraag om de actuele protocolspecificatie, testvectoren en een releasegebonden onafhankelijke beoordeling, inclusief onopgeloste bevindingen. Vergelijk daarna gewone productvereisten: ondersteunde apparaten, updategedrag, herstel, moderatierollen en gegevens die servers bewaren.
De MLS-architectuur houdt expliciet rekening met applicatiediensten en hun vertrouwensaannames. Lees ook Livara’s dreigingsmodel samen met de productclaims. Versleuteling maakt bevoegde deelnemers niet betrouwbaar, verhindert geen screenshots en verwijdert niet elke vorm van metadata.
Ontbreekt bewijs, noteer dan ‘niet aangetoond’ in plaats van een ontwerp automatisch onveilig of superieur te noemen. De beslissing moet de risico’s van je groep en de kwaliteit van het beschikbare bewijs weerspiegelen.
Veelgestelde vragen
Is LGS1 een implementatie van MLS?
De gepubliceerde beschrijvingen tonen verschillende architecturen. Dit artikel duidt LGS1 niet aan als een MLS-implementatie en claimt geen interoperabiliteit.
Vereist MLS dat alle leden tegelijk online zijn?
Nee. Asynchroon gebruik maakt deel uit van het ontwerp. Toepassingen hebben nog steeds beleid nodig voor vertraagde updates, verouderde status en leden die langdurig offline zijn.
Beslist postkwantumsleuteldistributie over de volledige groepsveiligheid?
Nee. Ze behandelt een deel van het opzetten van sleutels. Identiteit, lidmaatschap, sleutellevenscyclus, eindpuntbeveiliging en implementatie vereisen nog steeds bewijs.
Welk ontwerp is sneller?
Dit artikel bevat geen benchmark die een winnaar vaststelt. Meet de bewerkingen en de inzetomgeving die voor je groep belangrijk zijn.
