10. Message Encoding (Encodage des messages)

10. Message Encoding (Encodage des messages)

Ce document ne spécifie pas de format de codage sur le fil (wire format encoding) pour les messages HPKE. Les applications qui adoptent HPKE doivent donc spécifier un mécanisme de codage non ambigu qui inclut, au minimum: la valeur encapsulée enc, la ou les valeurs de texte chiffré (et l'ordre s'il y en a plusieurs), et toutes les valeurs info qui ne sont pas implicites. Un exemple de valeur non implicite est la clé publique du destinataire utilisée pour l'encapsulation, qui peut être nécessaire si un destinataire possède plusieurs clés publiques.

L'interface AEAD utilisée dans ce document est basée sur [RFC5116], qui produit et consomme une seule valeur de texte chiffré. Comme discuté dans [RFC5116], cette valeur de texte chiffré contient le texte en clair chiffré ainsi que toutes les données d'authentification, encodées de la manière décrite par le schéma AEAD individuel. Certaines implémentations ne sont pas structurées de cette manière, fournissant plutôt un texte chiffré et une balise d'authentification séparés. Lorsque de telles implémentations AEAD sont utilisées dans des implémentations HPKE, l'implémentation HPKE doit combiner ces entrées en une seule valeur de texte chiffré dans Seal() et les analyser dans Open(), où les détails d'analyse sont définis par le schéma AEAD. Par exemple, avec les schémas AES-GCM spécifiés dans ce document, la balise d'authentification GCM est placée dans les derniers Nt octets de la sortie de texte chiffré.