Prekeys lossen een timingprobleem op bij het opzetten van een sessie. Ze vervangen geen communicatiepad of zorgvuldig gedocumenteerd sleutelbeheer.
Een offline ontvanger kan een versleuteld bericht later ontvangen doordat diens apparaat vooraf openbaar sleutelmateriaal heeft gepubliceerd. De afzender heeft nog steeds een bereikbare bezorgdienst nodig; ‘asynchrone versleuteling’ betekent niet dat berichten een netwerkstoring overbruggen of meteen op een niet-verbonden telefoon verschijnen.
Postkwantumontwerpen breiden dit idee uit met een sleutelinkapselingsmechanisme. De belangrijke vragen zijn hoe het eerste geheim tot stand komt, hoe oude privésleutels buiten gebruik worden gesteld en hoe latere berichten de beveiliging vernieuwen.
Prekeys lossen een timingprobleem op
Stel dat Maya offline is wanneer Sam een nieuw gesprek begint. Maya’s apparaat heeft eerder openbare prekeys geüpload. Sam kan dat materiaal ophalen, het afzendersdeel van de sleutelovereenkomst uitvoeren en een versleuteld eerste bericht verzenden. Maya verwerkt het wanneer ze weer verbinding heeft, met privésleutels die op haar apparaat blijven.
De server levert dus openbare informatie en zet versleutelde gegevens in een wachtrij; hij hoeft het resulterende berichtgeheim niet te bezitten. De X3DH-specificatie van Signal is een primaire beschrijving van dit asynchrone ontwerp. Een ondertekende prekey en een eenmalige prekey hebben verschillende levensduren en rollen; ‘prekey’ betekent niet dat een geheim wachtwoord naar de server wordt geüpload.
Voor een al bestaand gesprek kan de app de bestaande sessiestatus gebruiken in plaats van de eerste inrichting voor elk bericht te herhalen. Een sessie starten en haar berichtsleutels verder ontwikkelen zijn afzonderlijke handelingen.
Wat een postkwantum-KEM toevoegt
Een sleutelinkapselingsmechanisme heeft drie basisbewerkingen: sleutels genereren, inkapselen met een openbare sleutel en ontkapselen met de bijbehorende privésleutel. Inkapseling levert zowel een gedeeld geheim als een cijfertekst op. De cijfertekst kan later worden bezorgd; het geheim zelf wordt niet onversleuteld verstuurd.
NIST FIPS 203 standaardiseert ML-KEM. Voor ML-KEM-768 is de openbare inkapselingssleutel 1.184 bytes, de cijfertekst 1.088 bytes en het gedeelde geheim 32 bytes. Dit zijn groottes op algoritmeniveau, niet de grootte van een volledig berichtenpakket. Handtekeningen, klassieke sleutels, identificatoren en transportomkadering voegen overhead toe; een gecachte openbare sleutel hoeft niet met elk bericht mee te komen.
In een hybride constructie combineert een protocol klassiek en postkwantumgeheim materiaal volgens een vastgelegd sleutelafleidingsschema. Alleen algoritmenamen achter elkaar zetten toont niet aan dat de combinatie veilig is. Identiteitsbinding, validatie, domeinscheiding en foutafhandeling moeten worden gespecificeerd en beoordeeld.
Een voorbeeld: PQXDH, geen universele blauwdruk
De PQXDH-specificatie van Signal beschrijft ondertekende eenmalige postkwantumprekeys en een ondertekende reservesleutel. De afzender controleert de aangeleverde handtekeningen, voert de sleutelovereenkomst uit en voegt de KEM-cijfertekst en sleutelidentificatoren toe aan het eerste versleutelde bericht. De ontvanger leidt later hetzelfde geheim af en verwerkt het bericht.
De reservesleutel maakt het opzetten van een sessie mogelijk wanneer eenmalige KEM-sleutels niet beschikbaar zijn, maar de analyse van compromitteringsrisico’s is niet identiek. Het verwijderen en roteren van privésleutels beïnvloedt de bescherming van eerdere sessies. De specificatie maakt ook onderscheid tussen postkwantum-forward secrecy en authenticatie tegenover een actieve kwantumaanvaller. Deze details mogen niet worden vervangen door ‘de uitwijkmogelijkheid kost geen beveiliging’.
PQXDH is één gespecificeerde constructie. De exacte krommen, handtekeningen en parameterkeuzes mogen niet worden overgenomen in een beschrijving van een ander product, tenzij dat product ze documenteert.
Een ratchet is niet hetzelfde als een prekeyvoorraad
Prekeys ondersteunen het opzetten van sessies. Een ratchetingprotocol verandert geheimen tijdens het gesprek. De Double Ratchet-specificatie beschrijft de ontwikkeling van berichtsleutels en nieuwere postkwantumratchetconstructies, waaronder ontwerpen die niet met elk toepassingsbericht een volledige postkwantumuitwisseling versturen.
Forward secrecy gaat over eerdere berichten nadat sleutels later worden gecompromitteerd. Post-compromise security gaat over het herstel van de beveiliging van toekomstige communicatie nadat de aanvaller de toegang verliest en nieuw geheim materiaal wordt ingebracht. Geen van beide betekent dat malware onbeperkt op een telefoon kan blijven terwijl de cryptografie de leesbare tekst van die telefoon op de een of andere manier voor die malware verbergt.
Een openbare prekey van de server verwijderen voorkomt normaal hergebruik; dat is niet hetzelfde als de bijbehorende privésleutel van een eindpunt verwijderen. Een nuttige audit controleert zowel de levenscyclusregels als het gedrag bij vertraagde berichten.
Wat Livara documenteert en waarvoor nog bewijs nodig is
De beveiligingspagina van Livara beschrijft hybride sessieopzet met eenmalige sleutels wanneer die beschikbaar zijn, gewone stappen in de berichtenketen en periodieke ML-KEM-epochs. Dat verschilt van de oude claim dat elk bericht een volledig nieuwe ML-KEM-uitwisseling uitvoert. Dit zijn uitspraken in de productdocumentatie, geen onafhankelijke verificatie van de implementatie.
Leid hieruit geen specifiek uitwijkbeleid bij uitgeputte sleutels, aanvulinterval of netwerklatentiecijfer af. Daarvoor is releasegebonden protocoldocumentatie of gemeten resultaat nodig. Ook het Proof Lab is geen volledige test van asynchrone sessieopzet, sleuteluitputting of herstel van vertraagde berichten.
Claims over offline berichten beoordelen
Vraag de leverancier of beoordelaar om bewijs voor deze gevallen:
| Testgeval | Wat je moet waarnemen |
|---|---|
| Eerste bericht aan een niet-verbonden contact | Welk openbaar sleutelmateriaal is gebruikt en wanneer de ontvanger het bericht daadwerkelijk ontvangt |
| Uitgeputte eenmalige prekeys | Of de sessieopzet stopt of een gedocumenteerde uitwijkroute volgt, en welke beveiligingsafweging daarbij wordt vermeld |
| Ontvanger installeert opnieuw of verandert van identiteit | Of oude wachtende berichten ontsleutelbaar blijven en of sleutelwijzigingen zichtbaar zijn |
| Vertraagde of anders gerangschikte berichten | Bewaargrenzen, afhandeling van overgeslagen sleutels en begrijpelijke foutmeldingen |
| Terugkeer na een lange afwezigheid | Veilige sleutelvernieuwing, begrensde verwerking en een juiste bezorgstatus |
| Prestatievergelijking | Apparaat, appversie, netwerk, payloadgrootte en afzonderlijke metingen van eerste sessieopzet en bestaande sessies |
Gebruik testaccounts en berichten zonder gevoelige informatie. Een geslaagde bezorgtest toont dat scenario aan, niet elke cryptografische eigenschap. Omgekeerd kan een mislukte bezorging het gevolg zijn van een netwerk- of levenscyclusprobleem in plaats van een doorbroken versleutelingsalgoritme.
Veelgestelde vragen
Kan een ontvanger offline zijn terwijl ik verstuur?
Ja, als de toepassing over het benodigde openbare materiaal en de bezorg- en opslaginfrastructuur beschikt. De ontvanger kan het wachtende bericht pas lezen wanneer diens apparaat het kan ophalen en verwerken.
Maken grotere KEM-sleutels chats altijd merkbaar langzamer?
Uit alleen de sleutelgrootte volgt geen universele uitspraak over tijd. De frequentie van sessieopzet, bundeling, caching, implementatie en netwerkomstandigheden zijn van belang. Publiceer een benchmark in plaats van nul overhead te beloven.
Bewijst een ondertekende prekey wie de persoon achter het account is?
Ze authenticeert materiaal ten opzichte van een ondertekeningsidentiteit. Hoe die identiteit is verbonden met de persoon die je wilt bereiken, is een aparte kwestie van vertrouwen en verificatie.
Werkt postkwantumversleuteling zonder enige verbinding?
Sommige lokale berekeningen kunnen offline worden uitgevoerd. Het bezorgen van berichten vereist nog steeds een communicatiepad; cryptografie levert dat niet.
