Prekeys lösen ein Zeitproblem bei der Sitzungseinrichtung. Sie ersetzen weder einen Übertragungsweg noch ein sorgfältig dokumentiertes Schlüsselmanagement.
Ein Offline-Empfänger kann eine verschlüsselte Nachricht später erhalten, weil sein Gerät zuvor öffentliches Schlüsselmaterial bereitgestellt hat. Der Absender benötigt weiterhin einen erreichbaren Zustelldienst; „asynchrone Verschlüsselung“ bedeutet nicht, dass Nachrichten einen Netzausfall überwinden oder sofort auf einem nicht verbundenen Telefon erscheinen.
Post-Quanten-Verfahren erweitern diese Idee um einen Schlüsselverkapselungsmechanismus. Entscheidend ist, wie das anfängliche Geheimnis hergestellt wird, wie alte private Schlüssel außer Betrieb genommen werden und wie spätere Nachrichten die Sicherheit erneuern.
Prekeys lösen ein Zeitproblem
Stellen Sie sich vor, Maya ist offline, als Sam eine neue Unterhaltung beginnt. Mayas Gerät hat zuvor öffentliche Prekeys hochgeladen. Sam kann dieses Material abrufen, die Absenderseite der Schlüsselvereinbarung ausführen und eine verschlüsselte erste Nachricht senden. Maya verarbeitet sie nach dem Wiederverbinden mit privaten Schlüsseln, die auf ihrem Gerät bleiben.
Der Server liefert somit öffentliche Informationen und hält verschlüsselte Daten zur Zustellung bereit; er muss das daraus entstehende Nachrichtengeheimnis nicht besitzen. Die X3DH-Spezifikation von Signal ist eine Primärbeschreibung dieses asynchronen Ansatzes. Ein signierter Prekey und ein einmaliger Prekey haben unterschiedliche Lebensdauern und Aufgaben; „Prekey“ bedeutet nicht, dass ein geheimes Passwort auf den Server hochgeladen wird.
Bei einer bereits eingerichteten Unterhaltung kann die App den vorhandenen Sitzungszustand nutzen, statt die Ersteinrichtung für jede Nachricht zu wiederholen. Eine Sitzung zu beginnen und ihre Nachrichtenschlüssel weiterzuentwickeln sind getrennte Vorgänge.
Was ein Post-Quanten-KEM ergänzt
Ein Schlüsselverkapselungsmechanismus hat drei grundlegende Operationen: Schlüssel erzeugen, mit einem öffentlichen Schlüssel verkapseln und mit dem zugehörigen privaten Schlüssel entkapseln. Die Verkapselung erzeugt sowohl ein gemeinsames Geheimnis als auch einen Chiffretext. Der Chiffretext kann später zugestellt werden; das Geheimnis selbst wird nicht im Klartext gesendet.
NIST FIPS 203 standardisiert ML-KEM. Bei ML-KEM-768 umfasst der öffentliche Verkapselungsschlüssel 1.184 Byte, der Chiffretext 1.088 Byte und das gemeinsame Geheimnis 32 Byte. Das sind Größen auf Algorithmusebene, nicht die Größe eines vollständigen Nachrichtenpakets. Signaturen, klassische Schlüssel, Kennungen und die Transport-Einrahmung verursachen zusätzlichen Aufwand; ein zwischengespeicherter öffentlicher Schlüssel muss nicht jeder Nachricht beiliegen.
In einer hybriden Konstruktion kombiniert ein Protokoll klassisches und Post-Quanten-Geheimnismaterial nach einem definierten Schlüsselableitungsplan. Das bloße Aneinanderreihen von Algorithmusnamen belegt nicht, dass die Kombination sicher ist. Identitätsbindung, Validierung, Domänentrennung und Fehlerbehandlung müssen spezifiziert und geprüft werden.
Ein Beispiel: PQXDH, kein universeller Bauplan
Die PQXDH-Spezifikation von Signal beschreibt signierte einmalige Post-Quanten-Prekeys sowie einen signierten Reserveschlüssel. Der Absender prüft die bereitgestellten Signaturen, führt die Schlüsselvereinbarung aus und fügt der ersten verschlüsselten Nachricht den KEM-Chiffretext und die Schlüsselkennungen bei. Der Empfänger leitet später dasselbe Geheimnis ab und verarbeitet die Nachricht.
Der Reserveschlüssel ermöglicht die Einrichtung, wenn keine einmaligen KEM-Schlüssel verfügbar sind; die Analyse der Folgen einer Kompromittierung ist jedoch nicht identisch. Das Löschen und Rotieren privater Schlüssel beeinflusst den Schutz früherer Sitzungen. Die Spezifikation unterscheidet außerdem Post-Quanten-Forward-Secrecy von der Authentifizierung gegenüber einem aktiven Quantenangreifer. Diese Einzelheiten dürfen nicht durch „die Ausweichlösung kostet keine Sicherheit“ ersetzt werden.
PQXDH ist eine konkret spezifizierte Konstruktion. Ihre genauen Kurven, Signaturen und Parameter sollten nicht in die Beschreibung eines anderen Produkts übernommen werden, sofern dieses Produkt sie nicht dokumentiert.
Ein Ratchet ist nicht dasselbe wie ein Prekey-Vorrat
Prekeys unterstützen die Sitzungseinrichtung. Ein Ratcheting-Protokoll verändert Geheimnisse während der Unterhaltung. Die Double-Ratchet-Spezifikation erläutert die Entwicklung von Nachrichtenschlüsseln und neuere Post-Quanten-Ratcheting-Konstruktionen, einschließlich Verfahren, die nicht mit jeder Anwendungsnachricht einen vollständigen Post-Quanten-Austausch übertragen.
Forward Secrecy betrifft frühere Nachrichten nach einer späteren Schlüsselkompromittierung. Post-Compromise Security betrifft die Wiederherstellung der Sicherheit zukünftiger Kommunikation, nachdem der Angreifer den Zugriff verliert und frisches Geheimnismaterial eingebracht wird. Beides bedeutet nicht, dass Schadsoftware unbegrenzt auf einem Telefon bleiben kann, während die Kryptografie dessen Klartext irgendwie vor ihr verbirgt.
Das Löschen eines öffentlichen Prekeys vom Server verhindert seine gewöhnliche Wiederverwendung; es ist nicht gleichbedeutend mit dem Löschen des entsprechenden privaten Schlüssels auf einem Endpunkt. Ein sinnvolles Audit prüft sowohl die Lebenszyklusregeln als auch das Verhalten bei verzögerten Nachrichten.
Was Livara dokumentiert – und wofür noch Nachweise nötig sind
Livara beschreibt auf seiner Sicherheitsseite eine hybride Sitzungseinrichtung mit einmaligen Schlüsseln, sofern verfügbar, gewöhnliche Fortschritte der Nachrichtenkette und periodische ML-KEM-Epochen. Das unterscheidet sich von der früheren Aussage, jede Nachricht führe einen vollständigen neuen ML-KEM-Austausch aus. Es handelt sich um Aussagen der Produktdokumentation, nicht um eine unabhängige Prüfung der Implementierung.
Leiten Sie daraus keine bestimmte Ausweichregel bei erschöpftem Schlüsselvorrat, kein Auffüllintervall und keine Netzwerklatenz ab. Diese Fragen erfordern versionsspezifische Protokolldokumentation oder Messergebnisse. Auch das Proof Lab ist kein vollständiger Test für asynchrone Einrichtung, Schlüsselerschöpfung oder die Wiederherstellung bei verzögerten Nachrichten.
So bewerten Sie Aussagen zu Offline-Nachrichten
Bitten Sie Anbieter oder Prüfer um Nachweise zu diesen Fällen:
| Testfall | Was zu beobachten ist |
|---|---|
| Erste Nachricht an einen nicht verbundenen Kontakt | Welches öffentliche Schlüsselmaterial verwendet wurde und wann der Empfänger die Nachricht tatsächlich erhält |
| Erschöpfte einmalige Prekeys | Ob die Einrichtung stoppt oder einer dokumentierten Ausweichlösung folgt und welcher Sicherheitskompromiss dafür angegeben wird |
| Empfänger installiert neu oder wechselt die Identität | Ob alte wartende Nachrichten weiterhin entschlüsselbar sind und ob Schlüsseländerungen sichtbar werden |
| Verzögerte oder umgeordnete Nachrichten | Aufbewahrungsgrenzen, Umgang mit übersprungenen Schlüsseln und verständliche Fehler |
| Rückkehr nach langer Abwesenheit | Sichere Schlüsselerneuerung, begrenzter Verarbeitungsaufwand und korrekter Zustellstatus |
| Leistungsvergleich | Gerät, App-Version, Netzwerk, Nutzlastgröße und getrennte Messungen für Ersteinrichtung und bestehende Sitzungen |
Verwenden Sie Testkonten und Nachrichten ohne sensible Inhalte. Ein erfolgreicher Zustelltest belegt dieses Szenario, nicht jede kryptografische Eigenschaft. Umgekehrt kann eine fehlgeschlagene Zustellung auf ein Netzwerk- oder Lebenszyklusproblem zurückgehen, statt auf einen Bruch des Verschlüsselungsverfahrens.
Häufig gestellte Fragen
Kann ein Empfänger offline sein, während ich sende?
Ja, wenn die Anwendung über das benötigte öffentliche Material und die Zustell- und Speicherinfrastruktur verfügt. Der Empfänger kann die wartende Nachricht erst lesen, wenn sein Gerät sie abrufen und verarbeiten kann.
Machen größere KEM-Schlüssel Chats immer spürbar langsamer?
Aus der Schlüsselgröße allein folgt keine allgemeingültige Zeitaussage. Einrichtungshäufigkeit, Bündelung, Zwischenspeicherung, Implementierung und Netzwerkbedingungen sind wichtig. Veröffentlichen Sie einen Benchmark, statt keinerlei Mehraufwand zu versprechen.
Beweist ein signierter Prekey die Person hinter dem Konto?
Er authentifiziert Material in Bezug auf eine Signaturidentität. Wie diese Identität an die Person gebunden ist, die Sie kontaktieren möchten, ist eine gesonderte Vertrauens- und Verifikationsfrage.
Funktioniert Post-Quanten-Verschlüsselung ganz ohne Verbindung?
Einige lokale Berechnungen können offline stattfinden. Die Zustellung von Nachrichten benötigt weiterhin einen Kommunikationsweg; die Kryptografie stellt keinen bereit.
