5. Hybrid Public Key Encryption (Hybride Public-Key-Verschlüsselung)
5. Hybrid Public Key Encryption (Hybride Public-Key-Verschlüsselung)
In diesem Abschnitt definieren wir einige HPKE-Varianten. Alle Varianten nehmen einen öffentlichen Empfängerschlüssel und eine Sequenz von Klartexten pt und erzeugen einen gekapselten Schlüssel enc und eine Sequenz von Chiffretexten ct. Diese Ausgaben sind so konstruiert, dass nur der Inhaber von skR den Schlüssel aus enc entkapsen und die Chiffretexte entschlüsseln kann. Alle Algorithmen nehmen auch einen info-Parameter, der verwendet werden kann, um die Generierung von Schlüsseln zu beeinflussen (z.B. um Identitätsinformationen einzubeziehen), und einen aad-Parameter, der zusätzliche authentifizierte Daten für den verwendeten AEAD-Algorithmus bereitstellt.
Zusätzlich zum Basisfall der Verschlüsselung an einen öffentlichen Schlüssel umfassen wir drei authentifizierte Varianten: eine, die den Besitz eines vorgeteilten Schlüssels authentifiziert, eine, die den Besitz eines privaten KEM-Schlüssels authentifiziert, und eine, die den Besitz sowohl eines vorgeteilten Schlüssels als auch eines privaten KEM-Schlüssels authentifiziert. Alle authentifizierten Varianten tragen zusätzliches Schlüsselmaterial zur Verschlüsselungsoperation bei. Die folgenden Ein-Byte-Werte werden verwendet, um zwischen Modi zu unterscheiden:
| Mode | Value (Wert) | |============---|============| | mode_base | 0x00 | | mode_psk | 0x01 | | mode_auth | 0x02 | | mode_auth_psk | 0x03 |
Table 1: HPKE Modes (Tabelle 1: HPKE-Modi)
Alle diese Fälle folgen demselben grundlegenden zweistufigen Muster:
-
Einrichten eines Verschlüsselungskontexts, der zwischen Sender und Empfänger geteilt wird.
-
Verwenden dieses Kontexts zum Verschlüsseln oder Entschlüsseln von Inhalten.
Ein context (Kontext) ist eine implementierungsspezifische Struktur, die den verwendeten AEAD-Algorithmus und Schlüssel kodiert und die verwendeten Nonces verwaltet, sodass dieselbe Nonce nicht mit mehreren Klartexten verwendet wird. Er verfügt auch über eine Schnittstelle zum Exportieren geheimer Werte, wie in Abschnitt 5.3 beschrieben. Siehe Abschnitt 5.2 für eine Beschreibung dieser Struktur und ihrer Schnittstellen. Die HPKE-Entschlüsselung schlägt fehl, wenn die zugrunde liegende AEAD-Entschlüsselung fehlschlägt.
Die hier beschriebenen Konstruktionen setzen voraus, dass die relevanten nicht-privaten Parameter (enc, psk_id usw.) zwischen Sender und Empfänger durch eine Anwendung transportiert werden, die HPKE verwendet. Darüber hinaus benötigt ein Empfänger mit mehr als einem öffentlichen Schlüssel eine Möglichkeit zu bestimmen, welcher seiner öffentlichen Schlüssel für die Kapselungsoperation verwendet wurde. Beispielsweise können Anwendungen diese Informationen zusammen mit einem Chiffretext vom Sender zum Empfänger senden. Die Spezifikation eines solchen Mechanismus wird der Anwendung überlassen. Weitere Details finden Sie in Abschnitt 10.
Beachten Sie, dass einige KEMs möglicherweise AuthEncap() oder AuthDecap() nicht unterstützen. Für solche KEMs werden nur mode_base oder mode_psk unterstützt. Zukünftige Spezifikationen, die neue KEMs definieren, MÜSSEN angeben, ob diese Modi unterstützt werden. Weitere Details finden Sie in Abschnitt 7.1.5.
Die in diesem Abschnitt beschriebenen Verfahren sind in einem Python-ähnlichen Pseudocode dargestellt. Die verwendeten Algorithmen bleiben implizit.