Hybridverschlüsselung

Die Primitive Hybridverschlüsselung kombiniert die Effizienz der symmetrischen Verschlüsselung mit der Zweckmäßigkeit der (asymmetrischen) Kryptografie mit öffentlichen Schlüsseln. Jeder kann Daten mit dem öffentlichen Schlüssel verschlüsseln, aber nur Nutzer mit dem privaten Schlüssel können die Daten entschlüsseln.

Bei der Hybridverschlüsselung generiert der Absender einen neuen symmetrischen Schlüssel, um den Klartext jeder Nachricht zu verschlüsseln und so einen Geheimtext zu erzeugen. Dieser symmetrische Schlüssel wird mit dem öffentlichen Schlüssel des Empfängers gekapselt. Bei der Hybridentschlüsselung wird der symmetrische Schlüssel vom Empfänger entkapselt und dann zum Entschlüsseln des Geheimtexts verwendet, um den ursprünglichen Klartext wiederherzustellen. Weitere Informationen zum Speichern oder Übertragen des Geheimtextes zusammen mit der Schlüsselkapselung finden Sie unter Tink-Hybridverschlüsselungsdrahtformat.

Die Hybridverschlüsselung hat folgende Attribute:

  • Vertraulichkeit: Niemand kann Informationen über den verschlüsselten Klartext abrufen (mit Ausnahme der Länge), es sei denn, er hat Zugriff auf den privaten Schlüssel.
  • Asymmetrie: Der Geheimtext kann mit dem öffentlichen Schlüssel verschlüsselt werden. Für die Entschlüsselung ist jedoch der private Schlüssel erforderlich.
  • Zufälligkeit: Die Verschlüsselung wird zufällig durchgeführt. Zwei Nachrichten mit demselben Klartext liefern nicht denselben Geheimtext. Dadurch wird verhindert, dass Angreifer erkennen, welcher Geheimtext einem bestimmten Klartext entspricht.

Die Hybridverschlüsselung wird in Tink als ein Primitivpaar dargestellt:

  • HybridEncrypt für die Verschlüsselung
  • HybridDecrypt zur Entschlüsselung

Parameter für Kontextinformationen

Zusätzlich zum Klartext akzeptiert die Hybridverschlüsselung den zusätzlichen Parameter context_info. Dies sind normalerweise öffentliche Daten, die implizit aus dem Kontext stammen, aber an den resultierenden Geheimtext gebunden sein sollten. Dies bedeutet, dass Sie mit dem Geheimtext die Integrität der Kontextinformationen bestätigen können. Es gibt jedoch keine Garantien für die Geheimhaltung oder Authentizität. Die tatsächlichen Kontextinformationen können leer oder null sein. Damit der resultierende Geheimtext jedoch richtig entschlüsselt werden kann, muss für die Entschlüsselung derselbe Kontextinformationswert angegeben werden.

Eine konkrete Implementierung der Hybridverschlüsselung kann Kontextinformationen auf verschiedene Weise an den Geheimtext binden, z. B.:

  • Verwenden Sie context_info als verknüpfte Dateneingabe für die symmetrische AEAD-Verschlüsselung (siehe RFC 5116).
  • Verwenden Sie context_info als „CtxInfo“-Eingabe für HKDF (wenn die Implementierung HKDF als Schlüsselableitungsfunktion verwendet, siehe RFC 5869).

Schlüsseltyp auswählen

Wir empfehlen für die meisten Anwendungsfälle die Verwendung des Schlüsseltyps DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM. Dieser Schlüsseltyp implementiert den HPKE-Standard (Hybrid Public Key Encryption) gemäß RFC 9180. HPKE besteht aus einem Schlüsselkapselungsmechanismus (Key Encapsulation Verfahren, KEM), einer Schlüsselableitungsfunktion (Key Derivation Function, KDF) und einem AEAD-Algorithmus (Authenticated Encryption with Associated Data).

DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_256_GCM verwendet speziell:

  • KEM: Diffie-Hellman über Kurve25519 mit HKDF-SHA-256, um das gemeinsame Secret abzuleiten.
  • KDF: HKDF-SHA-256 zur Ableitung des Sender- und Empfängerkontexts.
  • AEAD: AES-256-GCM mit 12-Byte-Nonces, die nach dem HPKE-Standard generiert wurden.

Weitere unterstützte HPKE-Schlüsseltypen sind unter anderem:

  • DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_AES_128_GCM
  • DHKEM_X25519_HKDF_SHA256_HKDF_SHA256_CHACHA20_POLY1305
  • DHKEM_P256_HKDF_SHA256_HKDF_SHA256_AES_128_GCM
  • DHKEM_P521_HKDF_SHA512_HKDF_SHA512_AES_256_GCM

Weitere Informationen zu den Algorithmusoptionen für KEM, KDF und AEAD finden Sie unter RFC 9180.

Tink wird zwar nicht mehr empfohlen, unterstützt aber auch einige ECIES-Varianten, wie in der Norm ISO 18033-2 von Victor Shoup beschrieben. Einige unterstützte ECIES-Schlüsseltypen sind unten aufgeführt:

  • ECIES_P256_HKDF_HMAC_SHA256_AES128_GCM
  • ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_GCM
  • ECIES_P256_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256
  • ECIES_P256_COMPRESSED_HKDF_HMAC_SHA256_AES128_CTR_HMAC_SHA256

Minimale Properties

  • Klartext- und Kontextinformationen können eine beliebige Länge haben (im Bereich von 0 bis 232 Byte).
  • Schutz vor Angriffen mit adaptivem ausgewähltem Geheimtext
  • 128-Bit-Sicherheit für Elliptische-Kurven-basierte Schemas

Beispielanwendungsfälle

Weitere Informationen finden Sie unter Ich möchte Daten austauschen.