8.2. Errors (Fehler)

8.2. Fehler

Die in diesem Dokument spezifizierten öffentlichen High-Level-HPKE-APIs können alle fehlschlagen. Dazu gehören die Setup-Funktionen und alle Verschlüsselungskontextfunktionen. Beispielsweise kann Decap() fehlschlagen, wenn der gekapselte Schlüssel enc ungültig ist, und Open() kann fehlschlagen, wenn die Entschlüsselung des Chiffretexts fehlschlägt. Die expliziten Fehler, die in dieser Spezifikation generiert werden, sowie die Bedingungen, die zu jedem Fehler führen, sind wie folgt:

• ValidationError: KEM-Eingabe- oder Ausgabevalidierungsfehler; Abschnitt 4.1.

• DeserializeError: Fehler bei der Deserialisierung öffentlicher oder privater Schlüssel; Abschnitt 4.

• EncapError: Encap()-Fehler; Abschnitt 4.

• DecapError: Decap()-Fehler; Abschnitt 4.

• OpenError: Context-AEAD-Open()-Fehler; Abschnitte 4 und 5.2.

• MessageLimitReachedError: Context-AEAD-Sequenznummernüberlauf; Abschnitte 4 und 5.2.

• DeriveKeyPairError: Fehler bei der Schlüsselpaarableitung; Abschnitt 7.1.3.

Implizite Fehler können ebenfalls auftreten. Beispielsweise können bestimmte Fehlerklassen, z.B. fehlerhafte Empfänger-öffentliche Schlüssel, keine expliziten Fehler erzeugen. Beispielsweise schlägt der Encap()-Algorithmus für die in dieser Spezifikation beschriebene DHKEM-Variante fehl, wenn ein ungültiger öffentlicher Empfängerschlüssel angegeben wird. Andere KEM-Algorithmen haben jedoch möglicherweise keinen effizienten Algorithmus zur Überprüfung der Gültigkeit öffentlicher Schlüssel. Daher manifestiert sich ein äquivalenter Fehler möglicherweise erst bei der AEAD-Entschlüsselung beim Empfänger. Ein weiteres Beispiel: Die AuthDecap()-Funktion von DHKEM erzeugt eine ungültige Ausgabe, wenn der falsche öffentliche Senderschlüssel angegeben wird. Dieser Fehler kann erst bei der nachfolgenden AEAD-Entschlüsselung erkannt werden.

Die Fehler in diesem Dokument dienen als Leitfaden für Implementierer. Sie sind keine erschöpfende Liste aller Fehler, die eine Implementierung ausgeben könnte. Beispielsweise könnten zukünftige KEMs interne Fehlerfa��le haben, oder eine Implementierung könnte keinen Speicher mehr haben.

Wie diese Fehler in einer API ausgedrückt oder von Anwendungen behandelt werden, ist ein implementierungsspezifisches Detail. Beispielsweise können einige Implementierungen bei einem DeriveKeyPairError-Fehler abbrechen oder abstürzen, da er nur mit vernachlässigbarer Wahrscheinlichkeit auftritt, während andere Implementierungen die fehlgeschlagene DeriveKeyPair-Operation wiederholen können. Weitere Informationen finden Sie in Abschnitt 7.1.3. Ein weiteres Beispiel: Einige Implementierungen des in diesem Dokument spezifizierten DHKEM können sich dafür entscheiden, ValidationError von DH() in EncapError oder DecapError von Encap() bzw. Decap() umzuwandeln, während andere sich dafür entscheiden können, ValidationError unverändert auszulösen.

Anwendungen, die HPKE-APIs verwenden, sollten nicht davon ausgehen, dass die hier aufgeführten Fehler vollständig sind, noch sollten sie davon ausgehen, dass bestimmte Fehlerklassen für alle Cipher-Suites immer auf dieselbe Weise auftreten. Beispielsweise gibt das in diesem Dokument spezifizierte DHKEM einen DeserializationError oder ValidationError aus, wenn ein öffentlicher KEM-Schlüssel ungültig ist. Ein neues KEM hat jedoch möglicherweise keinen effizienten Algorithmus, um festzustellen, ob ein öffentlicher Schlüssel gültig ist oder nicht. In diesem Fall könnte ein ungültiger öffentlicher Schlüssel stattdessen einen OpenError beim Versuch, einen Chiffretext zu entschlüsseln, erzeugen.