Hybride Postquanten-Ratchets: ML-KEM-768 und P-256

Ein hybrider Postquanten-Ratchet aktualisiert Messaging-Schlüssel mit klassischem und Postquanten-Material. Ziel ist, unter sorgfältig definierten Annahmen den Schutz zu erhalten, falls eine Komponente verwundbar wird, und zugleich die Schäden bestimmter Schlüsselkompromittierungen im Zeitverlauf zu begrenzen.

Livara dokumentiert diesen Ansatz für LVR1 mit P-256 und ML-KEM-768. Um das Design zu verstehen, muss man die anfängliche Schlüsselvereinbarung, gewöhnliche Aktualisierungen der Nachrichtenkette und periodische Postquanten-Auffrischungen unterscheiden. Es handelt sich nicht um denselben Vorgang, der bei jeder Nachricht stattfindet.

Vom gemeinsamen Geheimnis zu wechselnden Nachrichtenschlüsseln

Ein Schlüsselvereinbarungsmechanismus liefert den Beteiligten geheimes Material für einen Schlüsselableitungsplan. Ein Ratcheting-Protokoll entwickelt anschließend den Zustand weiter und leitet Nachrichtenschlüssel ab, statt während der gesamten Unterhaltung denselben Inhaltsschlüssel beizubehalten.

NIST FIPS 203 spezifiziert ML-KEM einschließlich des Parametersatzes ML-KEM-768. Es erzeugt ein gemeinsames Geheimnis; ein authentifiziertes Verschlüsselungsverfahren wie AES-GCM verschlüsselt die Nachrichtennutzlast. Die Authentifizierung und die Art, wie Komponenten kombiniert werden, gehören zum übergeordneten Protokoll.

Livaras Sicherheitsübersicht beschreibt eine hybride Schlüsselvereinbarung, unabhängige klassische und Postquanten-Wurzeln, mit den Nachrichten fortschreitende Einweg-Sende- und Empfangsketten sowie periodische ML-KEM-Epochenaktualisierungen. Demnach wird ein Nachrichtenschlüssel vor dem Schutz von Inhalt und Header mit der aktuellen Postquanten-Wurzel kombiniert.

Diese Beschreibung darf nicht zu „Für jede Nachricht erfolgen ein neuer P-256-Austausch und eine neue ML-KEM-Kapselung“ umgeschrieben werden. Ein Kettenfortschritt kann ein vergleichsweise günstiger Schlüsselableitungsschritt sein.

Was eine Epoche verändert

Eine Epoche ist ein Zeitraum des Protokollzustands, der einer bestimmten Auffrischung zugeordnet ist. Größere Schlüsselvereinbarungsnachrichten über Epochen zu verteilen kann wiederholten Kommunikationsaufwand reduzieren, macht aber auch die Auffrischungsregeln sicherheitsrelevant.

Prüfende sollten fragen:

• Was löst eine neue Epoche aus: ein Zähler, Zeit, eine Aktion der Gegenstelle oder eine andere Bedingung?
• Wie werden Epochenkennungen und Schlüsselmaterial authentifiziert?
• Was geschieht mit verspäteten, doppelten oder in falscher Reihenfolge eintreffenden Nachrichten?
• Wie behandelt ein Client ein fehlendes Update oder eine ältere inkompatible Gegenstelle?
• Welche alten Geheimnisse bleiben für verzögerte Zustellung erhalten, und wann werden sie verworfen?

Eine Implementierung benötigt präzise Antworten. Das Wort „periodisch“ allein ist keine vollständige Wiederherstellungs- oder Interoperabilitätsspezifikation.

Größen von Primitiven beziffern, ohne einen Benchmark zu erfinden

FIPS 203 nennt für ML-KEM-768 eine Kapselungsschlüsselgröße von 1.184 Byte und eine Chiffretextgröße von 1.088 Byte. Dies sind Kodierungen der Primitive, nicht die Gesamtgröße einer Livara-Nachricht oder eines Handshakes. Protokollheader, Signaturen, Rahmung und die Übertragungshäufigkeit jedes Werts bestimmen den tatsächlichen Datenverkehr.

Auch P-256-Schlüsselgrößen hängen von der Darstellung ab. Ein komprimierter Kurvenpunkt und ein unkomprimierter Punkt haben beispielsweise unterschiedliche kodierte Längen. Eine nicht näher bezeichnete „P-256-Schlüsselgröße“ mit einem ML-KEM-Chiffretext zu vergleichen ist keine vollständige Bandbreitenanalyse.

Um die Kosten eines Ratchets zu bewerten, messen Sie auf repräsentativen Geräten Byte pro Unterhaltung und Epoche, CPU-Zeit, Speicher, Funkmodul-Aktivierungen und Ende-zu-Ende-Latenz. Geben Sie Build- und Netzwerkbedingungen an. Ohne solche Messungen sind weder „vernachlässigbare Akkuauswirkungen“ noch eine universelle Ausführungszeit unter einer Millisekunde gerechtfertigt.

Forward Secrecy und Wiederherstellung nach einer Kompromittierung

Forward Secrecy soll frühere Nachrichten schützen, nachdem bestimmte spätere Geheimnisse offengelegt wurden, sofern die erforderlichen alten Geheimnisse gelöscht wurden. Post-Compromise Security betrifft die Wiedererlangung von Schutz, nachdem ein Angreifer den Endpunkt nicht mehr kontrolliert und frisches, ihm unbekanntes geheimes Material in das Protokoll eingeht.

Die Double-Ratchet-Spezifikation erläutert diese Unterschiede und die Grenzen der Wiederherstellung nach einem Einbruch. Fortgesetzter Malware-Zugriff, manipulierte Zufälligkeit oder ein aktiver Angreifer, der die relevanten Austauschvorgänge kontrolliert, können die erhoffte Wiederherstellung vereiteln. Eine weitere Nachricht zu senden beweist weder, dass eine gestohlene Sitzung widerrufen wurde, noch dass ein kompromittiertes Telefon sauber ist.

Eine hybride Konstruktion braucht außerdem eine solide Authentifizierung und Kombination. „Der Angreifer muss beide Algorithmen brechen“ ist eine beabsichtigte Eigenschaft unter den Annahmen der Konstruktion, keine bedingungslose Aussage, die Implementierungsfehler oder bösartige Endpunkte abdeckt.

Funktionsgrenzen sichtbar halten

In Livaras Dokumentation werden LGS1-Gruppensenderschlüssel über paarweise LVR1-Sitzungen verteilt. Das bedeutet nicht, dass eine Gruppensenderkette strukturell mit einem Double Ratchet für Direktchats identisch ist. Die aktuelle Sicherheitsseite schließt außerdem ältere inkompatible Gruppen von E2EE aus und verlangt, dass die Mitglieder bereit sind, bevor eine neue verschlüsselte Gruppe erstellt wird.

Anhänge haben eigene Inhaltsschlüssel, die innerhalb der geschützten Unterhaltung transportiert werden. Anrufe und optionale serverseitige Aufzeichnung erfordern eine separate Prüfung; leiten Sie Postquanten-Medienschutz nicht allein daraus ab, dass ein Signalisierungspfad eine hybride Sitzung nutzt. Öffentliche Kanäle und betriebliche Metadaten liegen außerhalb der Vertraulichkeit privater Inhalte.

Was würde das Vertrauen stärken?

Achten Sie auf eine versionierte Spezifikation, Interoperabilitäts- und Fehlerfalltests, unabhängige Prüfung und einen klaren Zusammenhang zwischen geprüftem Quellcode und ausgeliefertem Client. Standardalgorithmen sind nützliche Belege über Komponenten, keine Zertifizierung ihrer Kombination.

Livaras Proof Lab demonstriert ausgewählte klassische Primitive und schließt die vollständige LVR1/LGS1-Kombination ausdrücklich von diesem lokalen Prüfstand aus. Das Bedrohungsmodell bleibt notwendiger Kontext. Zusammen helfen diese Materialien, Fragen zu formulieren; sie dürfen nicht als Ersatz für eine vollständige Protokoll- und Implementierungsbewertung dargestellt werden.