Zusammenfassung

  • RFC 3394 formte n 64-Bit-Datenblöcke in n+1 Chiffreblöcke um. Das Integritätsregister durchlief sechs Umläufe und wurde zum vorderen Block, statt nachträglich als Padding angehängt zu werden.
  • Unwrap durfte Daten nur freigeben, wenn das wiedergewonnene Register dem erwarteten Anfangswert entsprach. Dieser Beleg bewies weder Identität noch Autorisierung, Frische, KEK-Verwahrung oder spätere Nutzbarkeit.

Die Länge verriet den Mechanismus: Aus n Blöcken wurden n+1. Der Zusatzblock lag nicht außerhalb der Verschlüsselung. Er war mit jedem Teil der Ladung in Berührung gekommen und bewachte anschließend deren Ausgang.

RFC 3394 erschien im September 2002 als Informational RFC. Es überführte NISTs AES-Key-Wrap-Spezifikation in den Internetbestand und kennzeichnete seine Herkunft ausdrücklich: Der größte Teil des Textes stammte von NIST; Sicherheitsbehauptungen wurden der US-Regierung zugeschrieben. Der Beitrag war eine reproduzierbare Transformation mit einer klaren Annahmegrenze.

„Key Data“ konnte einen Schlüssel, mehrere Schlüssel oder Begleitdaten enthalten. Der Key-Encryption Key durfte 128, 192 oder 256 Bit lang sein. Die Eingabe wurde in mindestens zwei 64-Bit-Blöcke geteilt. Die Ausgabe enthielt genau einen Block mehr.

Die Daten lagen in R[1] bis R[n]; das separate Register A begann mit einem Initialwert. Sechs Durchgänge über alle Register ergaben 6n AES-Aufrufe. Jeder Schritt verschlüsselte A | R[i]. Die untere Hälfte ersetzte R[i], während die obere Hälfte nach XOR mit dem Zähler t das neue A bildete.

Am Ende wurde A zu C[0]. Es war kein Füllblock nach fertiger Verschlüsselung, sondern Zustand aus jedem Datenblock und jeder Zählerposition. Eine Veränderung, eine falsche KEK, andere Reihenfolge oder ein unpassender Initialwertvertrag sollte verhindern, dass der inverse Weg den erwarteten Start wiederfindet.

Unwrap kehrte Schritte und Zähler um. Die gewonnenen Register blieben zunächst Kandidaten. Nur wenn A einen geeigneten Initialwert ergab, durften sie ausgegeben werden. Andernfalls musste die Implementierung einen Fehler und keinerlei Schlüsseldaten zurückgeben. Der Beleg war nur so stark wie dieses reale Ausgabeverbot.

Der Standardwert bestand aus achtmal A6. RFC 3394 setzte bei korrekter Wiedergewinnung die Wahrscheinlichkeit beschädigter Daten mit 2^-64 an, unter den Annahmen der Konstruktion. Das war keine gemessene Vorfallrate, keine Signatur und keine Zusicherung für das umgebende Schlüsselmanagement.

Erfolg bedeutete Kohärenz von Chiffretext, KEK, Variante und Initialwert. Er nannte keinen menschlichen Absender, erteilte keine Berechtigung, bewies keine Frische und schloss eine kopierte KEK nicht aus. Ebenso wenig stand fest, dass der freigegebene Schlüssel den Typ und Zweck besaß, den die nächste Komponente erwartete.

Das RFC benannte die äußere Autorität: Wird die KEK kompromittiert, können sämtliche damit geschützten Daten offengelegt werden. Eine gestohlene KEK erzeugt gültige Hüllen. Auch ein bestandener Testvektor beweist nur Bytes, nicht Seitenkanalresistenz, Isolation, Fehleruniformität oder sichere Produktion.

Der ursprüngliche Bereich verlangte n >= 2 und Vielfache von 64 Bit. Alternative Initialwerte waren für andere Integritätsumfänge oder Längen vorgesehen. Damit war A eine Evolutionsfläche, keine fest verdrahtete Dekoration.

RFC 5649 nutzte sie für Key Wrap with Padding. Sein alternativer Initialwert verbindet eine 32-Bit-Konstante mit einer 32-Bit-Längenangabe. Unwrap prüft Konstante, plausible Länge und Null-Padding; für einen einzelnen Block gilt ein Sonderpfad. Eine neue Längenaussage brauchte einen neuen Beleg.

RFC 3565, JOSE und COSE ergänzten Protokollkennungen. Diese wählen Variante und KEK-Größe in ihren Containern, machen A aber nicht zur Identität und KW nicht austauschbar mit KWP. Die Errata korrigieren Formulierungen, Indizes und einen historischen Link, ohne sechs Durchgänge oder Freigabegrenze zu ändern.

Lu Hengs minimale Anfangsspezifikation erklärt die Zurückhaltung: Blöcke, Register, Zähler, Durchgänge, Initialwert und Fehler genügten zur Interoperabilität. Verwahrung und Autorisierung blieben bei den zuständigen Systemen. Running-Code-Primacy verlangt danach Belege, dass die tatsächliche Software bei einem Fehler wirklich nichts freigibt.

Das Zusatzregister entschied also, wann plausible Bytes zu einem freigegebenen Schlüssel wurden. Seine Autorität endete genau dort. Es bestätigte die innere Form der Hülle, nicht den Anspruch auf ihren Inhalt oder dessen späteren Erfolg.

Quellen