Zusammenfassung

  • „RC5“ wird erst mit W, R, b, den tatsächlichen Schlüsselbytes, Modus, IV und Schlussblockregel zu einer interoperablen Identität.
  • Beispielcode, ASN.1 und Vektoren belegen Übereinstimmung für konkrete Eingaben; sie belegen weder Sicherheit noch Zufall, IV-Einmaligkeit, wirksame Speicherlöschung, Protokolleinbindung oder Betrieb.

Robert Baldwin und Ronald Rivest veröffentlichten RFC 2040 im Oktober 1996. Das Dokument beschreibt RC5, RC5-CBC, RC5-CBC-Pad und RC5-CTS detailliert genug, um getrennte Implementierungen zur Übereinstimmung zu bringen. Der RFC-Editor-Eintrag führt es als Informational und stellt klar, dass es keinen Internetstandard spezifiziert.

Der Text bezeichnet sich zudem als Neuformulierung bereits veröffentlichter Arbeiten. Sein Beitrag ist deshalb nicht die Erfindung von RC5, sondern die präzise Antwort auf die Frage, welche Entscheidungen übereinstimmen müssen, damit derselbe Name dieselben Bytes erzeugt.

Die Identität steckt im Parametersatz

W ist die Wortgröße. Die Blockgröße B umfasst zwei Wörter, BB gibt sie in Bytes an. R bezeichnet die Rundenzahl. b ist die Länge des Benutzerschlüssels, K dessen Bytefolge. Die Expansion erzeugt S mit T = 2(R+1) Wörtern. Im CBC-Modus kommt ein blocklanges Initialisierungssegment I hinzu.

Zwei Programme können beide RC5 nennen und dennoch verschiedene Maschinen bilden. Eine Abweichung bei W, R, Schlüssellänge, Byteordnung, Modus, IV oder Schlussregel reicht aus. Selbst W/R/b bestimmen ohne die tatsächlich gebundenen Schlüsselbytes keine vollständige Identität.

Die Schlüsselexpansion legt diese Abhängigkeit offen. K wird little-endian in Wörter gepackt, S mit von W abhängigen Konstanten initialisiert und beide Felder werden dreimal so oft gemischt, wie das größere von ihnen Elemente besitzt. Der C-Beispielpfad setzt einen 64-Bit-Block fest. Ein Ergebnis dieses Pfades ist kein Test aller möglichen Parametrisierungen.

Objekte legen den verborgenen Zustand frei

Die Darstellung trennt Schlüssel- und Chiffreobjekte. Das CBC-Objekt hält Paddingmodus, Rundenzahl, expandierten Schlüssel, ursprünglichen IV, aktuellen Verkettungsblock, einen unvollständigen Eingabeblock und dessen Position.

Encrypt_Init bindet und expandiert den Schlüssel und setzt die Kette auf den IV zurück. SetIV behält den expandierten Schlüssel, ersetzt aber den IV und leert Kette und Puffer. Update nimmt nacheinander Fragmente auf, hält einen Rest zurück, gibt nur ganze Blöcke aus, verknüpft jeden per XOR mit dem Kettenzustand und macht das Chiffrat zum nächsten Zustand.

Final entscheidet über den Rest. Gewöhnliches CBC meldet bei nicht ausgerichteten Bytes einen Fehler. CBC-Pad erzeugt stets einen Abschlussblock mit ein bis BB Bytes, deren Wert jeweils der Paddinglänge entspricht. Auch eine bereits ausgerichtete Nachricht erhält einen ganzen Paddingblock. Finalisierung ist damit Teil der Chiffrenidentität.

Drei Enden, drei unterschiedliche Maschinen

CBC akzeptiert nur Vielfache der Blockgröße. CBC-Pad verlängert die Ausgabe für andere Längen. CTS hält die Länge gleich, verändert aber die letzten zwei Teile. Der verkettete vorletzte Vollblock wird verschlüsselt; ein Präfix des Zwischenwerts bildet das kurze Schlusschiffrat. Das letzte Klartextfragment wird mit Nullen aufgefüllt, mit dem Zwischenwert XOR-verknüpft und erneut verschlüsselt. Dieser Vollblock steht in der Ausgabe vor dem gestohlenen Fragment.

Darum muss ein CTS-Objekt bis Final bis zu zwei Blöcke puffern. Vorher steht weder fest, welcher Vollblock wirklich der vorletzte ist, noch wie viele Bytes in das kurze Ende wandern.

Zur ausführbaren Lesart gehören die verifizierten Errata. Erratum 513 begrenzt CTS auf Klartexte von mehr als einem Block. 514 verlangt für kurze Nachrichten den IV, wenn kein früherer Chiffratblock existiert. 587 ergänzt beim Entschlüsseln ein fehlendes XOR samt derselben IV-Regel. Eine nur am ursprünglichen Wortlaut orientierte Implementierung kann gerade an der Grenze abweichen.

Die Reichweite der Testvektoren

Abschnitt 9 will ausdrücklich helfen, die Korrektheit einer Implementierung zu bestätigen. Das Programm verwendet Acht-Byte-Blöcke und liest Paddingflag, Rundenzahl, Schlüsselbytes, einen Acht-Byte-IV und Klartext.

Ein Treffer belegt für genau dieses Tupel Übereinstimmung bei Schlüsselabbildung, Expansion, Blocktransformation, CBC-Verkettung und Finalisierung. Eine Abweichung belegt einen Bruch, diagnostiziert aber nicht automatisch dessen Ort.

Die veröffentlichten Ergebnisse behandeln CBC und CBC-Pad, nicht CTS. Sie beobachten weder Schlüssel- und IV-Erzeugung noch IV-Einmaligkeit, kryptografische Stärke, korrekte API-Nutzung, Compilerverhalten, tatsächliche Speicherlöschung, Protokolltransport oder Einsatz. Eine Bytefolge kann keine unbeobachtete Betriebsrealität beweisen.

ASN.1 beschreibt nur einen Teil

Abschnitt 11 weist CBC und CBC-Pad OID-Bögen mit den Enden 8 und 9 zu. Die Parameterfolge trägt Version, Rundenzahl, Blockgröße und optional den IV. Fehlt er, gilt nach der historischen Regel ein Nullblock passender Größe. Erratum 6380 korrigiert Bezeichner, Groß-/Kleinschreibung und Einschränkungssyntax, ohne Felder hinzuzufügen.

b, Schlüsselbytes und Expansionstabelle fehlen; CTS erhält keinen Bezeichner. OID und Parameter legen also einen Teil des Interpretationsvertrags fest, nicht den ganzen Ausführungskontext. Ein definierter Null-IV bei Abwesenheit ist eine Dekodierregel, kein Nachweis zufälliger oder eindeutiger IVs im Betrieb.

Quelltextabsicht ist kein beobachteter Effekt

Die Beispielzerstörer schreiben vor dem Freigeben Nullen in Strukturen. Das belegt eine Anweisung im Quelltext. Es belegt nicht, dass ein Compiler sie erhalten hat oder sämtliche Kopien sensibler Daten verschwanden. Auch die Sicherheits- und Patentaussagen von 1996 dokumentieren ihren zeitgenössischen Kontext, keine heutige Bewertung.

Richtig gelesen ist RFC 2040 ein starkes Koordinationsartefakt. Sie benennt die Entscheidungen, die konvergieren müssen. Die Beweisgrenze wird erst überschritten, wenn Byteübereinstimmung zu Sicherheit, ordentlichem Betrieb oder Verbreitung erklärt wird.

Quellen