Zusammenfassung

  • RFC 1969 verwendete den letzten Ciphertext-Block eines Pakets als CBC-Eingang des nächsten. Das sparte paketweise Initialisierung, machte die Entschlüsselung aber vom Vorgänger abhängig.
  • Ein offen ausgehandelter 64-Bit-Nonce wurde mit dem gemeinsamen DES-Schlüssel zum ersten Kettenwert. Die sichtbare 16-Bit-Sequenz erkannte Lücken, authentisierte jedoch weder Inhalt noch Gegenstelle.
  • Fehlt N-1, ist N nicht entschlüsselbar. Kam dessen Ciphertext an, liefert sein Endblock den Zustand für N+1: Die Kette läuft weiter, die beiden fehlenden Klartexte bleiben verloren.

Der unlesbare Block als Rettungsleine

Im Verlustbeispiel von RFC 1969 geht Paket N-1 verloren, während N und N+1 korrekt eintreffen. Für N fehlt der letzte Ciphertext-Block des Vorgängers. Der Klartext kann nicht berechnet werden. Für N+1 liegt der nötige Vorgängerblock dagegen am Ende des empfangenen N.

Der Empfänger muss also einen unlesbaren Ciphertext behalten. Sein Inhalt ist verloren, sein Zustand nicht. Ein vorschnelles Verwerfen verlängerte die Desynchronisierung. Die in der RFC beschriebene recovery setzt die Rechenfolge wieder in Gang; sie rekonstruiert weder N-1 noch N und sagt nichts über PPP- oder Anwendungszustellung.

Warum CBC nicht am Paket endete

Die im Juni 1996 als Informational veröffentlichte RFC 1969 konkretisierte DES-CBC für das PPP Encryption Control Protocol. Nach dem Opened-Zustand verschlüsselte DESE Protocol- und Information-Feld mit einem 56-Bit-Schlüssel. LCP- und ECP-Pakete blieben ausgenommen.

Für das erste Paket gab es einen ausgehandelten Start. Danach wurde C[0] aus dem letzten Ciphertext-Block des vorherigen Pakets genommen. So musste nicht jedes Paket einen neuen Initialisierungswert tragen, und gleiche Klartextfolgen begannen nicht immer unter identischem Zustand. Dafür war ein einzelnes Paket kryptografisch nicht mehr selbständig.

Die PPP-Grenze blieb eine Übertragungsgrenze, aber keine Zustandsgrenze. Genau diese Kopplung erklärt den expliziten Zähler. Die allgemeine ECP-Aushandlung gehört zu RFC 1968; hier ist der Algorithmus bereits gewählt.

Offener Nonce, externer Schlüssel

Die zehn Oktette lange DESE-Option enthielt einen acht Oktette langen Initial Nonce. Der Empfänger bot ihn für das erste Paket an, das der Peer in seine Richtung senden sollte. Die RFC empfahl einen neuen Wert je ECP-Aushandlung und nannte eine zeitbasierte Bildung als Beispiel.

Der Nonce lief offen über die Leitung. Der tatsächliche erste CBC-Wert war E[k](nonce). Geheimhaltung kam vom gemeinsamen DES-Schlüssel, Variation vom Nonce, Fortsetzung vom vorherigen Ciphertext. Ein beobachteter Nonce war somit keine geheime Berechtigung.

Wie der gemeinsame Schlüssel verteilt und geschützt wurde, blieb außerhalb der Spezifikation. Manuelle Konfiguration war üblich; PPP-Authentisierung oder Endpoint Identifier konnten bei der Auswahl helfen. Erfolgreiches Entschlüsseln belegt kompatibles Material und Zustand, nicht die Identität einer benannten Organisation oder Person.

Eine Sequenznummer ist kein Siegel

Die 16-Bit-Sequence Number begann nach ECP Opened bei null. Eine Unterbrechung zeigte, dass der gespeicherte Kettenwert nicht zum empfangenen Paket passen musste.

Der Zähler prüfte keine Ciphertext-Bits und besaß keinen von RFC 1969 definierten Authentikator. Verlust, Umordnung, lokale Verwerfung oder aktiver Eingriff konnten dieselbe Lücke erzeugen. Auch der Absender wurde nicht beglaubigt.

RFC 2419 formulierte später ausdrücklich: nur confidentiality, keine integrity, authentication oder nonrepudiation; keine Garantie gegen replay, cut-and-paste oder active tampering. Eine erfolgreiche CBC-Rechnung ist daher kein Unversehrtheitsnachweis.

Acht-Oktett-Blöcke belasten die MRU

DES verlangt Vielfache von acht. RFC 1969 erlaubte bei Protokollen mit eigener Längenangabe — etwa IP, IPX, XNS und CLNP — zufällige Endbytes. Wo solche Bytes die Bedeutung veränderten, sollte selbstbeschreibendes Padding verwendet werden. Die richtige Behandlung hing damit von der Klassifikation des inneren Protokolls ab.

Das selbstbeschreibende Verfahren stammte aus RFC 1570. Selbst bereits ausgerichteter Klartext konnte acht zusätzliche Oktette benötigen, wenn sein Ende wie Padding aussah. Im MRU-Beispiel erzeugen PFC, ein ursprüngliches Vielfaches von acht, ein einoktettiges Protocol field, sieben Padding-Oktette und die zweioctettige Sequenz zusammen bis zu zehn Oktette Wachstum im DESE Information field. Die DESE-Aushandlung erhöht die MRU nicht automatisch.

RFC 2419 vereinheitlichte die Interpretation

Der RFC-2419-Eintrag erklärt RFC 1969 für obsolet. DESE-bis verlangte selbstbeschreibendes Padding für alle Klartextpakete, unabhängig von der PPP-SDP-Option, begrenzte es auf acht Oktette und empfahl die Verwerfung bei falschem Muster.

Da neue und alte Empfänger denselben entschlüsselten Inhalt unterschiedlich deuten konnten, erhielt DESE-bis ECP Type 3. Type 1 wurde deprecated und musste von neuen Implementierungen abgelehnt werden. Das IANA-PPP-Register dokumentiert diese Trennung.

RFC 2419 ersetzte DES nicht durch Triple-DES. 3DESE wurde separat in RFC 2420 unter Type 2 beschrieben. Der Nachfolger korrigierte Padding und Interoperabilität, verhinderte stilles Versionsmischen, wechselte auf den Standards Track und zog die Sicherheitsgrenze schärfer.

Exportrecht als Textspur

RFC 1969 verwies auf DES-ECB-Quellcode, erklärte aber, US-Exportgesetze verhinderten die Aufnahme kompilierfertigen Codes. RFC 2419 behielt den Satz. Er ist eine direkte Spur der Kryptografie-Exportordnung der 1990er Jahre im Dokument selbst.

Mehr belegt er nicht. Er entscheidet weder über die Rechtmäßigkeit eines Produkts noch über Herkunft, Export oder Einsatz einer Implementierung. Fehlender Quellcode im RFC ist kein Beweis für fehlende Software oder Sicherheit.

Der IETF Datatracker und RFC Editor tragen Identität und Nachfolge. Die Errata-Seite lieferte bei der Erfassung keinen nutzbaren Inhalt; eine leere Errata-Menge wird daher nicht behauptet.

Aus einem grünen Signal werden getrennte Belege

Ein belastbares Protokoll trennt ECP-Richtung und Type, Nonce-Fingerprint und Schlüsselreferenz, beobachtete Sequenz, verwendeten Vorgängerblock, Entschlüsselung, Padding und PPP-Entscheidung nach RFC 1661. Anwendungszustellung ist ein weiterer Beleg.

Heng Lus Running-Code Primacy verlangt, Spezifikation und beobachtbaren Betrieb getrennt zu prüfen. Minimum Initial Specification begrenzt Felder auf ihre minimale Funktion. Reality Layers und Reality, Not Advocacy verhindern, ein Symbol zum Ergebnis oder eine Struktur zur erfundenen Absicht zu machen. Sie sind redaktionelle Methode, keine Quellen zur DESE-Geschichte.