8.2. Errors (Erreurs)

8.2. Erreurs

Les API HPKE publiques de haut niveau spécifiées dans ce document sont toutes faillibles. Celles-ci incluent les fonctions Setup et toutes les fonctions de contexte de chiffrement. Par exemple, Decap() peut échouer si la clé encapsulée enc est invalide, et Open() peut échouer si le déchiffrement du texte chiffré échoue. Les erreurs explicites générées tout au long de cette spécification, ainsi que les conditions qui conduisent à chaque erreur, sont les suivantes :

• ValidationError : Échec de validation d'entrée ou de sortie KEM ; Section 4.1.

• DeserializeError : Échec de désérialisation de clé publique ou privée ; Section 4.

• EncapError : Échec de Encap() ; Section 4.

• DecapError : Échec de Decap() ; Section 4.

• OpenError : Échec de Open() AEAD du contexte ; Sections 4 et 5.2.

• MessageLimitReachedError : Débordement du numéro de séquence AEAD du contexte ; Sections 4 et 5.2.

• DeriveKeyPairError : Échec de dérivation de paire de clés ; Section 7.1.3.

Des erreurs implicites peuvent également se produire. Par exemple, certaines classes d'échecs, par exemple des clés publiques de destinataire mal formées, peuvent ne pas produire d'erreurs explicites. Par exemple, pour la variante DHKEM décrite dans cette spécification, l'algorithme Encap() échoue lorsqu'une clé publique de destinataire invalide est donnée. Cependant, d'autres algorithmes KEM peuvent ne pas avoir d'algorithme efficace pour vérifier la validité des clés publiques. Par conséquent, une erreur équivalente peut ne pas se manifester avant le déchiffrement AEAD chez le destinataire. Autre exemple, la fonction AuthDecap() de DHKEM produira une sortie invalide si la mauvaise clé publique d'expéditeur est donnée. Cette erreur n'est pas détectable avant le déchiffrement AEAD ultérieur.

Les erreurs de ce document sont destinées à servir de guide aux implémenteurs. Elles ne constituent pas une liste exhaustive de toutes les erreurs qu'une implémentation pourrait émettre. Par exemple, les futurs KEM pourraient avoir des cas d'échec internes, ou une implémentation pourrait manquer de mémoire.

La façon dont ces erreurs sont exprimées dans une API ou gérées par les applications est un détail spécifique à l'implémentation. Par exemple, certaines implémentations peuvent abandonner ou paniquer en cas d'échec DeriveKeyPairError étant donné qu'il ne se produit qu'avec une probabilité négligeable, tandis que d'autres implémentations peuvent réessayer l'opération DeriveKeyPair échouée. Voir Section 7.1.3 pour plus d'informations. Autre exemple, certaines implémentations du DHKEM spécifié dans ce document peuvent choisir de transformer ValidationError de DH() en EncapError ou DecapError de Encap() ou Decap(), respectivement, tandis que d'autres peuvent choisir de lever ValidationError non modifié.

Les applications utilisant les API HPKE ne doivent pas supposer que les erreurs ici sont complètes, ni qu'elles supposent que certaines classes d'erreurs se manifesteront toujours de la même manière pour toutes les suites cryptographiques. Par exemple, le DHKEM spécifié dans ce document émettra une DeserializationError ou ValidationError si une clé publique KEM est invalide. Cependant, un nouveau KEM pourrait ne pas avoir d'algorithme efficace pour déterminer si une clé publique est valide ou non. Dans ce cas, une clé publique invalide pourrait plutôt produire une OpenError lors de la tentative de déchiffrement d'un texte chiffré.