Betriebsmodi & Padding

Erstmal einfach — Worum geht's hier?

Eine Blockchiffre wie AES verschlüsselt genau 16 Bytes. Was machst du, wenn deine Nachricht 5 MB groß ist? Du brauchst eine Regel, wie du die Blöcke verkettest — das nennt man Betriebsmodus. Die Wahl ist wichtiger als die Chiffre selbst.

Die wichtigsten Modi

ECB (Electronic Codebook) — niemals nutzen. Jeder Block wird unabhängig verschlüsselt. Gleicher Klartext-Block → gleicher Geheimtext-Block. Wenn man ein Bild damit verschlüsselt, erkennt man das Originalmotiv noch — das berühmte „ECB-Pinguin"-Beispiel.

CBC (Cipher Block Chaining): Jeder Block wird vor der Verschlüsselung mit dem vorigen Geheimtext-XORt. Der erste Block bekommt einen zufälligen IV. Lange Zeit Standard, hat aber keinen Integritätsschutz und ist anfällig für Padding-Oracle-Angriffe.

CTR (Counter): Verschlüsselt einen Zähler statt der Daten und XORt das Ergebnis auf den Klartext. Macht aus der Blockchiffre eine Stromchiffre. Parallelisierbar, schnell, kein Padding nötig — aber tot bei Nonce-Wiederverwendung.

GCM (Galois/Counter Mode): CTR plus eingebauter Authentifizierung (MAC). Aktueller Standard für TLS, WireGuard, … Liefert Vertraulichkeit und Integrität in einem Schritt („AEAD"). Wenn du nicht sicher bist, nimm GCM.

Warum eigentlich? — Warum reicht ECB nicht?

Weil identische Eingabeblöcke identische Ausgabeblöcke produzieren — Muster im Klartext bleiben sichtbar. In einem Bitmap-Bild wiederholen sich Pixelmuster (z. B. einfarbige Flächen) in 16-Byte-Blöcken, und im Geheimtext wiederholen sich dann genau dieselben Block-Muster. Du siehst die Silhouette des Originals.

Generell: ECB leakt Gleichheit. Das ist in fast jedem Anwendungsfall ein Problem.

Tiefer rein — Padding — und warum es gefährlich ist

CBC braucht Eingaben, deren Länge ein Vielfaches von 16 ist. Lösung: PKCS#7-Padding — fehlen n Bytes bis zum nächsten Block, füllt man mit n Bytes vom Wert n auf. Beim Entschlüsseln prüft man das Padding und schneidet es ab.

Genau diese Prüfung ist das Problem: Verrät der Server, ob das Padding stimmt (über Fehlermeldungen oder Timing), kann ein Angreifer Byte für Byte den Klartext rekonstruieren — ganz ohne Schlüssel. Das ist der Padding-Oracle-Angriff (Vaudenay 2002), und er hat reale Systeme massenhaft kaputt gemacht (POODLE, BEAST, Lucky 13, …).

Lehre: encrypt-then-MAC oder gleich ein AEAD-Modus wie GCM. Niemals nackt CBC ohne Authentifizierung.

Häufiger Denkfehler — Den Nonce / IV wiederverwenden

In CTR und GCM ist der Nonce (Number used ONCE) heilig. Verwendest du denselben Nonce zweimal mit demselben Schlüssel, passiert dir der Two-Time-Pad-Bruch aus der OTP-Lektion: C₁ ⊕ C₂ = M₁ ⊕ M₂, beide Klartexte rekonstruierbar.

Bei GCM ist es noch schlimmer: Nonce-Wiederholung erlaubt dem Angreifer, den Authentifizierungs-Schlüssel zu berechnen — dann kann er beliebige Nachrichten fälschen. Deshalb: Nonce immer zufällig oder als monoton steigender Zähler, niemals wiederholen.

Warum eigentlich? — Was ist „AEAD“?

Authenticated Encryption with Associated Data. Ein Modus, der drei Sachen gleichzeitig liefert:

Vertraulichkeit — niemand liest den Klartext.
Integrität — Manipulation am Geheimtext wird erkannt.
Authentizität für Zusatzdaten — z. B. Header-Felder, die sichtbar sein dürfen, aber nicht verändert werden.

Standard-AEADs heute: AES-GCM und ChaCha20-Poly1305. Letzteres ist auf Smartphones ohne AES-Hardware schneller und wird z. B. von Google bevorzugt.

← AES Diffie-Hellman →