CFB1, CFB8 und CFB128: Das ist die Feedback-Größe, nicht die Schlüssellänge

Ein Name wie AES-256-CFB1 trägt zwei Zahlen, und sie beantworten verschiedene Fragen. Die 256 ist die AES-Schlüssellänge. Die 1 ist das CFB-Feedback, also die Segmentgröße: eine Eigenschaft dessen, wie der Modus seinen Zustand weiterbewegt. Liest man die 1 als Schlüssellänge, wirkt der Name wie eine katastrophale Fehlkonfiguration — und deshalb kehrt die Frage immer wieder.

Entscheiden Sie vor dem Urteil über den Namen, welche der drei Größen Sie vor sich haben: Schlüsselgröße, Blockgröße oder Segmentgröße. Nur die erste ist im üblichen Sinn ein Sicherheitsparameter.

Drei Zahlen, drei Größen

AES nimmt Schlüssel mit 128, 192 oder 256 Bit an und hat unabhängig von der Wahl einen Block von 128 Bit. Die Blockgröße gehört zu AES, nicht zum Modus. Das CFB-Suffix ist die dritte Größe: wie viele Daten der Modus pro Schritt verbraucht und zurückspeist. Die OpenSSL-Dokumentation zu AES nennt diese Verschiebegrößen für die CFB-Varianten ausdrücklich.

CFB1 speist jeweils ein Bit zurück, CFB8 ein Byte, CFB128 einen ganzen Block. Alle drei nutzen intern dieselbe Blockchiffre mit 128 Bit; geändert wird, wie viele Bit jedes berechneten Blocks pro Operation verwendet werden. Deshalb verschiebt das Suffix die Kosten und das Pufferverhalten, nicht die Schlüsselstärke.

Warum sich die Blockgröße nie ändert

AES ist eine Blockchiffre mit festem 128-Bit-Block, und Modi sind Konstruktionen darum herum. Keiner von ihnen verkleinert den Block, um zur Segmentgröße zu passen. Eine CFB1-Implementierung berechnet weiterhin einen vollen AES-Block und entnimmt ein Bit des Ergebnisses. Die übrigen Bit werden für diesen Schritt verworfen, und genau dort liegt der Effizienzpreis.

Ein Feedback von einem Bit bedeutet also nicht einen Schlüssel von einem Bit, und ein Name lässt sich nicht nach seinem Suffix ordnen. CFB128 ist nicht viermal stärker als CFB32; sie verarbeitet größere Segmente.

Was die Segmentgröße tatsächlich ändert

Die Segmentgröße ändert, wie viel Chiffrat pro Schritt zurückgespeist wird und wie viel Klartext jeder Schritt tragen kann. Sie ändert auch Fehlerfortpflanzung und Pufferverhalten, was für stromartige Nutzung zählt. Byte-orientierte Segmente passen zu Puffern, bit-orientierte nicht.

In der Praxis wählt das Protokoll den Modus, nicht der Betreiber. Ein VPN-Datenkanal nutzt die Konstruktion, die sein Protokoll vorgibt, mit eigenem Integritätsschutz, und eine Bibliotheksliste sagt nur, welche Namen existieren.

Einen unqualifizierten CFB-Namen lesen

Ein unqualifizierter CFB-Name braucht seinen Implementierungskontext. In den Headern von OpenSSL 1.0.2 ist EVP_aes_128_cfb ein Makro für EVP_aes_128_cfb128, mit passenden Aliasen für Schlüssel mit 192 und 256 Bit. Das ist eine API-Namenskonvention eines Zweigs, keine Aussage, dass jede Bibliothek, jedes Dateiformat oder jede GUI die Abkürzung gleich auflöst. Prüfen Sie Header oder Dokumentation der Version, die vor Ihnen liegt.

Sagt ein Altprofil CFB und der Peer akzeptiert es, werden die ausgehandelten Parameter irgendwo festgehalten: in einem Log, einem Konfigurationsdump, einer API-Antwort. Lesen Sie diese, statt die Segmentgröße aus einer Anzeigezeichenkette zu schließen.

Was ein Modusname Ihnen nicht sagt

Der Name beschreibt Verschlüsselungsverhalten und sonst nichts. Ein VPN braucht weiterhin Integritätsschutz, Schlüsselableitung und Peer-Authentifizierung, und CFB liefert nichts davon. Auch der Tausch von CFB8 gegen CFB1 ist keine kosmetische Änderung: Das Verhalten auf dem Draht unterscheidet sich, und beide Seiten müssen dieselbe Konstruktion unterstützen. Ein Name in einer Bibliothek belegt zudem nicht, dass das eingesetzte Gateway ihn für seinen Datenkanal akzeptiert.

Für alles, was gepflegt wird, gilt: die vollständige Schutzanordnung des Protokolls und die Policy des Betreibers nutzen und Bibliotheks- und Gateway-Versionen, die genaue Option und das ausgehandelte Ergebnis festhalten. Der alte Name erklärt, was Sie lesen; er rechtfertigt nicht, die Konfiguration wiederzubeleben.