5. Hybrid Public Key Encryption (Chiffrement hybride à clé publique)
5. Hybrid Public Key Encryption (Chiffrement hybride à clé publique)
Dans cette section, nous définissons quelques variantes HPKE. Toutes les variantes prennent une clé publique de destinataire et une séquence de textes en clair pt et produisent une clé encapsulée enc et une séquence de textes chiffrés ct. Ces sorties sont construites de telle sorte que seul le détenteur de skR peut désencapsuler la clé de enc et déchiffrer les textes chiffrés. Tous les algorithmes prennent également un paramètre info qui peut être utilisé pour influencer la génération de clés (par exemple, pour intégrer des informations d'identité) et un paramètre aad qui fournit des données authentifiées supplémentaires à l'algorithme AEAD utilisé.
En plus du cas de base du chiffrement vers une clé publique, nous incluons trois variantes authentifiées: une qui authentifie la possession d'une clé prépartagée, une qui authentifie la possession d'une clé privée KEM, et une qui authentifie la possession à la fois d'une clé prépartagée et d'une clé privée KEM. Toutes les variantes authentifiées contribuent du matériel de clé supplémentaire à l'opération de chiffrement. Les valeurs d'un octet suivantes seront utilisées pour distinguer les modes:
| Mode | Value (Valeur) | |============---|===============| | mode_base | 0x00 | | mode_psk | 0x01 | | mode_auth | 0x02 | | mode_auth_psk | 0x03 |
Table 1: HPKE Modes (Tableau 1: Modes HPKE)
Tous ces cas suivent le même modèle de base en deux étapes:
-
Établir un contexte de chiffrement partagé entre l'émetteur et le destinataire.
-
Utiliser ce contexte pour chiffrer ou déchiffrer le contenu.
Un context (contexte) est une structure spécifique à l'implémentation qui encode l'algorithme AEAD et la clé utilisés, et gère les nonces utilisés de sorte que le même nonce ne soit pas utilisé avec plusieurs textes en clair. Il possède également une interface pour exporter des valeurs secrètes, comme décrit dans la Section 5.3. Voir la Section 5.2 pour une description de cette structure et de ses interfaces. Le déchiffrement HPKE échoue lorsque le déchiffrement AEAD sous-jacent échoue.
Les constructions décrites ici supposent que les paramètres non privés pertinents (enc, psk_id, etc.) sont transportés entre l'émetteur et le destinataire par une application utilisant HPKE. De plus, un destinataire ayant plus d'une clé publique a besoin d'un moyen de déterminer laquelle de ses clés publiques a été utilisée pour l'opération d'encapsulation. Par exemple, les applications peuvent envoyer ces informations aux côtés d'un texte chiffré de l'émetteur au destinataire. La spécification d'un tel mécanisme est laissée à l'application. Voir la Section 10 pour plus de détails.
Notez que certains KEM peuvent ne pas prendre en charge AuthEncap() ou AuthDecap(). Pour de tels KEM, seuls mode_base ou mode_psk sont pris en charge. Les spécifications futures qui définissent de nouveaux KEM DOIVENT indiquer si ces modes sont pris en charge. Voir la Section 7.1.5 pour plus de détails.
Les procédures décrites dans cette section sont présentées sous forme de pseudocode de type Python. Les algorithmes utilisés sont laissés implicites.