Förnycklar låter mottagaren vara offline under etableringen. De undanröjer inte behovet av en leveransväg eller noggrann livscykelhantering av privata nycklar.
En mottagare som är offline kan ta emot ett krypterat meddelande senare eftersom enheten har publicerat offentligt nyckelmaterial i förväg. Avsändaren behöver fortfarande en nåbar leveranstjänst; ”asynkron kryptering” innebär inte att meddelanden tar sig genom ett nätavbrott eller omedelbart dyker upp på en frånkopplad telefon.
Postkvantkonstruktioner utvidgar denna idé med en mekanism för nyckelinkapsling. De viktiga frågorna är hur den ursprungliga hemligheten etableras, hur gamla privata nycklar tas ur bruk och hur senare meddelanden förnyar säkerheten.
Förnycklar löser ett tidsproblem
Tänk dig att Maya är offline när Sam startar ett nytt samtal. Mayas enhet har tidigare laddat upp offentliga förnycklar. Sam kan hämta materialet, utföra avsändarens del av nyckelöverenskommelsen och skicka ett krypterat första meddelande. Maya behandlar det när hon återansluter, med privata nycklar som finns kvar på hennes enhet.
Servern tillhandahåller alltså offentlig information och köar krypterade data; den behöver inte ha den resulterande meddelandehemligheten. Signals X3DH-specifikation är en primär beskrivning av denna asynkrona konstruktion. En signerad förnyckel och en engångsförnyckel har olika livslängder och roller; ”förnyckel” betyder inte ett hemligt lösenord som laddats upp till servern.
För ett redan etablerat samtal kan appen använda befintligt sessionstillstånd i stället för att upprepa den inledande etableringen för varje meddelande. Att starta en session och föra dess meddelandenycklar framåt är separata operationer.
Vad en postkvant-KEM tillför
En nyckelinkapslingsmekanism har tre grundläggande operationer: generera nycklar, kapsla in med en offentlig nyckel och kapsla upp med motsvarande privata nyckel. Inkapsling ger både en delad hemlighet och en chiffertext. Chiffertexten kan levereras senare; själva hemligheten skickas inte i klartext.
NIST FIPS 203 standardiserar ML-KEM. För ML-KEM-768 är den offentliga inkapslingsnyckeln 1 184 byte, chiffertexten 1 088 byte och den delade hemligheten 32 byte. Detta är storlekar på algoritmnivå, inte storleken på ett helt meddelandepaket. Signaturer, klassiska nycklar, identifierare och transportinramning ger extra overhead; en cachad offentlig nyckel behöver inte följa med varje meddelande.
I en hybridkonstruktion kombinerar protokollet klassiskt och postkvanthemligt material enligt ett definierat nyckelhärledningsschema. Att bara sätta ihop algoritmnamn fastställer inte att sammansättningen är säker. Identitetsbindning, validering, domänseparation och felhantering måste specificeras och granskas.
Ett exempel: PQXDH, inte en universell ritning
Signals PQXDH-specifikation beskriver signerade postkvantförnycklar för engångsbruk och en signerad reservnyckel som sista utväg. Avsändaren verifierar de tillhandahållna signaturerna, genomför nyckelöverenskommelsen och bifogar KEM-chiffertexten och nyckelidentifierarna till det första krypterade meddelandet. Mottagaren härleder senare samma hemlighet och behandlar meddelandet.
Reservnyckeln möjliggör etablering när engångsnycklar för KEM saknas, men analysen av nyckelkompromettering är inte identisk. Radering och rotation av privata nycklar påverkar skyddet för tidigare sessioner. Specifikationen skiljer också mellan postkvant framåtsekretess och autentisering mot en aktiv kvantangripare. Dessa detaljer får inte ersättas med ”reservläget har ingen säkerhetskostnad”.
PQXDH är en specificerad konstruktion. Dess exakta kurvor, signaturer och parameterval bör inte kopieras in i en beskrivning av en annan produkt om inte produkten dokumenterar dem.
En ratchet är inte samma sak som en pool av förnycklar
Förnycklar stöder sessionsetablering. Ett ratchetprotokoll ändrar hemligheter under samtalet. Double Ratchet-specifikationen förklarar meddelandenycklarnas utveckling och nyare postkvantkonstruktioner för ratcheting, inklusive lösningar som inte överför ett fullständigt postkvantutbyte med varje applikationsmeddelande.
Framåtsekretess gäller tidigare meddelanden när nycklar komprometteras senare. Säkerhet efter kompromettering gäller återhämtning för framtida kommunikation efter att angriparen har förlorat åtkomsten och nytt hemligt material har införlivats. Ingetdera innebär att skadlig kod kan finnas kvar på en telefon obegränsat medan kryptografi på något sätt döljer telefonens klartext för den.
Att radera en offentlig förnyckel från servern förhindrar vanlig återanvändning; det är inte samma sak som att radera motsvarande privata nyckel från en ändpunkt. En användbar granskning kontrollerar både livscykelregler och hanteringen av försenade meddelanden.
Vad Livara dokumenterar – och vad som fortfarande kräver belägg
Livaras säkerhetssida beskriver hybridetablering av sessioner med engångsnycklar när de finns tillgängliga, vanliga steg i meddelandekedjan och periodiska ML-KEM-epoker. Det skiljer sig från det gamla påståendet att varje meddelande utför ett helt nytt fullständigt ML-KEM-utbyte. Detta är uppgifter i produktdokumentationen, inte en oberoende verifiering av implementationen.
Dra inte slutsatser om en viss reservpolicy när nycklar tar slut, ett påfyllningsintervall eller en siffra för nätverkslatens från dessa uppgifter. Sådana frågor kräver versionsspecifik protokolldokumentation eller uppmätta resultat. Proof Lab är inte heller ett fullständigt test av asynkron etablering, uttömda nycklar eller återhämtning av försenade meddelanden.
Så bedömer du påståenden om offlinemeddelanden
Be leverantören eller granskaren om belägg som omfattar följande fall:
| Testfall | Vad du bör observera |
|---|---|
| Första meddelandet till en frånkopplad kontakt | Vilket offentligt nyckelmaterial som användes och när mottagaren faktiskt tar emot meddelandet |
| Uttömda engångsförnycklar | Om etableringen avbryts eller följer en dokumenterad reservlösning och dess angivna säkerhetsavvägning |
| Mottagaren installerar om eller byter identitet | Om gamla köade meddelanden fortfarande kan dekrypteras och om nyckelbyten syns |
| Försenade meddelanden eller meddelanden i fel ordning | Lagringsgränser, hantering av överhoppade nycklar och begripliga fel |
| Återkomst efter lång frånvaro | Säker nyckelförnyelse, begränsad bearbetning och korrekt leveransstatus |
| Prestandajämförelse | Enhet, appversion, nätverk, nyttolaststorlek och separata mätningar av kallstartsetablering respektive etablerad session |
Använd testkonton och meddelanden utan känsliga uppgifter. Ett lyckat leveranstest demonstrerar det scenariot, inte varje kryptografisk egenskap. Omvänt kan misslyckad leverans bero på nätverk eller livscykel snarare än på att chiffret har knäckts.
Vanliga frågor
Kan en mottagare vara offline när jag skickar?
Ja, om appen har det offentliga material som krävs och infrastruktur för leverans och lagring. Mottagaren kan inte läsa det köade meddelandet förrän enheten kan hämta och behandla det.
Gör större KEM-nycklar alltid chattar märkbart långsammare?
Enbart nyckelstorleken ger inget universellt påstående om tidsåtgång. Etableringsfrekvens, batchning, cachelagring, implementation och nätverksförhållanden spelar roll. Publicera ett prestandatest i stället för att lova noll overhead.
Bevisar en signerad förnyckel vem personen bakom kontot är?
Den autentiserar material i förhållande till en signeringsidentitet. Hur den identiteten binds till personen du vill kontakta är en separat fråga om tillit och verifiering.
Fungerar postkvantkryptering helt utan anslutning?
Vissa lokala beräkningar kan köras offline. Leverans av meddelanden kräver fortfarande en kommunikationsväg; kryptografi tillhandahåller inte en sådan.
