En standardiserad komponent är en utgångspunkt för granskning, inte ett certifikat för hela meddelandeappen.
ML-KEM-768 hjälper två parter att etablera en delad hemlighet som sedan kan användas för att skydda meddelanden. Det är en komponent i ett meddelandesystem, inte ett fullständigt chattprotokoll, ett meddelandechiffer eller ett intyg på att en app är säker.
NIST publicerade FIPS 203 den 13 augusti 2024, vilket standardiserade ML-KEM och dess parameteruppsättningar 512, 768 och 1024. Säkerheten bygger på gitterbaserade problem som antas motstå kvantattacker. ”Antas motstå” är ett säkerhetsantagande som stöds av analys, inte ett löfte om att ingen framtida svaghet kan finnas. NIST FIPS 203.
Var en KEM passar in i en krypterad chatt
Ett användbart sätt att läsa ett krypteringspåstående är att följa nyckelmaterialet:
- Autentisera den avsedda motparten. Ett nyckelutbyte med en bedragare är fortfarande ett nyckelutbyte med fel person.
- Etablera delat hemligt material. En KEM bidrar med en hemlighet genom inkapsling och uppkapsling.
- Härled nycklar för deras särskilda ändamål. En nyckelhärledningsfunktion separerar materialet som används av protokollets olika delar.
- Kryptera och autentisera meddelanden. Ett schema för autentiserad kryptering skyddar innehåll och upptäcker obehöriga ändringar.
- Hantera sessionen över tid. Nyckelrotation, radering, enhetsbyten och återställning avgör vad en senare kompromettering kan exponera.
Dessa steg förklarar varför en standard för steg två inte kan validera hela appen. NIST:s vanliga frågor om postkvantkryptografi ger sammanhang för införandet av de nya standarderna.
Varför kombinera ML-KEM med klassisk nyckelöverenskommelse?
En hybridkonstruktion använder en postkvantkomponent tillsammans med en klassisk komponent, till exempel Diffie–Hellman med elliptiska kurvor. Den avsedda fördelen är att undvika att under en övergång enbart förlita sig på någon av uppsättningarna av antaganden.
Säkerhetspåståendet gäller den fullständiga kombineringsmekanismen och protokollet, inte bara en lista med två algoritmer. Granskare behöver veta vilka indata som autentiseras, hur de kodas och kombineras, vilket sammanhang som binds till härledningen och vad som händer när en komponent fallerar. Att sammanfoga hemligheter utan en specificerad konstruktion är inget säkerhetsargument.
För användaren är den praktiska frågan inte ”Står det kvantsäker på inställningssidan?”. Den är ”Vilka samtal och versioner använder faktiskt konstruktionen, och vilka belägg stöder det påståendet?”.
Vad Livara dokumenterar
Livaras säkerhetsdokumentation beskriver LVR1-sessioner för direktchattar som använder klassiskt P-256-material och ML-KEM-768-material, med AES-256-GCM för innehållet. Privata LGS1-grupper beskrivs som avsändarkedjor som distribueras genom parvisa LVR1-sessioner. Det är olika lager: ett vanligt gruppmeddelande är inte nödvändigtvis ett nytt ML-KEM-utbyte för varje mottagare.
Läs dokumentationen som utvecklarens beskrivning. Att namnge standardiserade primitiver visar inte att Livaras egna sammansättning har granskats oberoende eller att varje installerat bygge implementerar den korrekt. Proof Lab begränsar uttryckligen sin webbläsardemonstration: den kör inte de fullständiga LVR1/LGS1-ratchetmekanismerna och utgör inte en protokollgranskning.
Vad postkvantskydd inte omfattar
| Fråga | Varför ML-KEM ensamt inte besvarar den |
|---|---|
| Kan en mottagare kopiera mitt meddelande? | Mottagaren får läsbart innehåll. |
| Är min enhet fri från spionprogram? | Ändpunktens integritet är ett separat tillitsantagande. |
| Är säkerhetskopior skyddade? | Säkerhetskopieringsnycklar och återställningsregler kräver en egen konstruktion. |
| Är medlemsändringar i grupper säkra? | Regler för autentisering, medlemskap och nyckelbyte är viktiga. |
| Behåller tjänsten metadata? | Innehållskryptering döljer inte automatiskt routning eller tidpunkter. |
| Skyddas ett samtal på samma sätt som en textchatt? | Samtalssignalering och media kan använda olika protokoll. |
Livaras hotmodell skiljer också privata samtal från offentliga kanaler och erkänner exponering på enhetsnivå. Utvidga inte ett påstående om direktchattar till alla produktens ytor.
En köpares checklista för ”FIPS 203-meddelanden”
Be om exakt parameteruppsättning och protokollversion, en beskrivning av motpartsautentisering och nyckelkombinering, klientversioner som stöds, beteendet med inkompatibla klienter samt tester eller granskningsfynd knutna till den levererade implementationen. Om leverantören hävdar FIPS-validering, be om relevant valideringspost och dess omfattning. Att använda en algoritm som beskrivs i en FIPS-publikation är inte i sig belägg för produkt- eller modulvalidering.
Dra inte slutsatser om batteritid, genomströmning eller appens svarstider från parameternamnet. Det kräver mätningar med dokumenterad enhet, bygge och arbetsbelastning.
Den användbara förändringen för meddelanden är ett nytt verktyg för långsiktig konfidentialitet. Dess värde beror på integration, implementation och operativa gränser, inte på att ersätta en marknadsföringsetikett med en annan.
