AES-GCM vs AES-CBC: Welchen Modus verwenden und warum

AES ist eine Blockchiffre. Blockchiffren verschlüsseln für sich allein nur einen einzelnen Datenblock fester Größe (16 Byte bei AES). Um größere Daten oder Daten zu verschlüsseln, die kein genaues Vielfaches von 16 Byte sind, benötigt man einen darüberliegenden Betriebsmodus.

Die beiden Modi, die man in realen Systemen am häufigsten antrifft, sind CBC (Cipher Block Chaining) und GCM (Galois Counter Mode). Sie sind nicht austauschbar. Den falschen zu wählen ist der Typ Fehler, der nicht abstürzt, keine Tests zum Scheitern bringt und die Sicherheit still schwächt, bis jemand gezielt nachschaut. Dieser Artikel erläutert, was jeder Modus tut, welche Fallstricke Menschen auf falsche Füße stellen, und in welchen Fällen jeder Modus die richtige Wahl ist.

Was ein Modus eigentlich leistet

Stellen Sie sich vor, Sie haben 80 Byte Daten. AES kann immer nur 16 davon auf einmal verschlüsseln. Naive Lösung: In 5 Blöcke zu je 16 aufteilen, jeden unabhängig verschlüsseln, die Ergebnisse zusammenfügen. Das nennt sich ECB (Electronic Codebook) und ist auf bekannte, sichtbare Weise gebrochen: Identische Eingabeblöcke erzeugen identische Geheimtextblöcke. Muster im Klartext scheinen direkt durch.

Jeder andere Modus existiert, um dieses Problem und die danach folgenden Probleme zu lösen. Die zwei häufigsten Lösungen:

• CBC kettet Blöcke aneinander. Jeder Klartextblock wird mit dem Geheimtext des vorherigen Blocks per XOR verknüpft, bevor er verschlüsselt wird. Der erste Block verwendet einen Initialisierungsvektor (IV), um das Muster zu brechen.
• GCM nutzt einen Zähler, um AES in eine Stromchiffre (CTR-Modus) umzuwandeln, und legt dann einen Authentifizierungstag darüber, um Manipulation zu erkennen.

Beide beseitigen das ECB-Musterproblem. In allem anderen unterscheiden sie sich.

Wenn Sie mit einer echten Implementierung experimentieren möchten, führt das AES Encrypt/Decrypt -Tool beide Modi im Browser aus und zeigt Ihnen den IV/Nonce, den Geheimtext und (bei GCM) den Authentifizierungstag.

CBC: gekettet, gepaddet, unauthentifiziert

Das CBC-Verschlüsselungsrezept:

1. Einen zufälligen 16-Byte-IV wählen.
2. Klartextblock 1 nehmen, per XOR mit dem IV verknüpfen, durch AES mit dem Schlüssel laufen lassen. Das ergibt Geheimtextblock 1.
3. Klartextblock 2 nehmen, per XOR mit Geheimtextblock 1 verknüpfen, durch AES laufen lassen. Das ergibt Geheimtextblock 2.
4. Bis zum Ende wiederholen.
5. Der IV wird zusammen mit dem Geheimtext übermittelt (er ist nicht geheim, muss aber unvorhersehbar sein).

Das Ketten ist das, was CBC sicher gegen den ECB-Musterleck macht: Identische Klartextblöcke erzeugen unterschiedliche Geheimtextblöcke, weil jeder mit einem anderen vorherigen Geheimtextblock per XOR verknüpft wird.

Zwei Konsequenzen ergeben sich aus diesem Design und werden zu Fallstricken:

Padding. CBC erfordert, dass der Klartext ein Vielfaches von 16 Byte ist. Hat Ihr Klartext 22 Byte, muss er auf 32 aufgefüllt werden. Das Standardpadding-Verfahren ist PKCS#7. Die Entschlüsselungsseite muss das Padding entfernen, bevor sie den Klartext zurückgibt.

Padding-Oracle-Angriffe. Wenn Ihr Entschlüsselungspfad dem Angreifer (über Timing, Fehlermeldungen oder unterschiedliche Statuscodes) mitteilt, ob das Padding gültig war, kann ein Angreifer den Klartext byte für byte ohne Kenntnis des Schlüssels wiederherstellen. Das ist die berüchtigte “Padding-Oracle”-Schwachstelle, die 2010 Microsoft ASP.NET traf und eine lange Liste anderer Systeme davor.

Keine Authentifizierung. CBC verschlüsselt. Es authentifiziert nicht. Ein Angreifer, der Bits im Geheimtext umschießen kann, kann entsprechende Bits im Klartext umschießen. Das nennt man Formbarkeit (Malleability). Um das zu verhindern, muss CBC-Geheimtext in einen separaten MAC (typischerweise HMAC-SHA-256) eingebettet werden, in einer “Encrypt-then-MAC”-Konstruktion. Vergisst man den MAC, ist der Geheimtext still manipulierbar.

Diese zwei Probleme - Padding-Oracles und fehlende Authentifizierung - sind die Hauptgründe, warum CBC für neue Designs aus der Mode gekommen ist.

GCM: Zählermodus plus Authentifizierungstag

GCM ist das Paradebeispiel für Authenticated Encryption with Associated Data (AEAD). Es erledigt Verschlüsselung und Authentifizierung in einem einzigen, gekoppelten Schritt.

Das Rezept:

1. Einen zufälligen oder sequenziellen 12-Byte-Nonce (96 Bit) wählen.
2. AES im Zählermodus verwenden: Zähler || Nonce verschlüsseln, per XOR mit jedem Klartextblock verknüpfen, um Geheimtext zu erzeugen. Kein Padding nötig; der Zählertrick erzeugt einen Keystrom beliebiger Länge.
3. Einen Galois-Feld-MAC über den Geheimtext (und etwaige “zugeordnete Daten” wie Header, die authentifiziert, aber nicht verschlüsselt werden sollen) berechnen.
4. Ausgabe: Nonce + Geheimtext + 16-Byte-Authentifizierungstag.

Bei der Entschlüsselung führt der Empfänger dieselbe MAC-Berechnung durch, vergleicht sie mit dem empfangenen Tag und fährt nur fort, wenn sie übereinstimmen. Ein Bit-Flip irgendwo im Geheimtext oder den zugeordneten Daten lässt die Tag-Prüfung fehlschlagen, und der Klartext wird abgelehnt.

Drei Dinge machen GCM für die meisten Fälle angenehmer als CBC + HMAC:

• Kein Padding, kein Padding-Oracle. Die Stromverschlüsselung erzeugt Geheimtext genau so lang wie der Klartext.
• Authentifizierung ist eingebaut. Man kann sie nicht versehentlich vergessen.
• Performance. Auf modernen x86- und ARM-Prozessoren hat AES-GCM Hardware-Beschleunigung (AES-NI plus PCLMULQDQ für die Galois-Mathematik). Es ist typischerweise deutlich schneller als CBC + HMAC-SHA-256.

Der Haken: GCM hat eine extrem scharfe Kante.

Die Nonce-Wiederverwendungs-Falle

Wenn Sie zwei verschiedene Klartexte mit demselben Schlüssel und demselben Nonce verschlüsseln, ist GCM katastrophal gebrochen. Nicht “ein bisschen geschwächt” - vollständig gebrochen. Ein Angreifer, der beide Geheimtexte sieht, kann sie per XOR verknüpfen, um das XOR der beiden Klartexte zu erhalten, was ausreicht, um das meiste von beiden zu lesen, und kann auch neue authentifizierte Nachrichten fälschlicherweise erstellen, ohne den Schlüssel zu kennen.

Das ist wesentlich schlimmer als der äquivalente Fehler bei CBC, wo IV-Wiederverwendung schlimm, aber reparierbar ist.

In der Praxis gilt die Regel: Verwenden Sie niemals dasselbe (Schlüssel, Nonce)-Paar zweimal. Die zwei Strategien, um das zu gewährleisten:

• Zufalls-Nonces mit 96 Bit aus einem hochwertigen Zufallsgenerator. Die Geburtstagsschranke besagt, dass Sie nach 2^48 Nachrichten eine ungefähr 50%ige Kollisionswahrscheinlichkeit haben. Bleiben Sie deutlich darunter und Sie sind sicher. Für die meisten Anwendungen ist 2^32 Nachrichten pro Schlüssel die konservative Obergrenze.
• Zähler-basierte Nonces. Jedes Gerät oder jede Sitzung hat einen Zähler, der pro Nachricht inkrementiert wird. Den Zähler niemals zurücksetzen, ohne den Schlüssel zu rotieren.

Wenn Sie ein System aufbauen, in dem Nachrichten von Clients wiederholt oder wiedergegeben werden könnten (z. B. mobile Apps mit schlechten Netzwerken), sind zählerbasierte Nonces mit einer strikten “Schlüssel rotieren beim Zähler-Überlauf”-Richtlinie zuverlässiger als zufallsbasierte Nonces.

Für zufallsbasierte Schlüssel und IVs ist ein CSPRNG zwingend erforderlich. Der Zufalls-String-Generator verwendet crypto.getRandomValues des Browsers, dasselbe Grundelement, das WebCrypto intern verwendet. Wenn Sie Schlüssel im Code generieren, bieten crypto.randomBytes (Node), secrets.token_bytes (Python) oder secure_random (Ruby) dieselbe Garantie.

Wann welcher Modus zu wählen ist

Eine einfache Entscheidungsregel, die in über 90% der Fälle gilt:

• GCM verwenden für neue Anwendungen, Netzwerkprotokolle (TLS 1.3 ist standardmäßig GCM), Dateiverschlüsselung mit nicht wiederholten Schlüsseln und alles, bei dem ein einziges Grundelement Vertraulichkeit und Integrität übernehmen soll.
• CBC + HMAC-SHA-256 verwenden, wenn Sie mit einem älteren System interoperieren müssen, das es bereits spricht, oder wenn Sie spezifische FIPS/Compliance-Gründe haben, die darauf angewiesen sind.
• Niemals CBC allein verwenden für irgendetwas, das eine Vertrauensgrenze überschreitet. Die Formbarkeit beißt irgendwann zu.
• Niemals ECB verwenden für irgendetwas anderes als die Verschlüsselung eines einzelnen Blocks (und selbst dann ist ein Wrapper vorzuziehen).

Die relative Anzahl der Fallstricke ist Teil des Grundes, warum GCM tendenziell gewinnt. CBC hat Padding-Oracles, IV-Vorhersagerisiken (CBC erfordert unvorhersehbare IVs, nicht nur eindeutige) und aufgesetzte MACs, die jemand vergessen hat hinzuzufügen. GCM hat genau eine große Fallstrick (Nonce-Wiederverwendung), und der ist laut.

Schlüsselgrößen und Rotation

AES ist mit 128-, 192- und 256-Bit-Schlüsseln spezifiziert. AES-128 ist für jedes Bedrohungsmodell gut, das keine Nationalstaat-Quantencomputer-Gegner einschließt (und selbst die sind Jahrzehnte davon entfernt, symmetrische 128-Bit-Verschlüsselung zu brechen). AES-256 wird von einigen Compliance-Regelungen (FIPS, bestimmte staatliche Datenklassifizierungen) vorgeschrieben und ist die sicherere Standardwahl, wenn man nicht sicher ist.

Sowohl CBC als auch GCM nehmen einen Schlüssel beliebiger AES-unterstützter Länge ohne Änderungen. Es gibt keinen Sicherheitsgrund, 192 gegenüber 128 oder 256 für einen der Modi zu bevorzugen.

Schlüssel rotieren, wenn:

• Der Nonce-Zähler sich der sicheren Obergrenze nähert.
• Ein Gerät kompromittiert oder ein Credential geleakt wird.
• Ein geplantes Rotationsintervall (typisch: 1 Jahr für langlebige Schlüssel, Stunden für ephemere Sitzungsschlüssel) abläuft.

Um zu überprüfen, ob zwei beliebige Eingaben denselben Fingerabdruck ergeben (ein anderes, aber verwandtes Grundelement), deckt der Hash-Generator SHA-256 und Verwandte ab. Hashes vergleicht man; Geheimtext entschlüsselt man.

Eine kurze Anmerkung zu TLS und anderen Protokollen

In der Regel wählt man AES-Modi nicht manuell. Protokolle auf höherer Ebene wählen für einen:

• TLS 1.3: Nur AES-GCM und ChaCha20-Poly1305. CBC ist verschwunden.
• TLS 1.2: Beide, aber Konfigurationen mit AES-CBC sind veraltet und werden schrittweise deaktiviert.
• SSH: GCM ist der Standard für AES-basierte Chiffren in modernem OpenSSH.
• PGP/GPG: Meist OCB oder GCM in neueren Versionen; ältere Nachrichten verwendeten CFB.
• AWS KMS, Azure Key Vault, GCP KMS: Alle verwenden intern standardmäßig GCM.

Die Tatsache, dass jedes größere Protokoll zu authentifizierten Modi (GCM, ChaCha20-Poly1305, OCB) migriert, ist selbst das stärkste Argument für die Wahl von GCM im eigenen Code.

Das Fazit

CBC ist ein Legacy-Modus, der sorgfältige Padding-Behandlung und einen separaten MAC erfordert, um sicher zu sein. GCM ist der moderne Standard: schneller, authentifiziert und frei von Padding-Oracles, mit dem einen entscheidenden Vorbehalt, dass man niemals einen Nonce wiederverwenden darf. Für neue Projekte GCM wählen und Nonce-Management auf eine Checkliste setzen. Für alten Code, der bereits korrekt CBC + HMAC spricht, ihn in Ruhe lassen, bis eine geplante Schlüsselrotation die Gelegenheit bietet, sauber zu migrieren.

Wenn Sie beide Modi an realen Eingaben ausprobieren möchten, zeigt das AES Encrypt/Decrypt -Tool den vollständigen IV/Nonce, Geheimtext und Tag, sodass Sie den strukturellen Unterschied zwischen einem CBC-Blob und einem GCM-Blob sehen können, ohne eine Zeile Code zu schreiben.