AES-Verschlüsselungsmodi erklärt Warum GCM CBC in den meisten Fällen übertrifft (und wann nicht)

Wenn die Dokumentation Ihnen sagt, „AES-256 verwenden“, ist das eine unvollständige Empfehlung. AES ist ein Blockverschlüsselungsverfahren – es verschlüsselt genau einen 128-Bit-Block zu einem Zeitpunkt. Der Betriebmodus bestimmt, wie AES reale Daten, die länger als 16 Bytes sind, verarbeitet und wie viel Schutz er gegen Angreifer bietet, die das Kryptotext beobachten oder verändern können. Wenn das falsch ist, endet das Ergebnis mit „verschlüsselten“ Daten, die Ihre Dateistruktur enthüllen oder einem System, das anfällig für Bit-Flip-Angriffe ist, ausgesetzt sind.

Die vollständige Algorithmus-Spezifikation sieht aus wie AES-256-GCM oder AES-128-CBC — Schlüsselgröße gefolgt von Modus. Dieser Artikel erklärt, was jeder Modus tatsächlich tut, warum GCM der Standard ist und wann Sie etwas anderes legitim verwenden können.

Zuerst: Warum ECB ein Meme ist und nicht nur ein Witz

ECB (Electronic Codebook) ist der naive Modus. Jeder 16-Byte-Block des Klartexts wird unabhängig mit dem gleichen Schlüssel verschlüsselt. Das bedeutet, dass identische Klartextblöcke identische Chiffretextblöcke erzeugen.

Das klassische Beispiel ist das ECB-verschlüsselte Linux-Pinguin (Tux). Das Bitmap wird blockweise verschlüsselt, aber da große Bereiche des Bildes eine gleichfarbige Farbe haben, zeigt der verschlüsselte Version immer noch eine Pinguin-Form. Die Verschlüsselung ist mathematisch gültig – die Daten sind vermischt – aber die Muster wird erhalten.

In der Praxis spielt das dann immer dann eine Rolle, wenn der Klartext Wiederholungen enthält: Datenbankzeilen mit einem gemeinsamen Präfix, Dateiheader, gepaßte Felder. ECB enthüllt die Struktur. Es gibt keine zulässige Anwendung von ECB in neuen Code. Wenn Sie Code warten, der ECB verwendet, ersetzen Sie ihn.

Die Werte, die Sie kennen sollten

CBC – der Modus, den das meisten Legacy-Code verwendet

Cipher Block Chaining XORt jedes Klartextblocks mit dem vorherigen Chiffretextblock vor der Verschlüsselung. Dadurch wird das Problem des ECB-Musters behoben – identische Klartextblöcke erzeugen unterschiedliche Chiffretextblöcke, weil die Kette jedes Blocks seine Verschlüsselung von dem vorherigen abhängig macht.

CBC benötigt einen Initialisierungsvektor (IV) – einen zufälligen 16-Byte-Wert, der die Kette für den ersten Block startet. Der IV muss nicht geheim sein, aber er muss zufällig sein und muss mit dem Chiffretext übertragen werden.

Das Problem mit CBC: es bietet Vertraulichkeit aber nicht Integrität. Ein Angreifer, der den Chiffretext in der Übertragung ändern kann, kann bestimmte Bits im entschlüsselten Output vorhersagbar verändern. Dies ist die Grundlage von Padding-Oracle-Angriffen, die echte Systeme (POODLE, BEAST, Lucky Thirteen) gebrochen haben. Wenn Sie CBC ohne eine separate MAC (Message Authentication Code) zur Integritätsprüfung verwenden, sind Sie anfällig. Das Muster heißt „encrypt-then-MAC“ – verschlüsseln Sie zuerst, dann HMAC den Chiffretext und überprüfen Sie die MAC vor der Entschlüsselung. Wenn die Reihenfolge falsch ist, ist das ein klassischer Fehler.

CBC ist auch sequentiell – Sie können die Verschlüsselung nicht parallelisieren (jeder Block hängt vom vorherigen Chiffretext ab) und die Entschlüsselung ist nur teilweise parallelisierbar.

CTR – Stream-Cipher-Verhalten aus einem Block-Cipher

Counter-Modus verwandelt AES in einen Stream-Cipher. Statt den Klartext direkt zu verschlüsseln, verschlüsselt er aufeinanderfolgende Zählerwerte und XORt das Ergebnis mit dem Klartext. Dadurch benötigt CTR-Modus keine Padding (er funktioniert auf beliebig lange Daten), ist vollständig parallelisierbar in beiden Richtungen und ermöglicht zufälligen Zugriff auf jede Position im Chiffretext bei der Entschlüsselung.

CTR verwendet einen Nonce (Number used once) anstatt einen vollständigen IV. Der Nonce muss pro Nachricht für eine gegebene Schlüssel einzigartig sein – die Wiederholung eines Nonces mit dem gleichen Schlüssel enthüllt das XOR der beiden Klartexte, was katastrophal ist. Im Gegensatz zu CBC bietet CTR auch keine Integritätsversicherung. Gleiche Geschichte: Wenn Sie eine MAC benötigen, um gegen Manipulationen geschützt zu sein, brauchen Sie „encrypt-then-MAC“.

CTR macht Sinn, wenn Sie Eigenschaften eines Stream-Ciphers benötigen – große Dateien, zufälliger Zugriff bei Entschlüsselung, hohe Durchsatz-Szenarien, bei denen Parallelität wichtig ist – und wenn Sie die MAC-Schicht separat behandeln.

GCM – Authentifizierter Verschlüsselung, ein Schritt

Galois/Counter Mode ist CTR-Modus plus eine eingebaute Authentifizierung (GHASH). Sie erhalten Vertraulichkeit und Integrität in einem einzigen Primitiv. Die Authentifizierung – typischerweise 128 Bit – ermöglicht dem Empfänger, zu überprüfen, ob der Chiffretext nicht verändert wurde, bevor er entschlüsselt wird. Kein separates HMAC-Schritt, keine Möglichkeit, die Reihenfolge von „encrypt-then-MAC“ falsch zu machen.

GCM unterstützt auch Zusätzliche authentifizierte Daten (AAD) – Daten, die authentifiziert, aber nicht verschlüsselt werden. Dies ist nützlich für Header, Metadaten oder alle Daten, die eine Integritätsversicherung benötigen, aber nicht vertraulich sein müssen. Das AAD wird zusammen mit dem Chiffretext an die Authentifizierung überprüft.

Der Nonce für GCM ist standardmäßig 96 Bit (12 Byte). Wie CTR ist die Wiederholung eines Nonces mit dem gleichen Schlüssel fatal – die Wiederholung eines Nonces mit dem gleichen Schlüssel unter GCM enthüllt sowohl den Klartext als auch die Authentifizierungsschlüssel (H), was die Sicherheit vollständig zerstört. Generieren Sie immer Nonces mit einem kryptografisch sicheren Zufallsgenerator; verwenden Sie keine abgeleiteten Zähler, es sei denn, Sie haben ein sorgfältig verwaltetes globales Zählersystem mit strengen Einzigartigkeitsgarantien.

GCM ist parallelisierbar und erfordert keine Padding. Es ist die empfohlene Standardanwendung in TLS 1.3, Signal-Protokoll und den meisten modernen kryptographischen Bibliotheken. Wenn Sie neuen Code schreiben, ist GCM Ihr Standard.

Modus-Vergleich

Modus	Authentifiziert	Parallelisierbar	Bedarf an Padding	Risiko von Nonce/IV-Wiederholung	Urteil
ECB	NEIN	Ja	Ja	N/A (kein IV)	Nicht verwenden
CBC	Nein (MAC hinzufügen)	Verschlüsseln: Nein / Entschlüsseln: Ja	Ja	Moderat	Nur für Legacy-Systeme
CTR	Nein (MAC hinzufügen)	Ja	NEIN	Kritisch – Wiederholung führt zu Klartextleak	Niche-Anwendung
GCM	Ja (integriert)	Ja	NEIN	Kritisch – Wiederholung führt zu vollständiger Sicherheitsbrechung	Standardwahl

AES-256-GCM in Node.js

Hier ist eine vollständige Verschlüsselungs- und Entschlüsselungs-Implementierung mit Node.js’ integriertem crypto Modul – keine Abhängigkeiten erforderlich:

const crypto = require('crypto');

const ALGORITHM = 'aes-256-gcm';
const KEY_LENGTH = 32; // 256 bits
const NONCE_LENGTH = 12; // 96 bits — GCM default
const TAG_LENGTH = 16; // 128-bit auth tag

function encrypt(plaintext, key) {
  const nonce = crypto.randomBytes(NONCE_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, key, nonce, {
    authTagLength: TAG_LENGTH,
  });

  const encrypted = Buffer.concat([
    cipher.update(plaintext, 'utf8'),
    cipher.final(),
  ]);
  const tag = cipher.getAuthTag();

  // Prepend nonce + tag to ciphertext for storage/transmission
  return Buffer.concat([nonce, tag, encrypted]);
}

function decrypt(ciphertext, key) {
  const nonce = ciphertext.subarray(0, NONCE_LENGTH);
  const tag = ciphertext.subarray(NONCE_LENGTH, NONCE_LENGTH + TAG_LENGTH);
  const data = ciphertext.subarray(NONCE_LENGTH + TAG_LENGTH);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, nonce, {
    authTagLength: TAG_LENGTH,
  });
  decipher.setAuthTag(tag);

  // Throws if auth tag doesn't match — do not catch this silently
  return Buffer.concat([decipher.update(data), decipher.final()]).toString('utf8');
}

// Generate a key (do this once; store it securely)
const key = crypto.randomBytes(KEY_LENGTH);

const message = 'Hello, authenticated encryption.';
const ciphertext = encrypt(message, key);
console.log('Encrypted:', ciphertext.toString('hex'));

const plaintext = decrypt(ciphertext, key);
console.log('Decrypted:', plaintext); // Hello, authenticated encryption.

Ein paar Dinge, die bei diesem Code wertvoll sind:

• Der Nonce wird pro Verschlüsselungsauftrag neu generiert — crypto.randomBytes ist kryptografisch sicher. Ersetzen Sie dies nicht durch einen Zähler, es sei denn, Sie verstehen das Problem der verteilten Einzigartigkeit.
• Der Nonce und der Authentifizierungs-Tag werden mit dem Chiffretext gespeichert – sie müssen mit dem verschlüsselten Daten transportiert werden. Der Nonce ist öffentlich; der Tag ist öffentlich. Nur der Schlüssel ist geheim.
• decipher.final() wirft bei Authentifizierungsfehlern – das ist das richtige Verhalten. Fangen Sie es nicht still und geben Sie teilweise Klartext zurück. Ein Authentifizierungsfehler bedeutet, dass die Daten verändert wurden oder der Schlüssel falsch ist.
• Die Schlüsselverwaltung ist der schwierige Teil — crypto.randomBytes(32) gibt Ihnen einen guten Schlüssel, aber wo Sie ihn speichern und rotieren, ist wichtiger als die Algorithmuswahl. Verwenden Sie einen Secrets-Manager, nicht eine konstante Eingabe.

Möchten Sie Verschlüsselungsmode interaktiv testen? IO Tools’ AES Verschlüsselungs-/Entschlüsselungs-Tool erlaubt Ihnen, mit CBC und GCM-Modi im Browser zu verschlüsseln und zu entschlüsseln – nützlich zur Überprüfung der Interoperabilität oder zum Debuggen einer Integration. Um einen kryptografisch sicheren 256-Bit-Schlüssel zu generieren, verwenden Sie das AES-Schlüssel-Generator.

IV und Nonce: die Regeln, die tatsächlich zählen

Falsche Verwendung von Nonce/IV verursacht mehr echte Sicherheitsbrüche als die Algorithmuswahl. Die Regeln:

• Generieren Sie immer Nonce/IV mit einem CSPRNG — crypto.randomBytes() in Node, os.urandom() in Python, SecureRandom in Java. Nicht Math.random(). Nicht eine Uhrzeit. Nicht einen absteigenden Zähler, es sei denn, es ist ein sorgfältig verwaltetes globales Zählersystem mit strengen Einzigartigkeitsgarantien.
• Die Wiederholung eines GCM-Nonce führt zu vollständiger Authentifizierungsschädigung – mit dem gleichen Schlüssel und Nonce wird die Authentifizierungsschlüssel H ausgespielt. Ein Angreifer kann dann Authentifizierungs-Tags für beliebige Chiffretexte fälschen. Dies ist nicht theoretisch: Der Forbidden Attack nutzt dies und wurde gegen echte Implementierungen eingesetzt.
• CBC-IV-Wiederholung ist weniger katastrophal, aber immer noch schlecht – gewählte-Plaintext-Angriffe werden möglich. In der Praxis generieren Sie immer einen neuen IV pro Nachricht.
• Leiten Sie niemals einen Nonce aus dem Nachrichteninhalt ab – deterministische Nonce, die auf vorhersehbare Daten basieren, erzeugen vorhersehbare Muster. Verwenden Sie Zufall.

Wann ist CBC oder CTR immer noch die richtige Wahl

GCM ist nicht immer die Lösung:

• Interoperabilität mit Legacy-Systemen – wenn Sie mit einem System integrieren, das nur AES-CBC spricht, verwenden Sie CBC. Dokumentieren Sie die MAC-Anforderung klar und implementieren Sie sie korrekt (encrypt-then-MAC mit HMAC-SHA256).
• Grenzgebiete mit keinem GHASH-Hardware – GCMs Authentifizierungsschritt verwendet GHASH, was auf Hardware ohne spezielle Beschleunigung schwerer ist als eine einfache Blockverschlüsselung. Einige eingebettete Zielgeräte, bei denen CTR+CMAC verfügbar ist, aber GHASH nicht, können CTR-Modus rechtfertigen.
• Stream-Verschlüsselung sehr großer Dateien, bei denen Sie zufälligen Zugriff bei Entschlüsselung benötigen – CTRs zufälliger Zugriffseigenschaft ist nützlich, wenn Sie Position N entschlüsseln müssen, ohne Positionen 0 bis N-1 zu lesen. GCM erlaubt das technisch, aber die Authentifizierung erfordert die Verarbeitung des gesamten Chiffretexts, was den Sinn verliert.
• Plattformverschlüsselung – Vollplattformverschlüsselung verwendet XTS-Modus (nicht hier abgedeckt), nicht GCM, weil XTS für feste, zufällig zugreifbare Sektoren konzipiert ist. GCM dient für Nachrichtenverschlüsselung, nicht für Sektorenverschlüsselung.

Die kurze Version

Verwenden Sie AES-256-GCM für neuen Code. Generieren Sie pro Verschlüsselungsauftrag einen neuen 12-Byte-zufälligen Nonce. Speichern Sie den Nonce und den Authentifizierungs-Tag mit dem Chiffretext. Behandeln Sie Authentifizierungsfehler als Fehler, nicht als Warnung – geben Sie niemals Klartext zurück, wenn GCM sagt, dass die Daten ungültig sind.

Wenn Sie bestehende CBC-Code überprüfen: stellen Sie sicher, dass „encrypt-then-MAC“ korrekt implementiert ist, überprüfen Sie, dass IVs zufällig sind (nicht wiederholt, nicht sequentiell), und planen Sie eine Migration zu GCM, wenn die Wartungszeit erlaubt ist. CBC mit korrekter HMAC ist nicht gebrochen – es hat nur mehr „Falle“ als GCM.

ECB: Ersetzen Sie es einfach. Es gibt keinen Audit-Pfad, der mit „ECB ist hier in Ordnung“ endet.

Das könnte Ihnen auch gefallen