De nuttige vooruitgang is een nieuw hulpmiddel voor langdurige vertrouwelijkheid. De waarde hangt af van integratie, implementatie en operationele grenzen.
ML-KEM-768 helpt twee partijen een gedeeld geheim tot stand te brengen dat vervolgens kan worden gebruikt om berichten te beschermen. Het is één onderdeel van een berichtensysteem, geen volledig chatprotocol, geen versleutelingsalgoritme voor berichten en geen certificaat dat een app veilig is.
NIST publiceerde FIPS 203 op 13 augustus 2024 en standaardiseerde daarmee ML-KEM en de parametersets 512, 768 en 1024. Hun beveiliging berust op roosterproblemen waarvan wordt aangenomen dat ze bestand zijn tegen kwantumaanvallen. ‘Aangenomen dat ze bestand zijn’ is een beveiligingsaanname die door analyse wordt ondersteund, geen belofte dat een toekomstige zwakte onmogelijk is. NIST FIPS 203.
Waar een KEM in een versleutelde chat past
Een nuttige manier om een versleutelingsclaim te lezen is het sleutelmateriaal te volgen:
- Authenticeer de bedoelde gesprekspartner. Een sleuteluitwisseling met een bedrieger blijft een uitwisseling met de verkeerde persoon.
- Breng gedeeld geheim materiaal tot stand. Een KEM levert een geheim via inkapseling en ontkapseling.
- Leid sleutels af voor hun specifieke doelen. Een sleutelafleidingsfunctie scheidt het materiaal dat verschillende delen van het protocol gebruiken.
- Versleutel en authenticeer berichten. Een geauthenticeerd versleutelingsschema beschermt inhoud en detecteert ongeoorloofde wijzigingen.
- Beheer de sessie door de tijd heen. Sleutelrotatie, verwijdering, apparaatwisselingen en herstel bepalen wat een latere compromittering kan blootleggen.
Deze stappen verklaren waarom een standaard voor stap twee niet de hele toepassing kan valideren. De postkwantum-FAQ van NIST geeft context voor de invoering van de nieuwe standaarden.
Waarom ML-KEM combineren met klassieke sleutelovereenkomst?
Een hybride ontwerp gebruikt een postkwantumcomponent naast een klassieke component, zoals Diffie–Hellman met elliptische krommen. Het beoogde voordeel is tijdens een overgang niet uitsluitend van een van beide groepen aannames afhankelijk te zijn.
De beveiligingsclaim hoort bij de volledige combinatiefunctie en het protocol, niet slechts bij een lijst van twee algoritmen. Beoordelaars moeten weten welke invoer wordt geauthenticeerd, hoe die wordt gecodeerd en gecombineerd, welke context in de afleiding wordt gebonden en wat er gebeurt wanneer een component faalt. Geheimen achter elkaar plaatsen zonder een gespecificeerde constructie is geen beveiligingsargument.
Voor gebruikers is de praktische vraag niet: ‘Staat op de instellingenpagina kwantumveilig?’ Het is: ‘Welke gesprekken en versies gebruiken deze constructie daadwerkelijk en welk bewijs ondersteunt die uitspraak?’
Wat Livara documenteert
Livara’s beveiligingsdocumentatie beschrijft LVR1-sessies voor directe chats met klassiek P-256- en ML-KEM-768-materiaal, met AES-256-GCM voor inhoud. Ze beschrijft besloten LGS1-groepen als afzenderketens die via paarsgewijze LVR1-sessies worden verspreid. Dat zijn verschillende lagen: een gewoon groepsbericht is niet noodzakelijk een nieuwe ML-KEM-uitwisseling voor elke ontvanger.
Lees die documentatie als de beschrijving van de ontwikkelaar. Het noemen van gestandaardiseerde bouwstenen toont niet aan dat Livara’s eigen samenstelling onafhankelijk is geaudit of dat elke geïnstalleerde build haar correct implementeert. Het Proof Lab begrenst zijn browserdemonstratie uitdrukkelijk: die voert niet de volledige LVR1/LGS1-ratchets uit en vormt geen protocolaudit.
Wat postkwantumbescherming niet dekt
| Vraag | Waarom ML-KEM alleen die niet beantwoordt |
|---|---|
| Kan een ontvanger mijn bericht kopiëren? | De ontvanger krijgt leesbare inhoud. |
| Is mijn apparaat vrij van spyware? | Integriteit van het eindpunt is een afzonderlijke vertrouwensaanname. |
| Zijn back-ups beschermd? | Back-upsleutels en herstelregels vereisen een eigen ontwerp. |
| Zijn wijzigingen in groepslidmaatschap veilig? | Authenticatie-, lidmaatschaps- en sleutelvernieuwingsregels zijn van belang. |
| Bewaart de dienst metadata? | Inhoudsversleuteling verbergt niet automatisch routering of tijdstippen. |
| Wordt een oproep hetzelfde beschermd als een tekstchat? | Oproepsignalering en media kunnen andere protocollen gebruiken. |
Livara’s dreigingsmodel onderscheidt ook privégesprekken van openbare kanalen en erkent blootstelling op apparaatniveau. Trek een claim over directe chats niet door naar elk onderdeel van het product.
Een koperschecklist voor ‘FIPS 203-berichten’
Vraag om de exacte parameterset en protocolversie; een beschrijving van de authenticatie van gesprekspartners en de sleutelcombinatie; ondersteunde clientversies; gedrag bij incompatibele clients; en tests of beoordelingsbevindingen die bij de geleverde implementatie horen. Claimt een leverancier FIPS-validatie, vraag dan om de bijbehorende validatieregistratie en reikwijdte. Een algoritme gebruiken dat in een FIPS-publicatie wordt beschreven, bewijst op zichzelf geen product- of modulevalidatie.
Leid accuduur, doorvoersnelheid of reactiesnelheid van de app niet af uit de parameternaam. Daarvoor zijn metingen met een gedocumenteerd apparaat, build en werkbelasting nodig.
De nuttige verandering voor berichtenverkeer is een nieuw hulpmiddel voor langdurige vertrouwelijkheid. De waarde hangt af van integratie, implementatie en operationele grenzen, niet van het vervangen van het ene marketingetiket door het andere.
