Summary

  • Am 2. November genehmigte der IESG draft-ietf-hpke-hpke-06 zur Veröffentlichung als Proposed Standard. Der Entwurf beschreibt ein- und zweistufige Verfahren zur Schlüsselableitung.
  • Die zitierte Sicherheitsanalyse deckt nach Aussage des Entwurfs die zweistufige Variante ab. Eine gleichwertige formale Prüfung der einstufigen Variante steht aus.

Ein Standardisierungsgremium kann eine Konstruktion freigeben und zugleich offenlegen, wo die Beweisarbeit endet. Genau das zeigt die IESG-Mitteilung vom 2. November: Der HPKE-Nachfolger ist für die Veröffentlichung als Proposed Standard genehmigt. Der IETF-Datatracker führt den Stand „Approved-announcement sent“. Eine endgültige RFC-Fassung samt Nummer ist der nächste Schritt. Die Entscheidung über die technische Form ist bereits gefallen.

HPKE kombiniert einen Schlüsselkapselungsmechanismus, eine Ableitungsfunktion und authentifizierte Verschlüsselung. Der bisherige KDF-Weg besteht aus Extract() gefolgt von Expand(). Revision 06 beschreibt zusätzlich einen einzigen Aufruf von Derive() über kodierte Eingaben mit HPKE-Kennzeichnung. Die getrennten Abläufe betreffen den Schlüsselfahrplan, die Kapselung und den Export weiterer Geheimnisse. Schon Revision 05 enthielt die einstufige Variante. Neu ist die deutlichere Aussage über die Tragweite der vorhandenen Sicherheitsbeweise.

Abschnitt 1.1 ordnet die zitierten Analysen der zweistufigen Variante zu. In Abschnitt 9.1 erwarten die Autoren, dass sich die Überlegungen auf eine einstufige Funktion übertragen lassen, wenn deren Derive() als Zufallsorakel modelliert werden kann. Sie halten zugleich fest: Formal verifiziert wurde diese Übertragung bislang nicht. Abschnitt 9.3 nennt die benötigte Eigenschaft. Der Schlüsselfahrplan muss pseudozufällige Werte liefern, wenn dem Angreifer entweder das KEM-Geheimnis oder der vorab vereinbarte Schlüssel verborgen bleibt, selbst wenn er andere Eingaben kennt oder wählen kann. SHAKE erscheint als Beispiel einer erweiterbaren Ausgabefunktion für dieses Modell.

Die Kennnummern sind bereits vergeben. Im IANA-Register für HPKE stehen vier SHAKE- und TurboSHAKE-KDFs unter 0x0010 bis 0x0013, mit Verweis auf den separaten Post-Quanten-Entwurf der HPKE-Arbeitsgruppe. Dieser Entwurf steht weiterhin auf I-D Exists. Revision 06 verlangt eine neue Registerspalte Two-Stage und für die vier Einträge den Wert N. Am 3. November zeigte das öffentliche Register noch die alte Spaltenstruktur. Eine Kennnummer ordnet einen Algorithmus zu; sie zählt weder Produkte noch ersetzt sie dessen Sicherheitsanalyse.

Für Implementierungen gibt es prüfbare Grenzen. Bei der einstufigen Konstruktion sind psk, psk_id und info wegen ihrer Zwei-Byte-Längenangaben jeweils auf 65.535 Byte begrenzt. Für die Exportausgabe gilt eine separate Obergrenze derselben Größe. Solche Werte kann ein Testlauf kontrollieren. Welche Anwendungen den neuen Weg tatsächlich wählen, lässt sich aus der IESG-Mitteilung ebenfalls nicht ablesen; dafür wäre eine Einsatzübersicht nötig.