AES-Verschlüsselung für Entwickler Wann Sie es benötigen und wie es funktioniert

Wenn Sie sensible Daten – wie Benutzer-PII, API-Schlüssel oder Finanzdaten – speichern, ist die AES-Verschlüsselung die Lösung, die Sie wählen. Es ist das Industriestandard für symmetrische Verschlüsselung bei Ruhezustand: schnell, bewährt und in jeder wichtigen Programmiersprache nativ unterstützt.

Aber AES, das falsch angewendet wird, ist schlimmer als nutzlos. Das ECB-Modus enthüllt Muster. Die Wiederholung eines IV bei GCM zerstört vollständig die Sicherheitsgarantie. Und die Speicherung Ihres Schlüssels neben Ihrem Chiffretext zerstört das gesamte Ziel.

Hier ist, was Sie tatsächlich benötigen, um AES korrekt in der Produktion zu verwenden.

Was ist AES?

AES (Advanced Encryption Standard) ist ein symmetrischer Blockchiffre. Symmetrisch bedeutet, dass der gleiche Schlüssel zum Verschlüsseln und Entschlüsseln verwendet wird. Blockchiffre bedeutet, dass es auf feste 128-Bit-Blöcke von Daten operiert.

Es ersetzte DES im Jahr 2001 und ist heute überall: in TLS, auf Festplatten, in Passwort-Manager und bei Datenfeldverschlüsselung. Im Gegensatz zu asymmetrischer Verschlüsselung (RSA, ECDH) ist AES schnell genug, um große Datenmengen in Echtzeit zu verschlüsseln. Der Nachteil: Beide Parteien benötigen den gleichen Schlüssel, weshalb die Schlüsselverteilung Ihr Problem wird.

AES-128 vs AES-256: Welche Schlüssellänge?

AES verfügt über drei Schlüssellängen: 128, 192 und 256 Bit. In der Praxis wählen Sie zwischen 128 und 256 Bit.

	AES-128	AES-256
Schlüssellänge	128 Bit	256 Bit
Runden	10	14
Leistung	Schneller	ca. 40% langsamer
Sicherheit	Stark – keine praktische Angriffsmöglichkeit bekannt	Stärker – zukunftssicher gegen Quantenrechner
Urteil	Geeignet für die meisten Anwendungen	Verwenden Sie sie für hochsensible Daten oder lange Aufbewahrungsdauer

AES-128 ist nicht gebrochen. Es gibt keine praktische Angriffsmöglichkeit. Aber wenn Sie Daten verschlüsseln, die über 20 Jahre sicher bleiben müssen – oder wenn Ihr Bedrohungsmodell zukünftige Quantenrechner einschließt – bietet AES-256 eine sinnvolle Sicherheitsmarge. Für die meisten Anwendungen, bei denen heute Datenfelder verschlüsselt werden, ist AES-128 ausreichend. Wenn Sie unsicher sind, verwenden Sie AES-256; die Leistungseinbuße ist für typische Workloads vernachlässigbar.

Modus der Ausführung: Warum GCM und nicht ECB

AES allein verschlüsselt nur einen 128-Bit-Block. Für echte Daten benötigen Sie einen Modus der Ausführung, der mehrere Blöcke und sie korrekt sequenziert. Diese Wahl ist entscheidend.

Modus	Authentifiziert	IV erforderlich	Urteil
ECB	NEIN	NEIN	Nicht verwenden – identische Klartexte erzeugen identische Chiffretexte und enthüllen Muster
CBC	NEIN	Ja	Veraltet – keine Authentifizierung, anfällig für Padding-Oracle-Angriffe
GCM	Ja (AEAD)	Ja (Nonce)	Verwenden Sie dies – verschlüsselt und authentifiziert in einem Durchgang

Verwenden Sie GCM. GCM (Galois/Counter Mode) ist ein AEAD-Chiffre – Authentifizierte Verschlüsselung mit zugehörigen Daten. Es führt zwei Dinge gleichzeitig aus:

1. Verschlüsselt Ihre Daten, sodass sie ohne den Schlüssel nicht lesbar sind
2. Erzeugt eine Authentifizierungs-Tag, sodass jede Manipulation sofort erkennbar ist

Ohne Authentifizierung kann ein Angreifer Bits in Ihrem Chiffretext ändern, und Sie entschlüsseln dann Unsinn, ohne es zu wissen. Mit GCM scheitert die Entschlüsselung laut, wenn der Chiffretext verändert wurde – bevor überhaupt ein Klartext zurückgegeben wird.

Der IV/Nonce: Zufällig, nie wieder verwendet

GCM erfordert eine Initialisierungsvektor (IV), auch bekannt als Nonce – „Zahl, die nur einmal verwendet wird“. Der IV muss nicht geheim sein, aber er muss:

• Zufällig — mit einem kryptografisch sicheren Zufallsgenerator generiert werden
• Einzigartig — nie mit dem gleichen Schlüssel wieder verwendet werden

Die Wiederholung eines IV mit dem gleichen Schlüssel in GCM ist katastrophal. Ein Angreifer, der zwei Chiffretexte mit dem gleichen Schlüssel und IV sieht, kann sie miteinander XORen und beide Klartexte wiederherstellen. Das ist nicht theoretisch – es ist in Produktionsystemen bereits passiert.

Verwenden Sie einen 96-Bit (12-Byte)-zufälligen IV pro Verschlüsselungsvorgang. Da Sie ihn für die Entschlüsselung benötigen, speichern Sie ihn neben dem Chiffretext – der IV wird konventionell vor dem Chiffretext platziert.

Funktionierender Code: AES-256-GCM

Hier sind fertige Snippets. Beide speichern den IV und den Authentifizierungs-Tag mit dem Chiffretext, sodass die Entschlüsselung selbstständig erfolgen kann.

Node.js

const crypto = require('crypto');

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

function encrypt(plaintext, key) {
  const iv = crypto.randomBytes(IV_LENGTH);
  const cipher = crypto.createCipheriv(ALGORITHM, key, iv);

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

  // Layout: [iv (12)] + [tag (16)] + [ciphertext]
  return Buffer.concat([iv, tag, encrypted]).toString('base64');
}

function decrypt(ciphertextB64, key) {
  const data      = Buffer.from(ciphertextB64, 'base64');
  const iv        = data.subarray(0, IV_LENGTH);
  const tag       = data.subarray(IV_LENGTH, IV_LENGTH + TAG_LENGTH);
  const encrypted = data.subarray(IV_LENGTH + TAG_LENGTH);

  const decipher = crypto.createDecipheriv(ALGORITHM, key, iv);
  decipher.setAuthTag(tag);

  return Buffer.concat([decipher.update(encrypted), decipher.final()]).toString('utf8');
}

// Usage
const key        = crypto.randomBytes(KEY_LENGTH); // store this securely
const ciphertext = encrypt('sensitive data here', key);
const plaintext  = decrypt(ciphertext, key);

Python

import os, base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

IV_LENGTH = 12  # 96 bits

def encrypt(plaintext: str, key: bytes) -> str:
    iv = os.urandom(IV_LENGTH)
    aesgcm = AESGCM(key)
    # encrypt() appends the 16-byte auth tag automatically
    ciphertext = aesgcm.encrypt(iv, plaintext.encode(), None)
    return base64.b64encode(iv + ciphertext).decode()

def decrypt(ciphertext_b64: str, key: bytes) -> str:
    data       = base64.b64decode(ciphertext_b64)
    iv         = data[:IV_LENGTH]
    ciphertext = data[IV_LENGTH:]
    aesgcm = AESGCM(key)
    return aesgcm.decrypt(iv, ciphertext, None).decode()

# Usage
key        = AESGCM.generate_key(bit_length=256)  # store this securely
ciphertext = encrypt('sensitive data here', key)
plaintext  = decrypt(ciphertext, key)

Installieren Sie die Abhängigkeit: pip install cryptography

Sie können AES-Verschlüsselung und -Entschlüsselung interaktiv testen – ohne jegliche Setup – mit dem IO Tools AES-Verschlüsselungs-/Entschlüsselungs-Tool.

Schlüsselverwaltung: Das schwere Teil

Ihre Verschlüsselung ist nur so stark wie Ihre Schlüsselverwaltung. Die häufigsten Fehler:

• Der Schlüssel befindet sich in derselben Datenbank wie die verschlüsselten Daten — wenn ein Angreifer Ihren Datenbankdump erhält, erhält er beide.
• Der Schlüssel wird in Quellcode eingebunden — selbst wenn er in einer git-ignorierten Datei ist .env, die Rotation wird schwierig und die Geschichte bleibt erhalten.
• Der Schlüssel erscheint in Protokollen — Anwendungssystemprotokolle werden an Aggregator übermittelt. Schlüssel sollten dort niemals auftauchen.

Wo Sie die Verschlüsselungsschlüssel tatsächlich speichern sollten:

• AWS KMS / Google Cloud KMS / Azure Key Vault — verwaltetes Schlüsselverwaltungssystem mit Audit-Protokollen und automatischer Rotation
• HashiCorp Vault — selbstbetrieben, gut für Multi-Cloud-Umgebungen
• Umgebungsvariablen — akzeptabel für niedrigsensible Workloads mit begrenztem Expositionsgrad

Für die Verschlüsselung von Datenfeldern ist die Standardmuster die Umhüllung: Erstellen Sie einen Datenverschlüsselungsschlüssel (DEK) pro Datensatz oder Spalte, und verschlüsseln Sie dann den DEK mit einem Master-Schlüssel, der in einem KMS gespeichert ist. Ihre Datenbank enthält nur verschlüsselte DEKs und Chiffretexte – der Master-Schlüssel berührt die Datenbank nie.

Wann sollte man AES verwenden – und wann nicht?

AES ist die richtige Lösung für:

• Die Verschlüsselung von Feldern in einer Datenbank — SSNs, Kartennummern, Gesundheitsdaten
• Die Verschlüsselung von Dateien bei Ruhezustand vor Cloudspeicherung
• Geheime Daten zwischen Diensten die einen vorab festgelegten Schlüssel teilen

AES ist nicht die richtige Lösung, wenn:

• Sie Daten über ein Netzwerk übertragen — verwenden Sie TLS. Bauen Sie keine eigene Transportschicht.
• Sie benötigen asymmetrische Verschlüsselung — wenn Sender und Empfänger kein gemeinsamer Schlüssel im Voraus teilen können, verwenden Sie RSA oder ECDH für Schlüsselaustausch.
• Sie speichern Passwörter — verwenden Sie bcrypt, scrypt oder Argon2. Verschlüsselte Passwörter können entschlüsselt werden; richtig gehashte Passwörter können nicht.
• Eine verwaltete Lösung passt — AWS Secrets Manager, Vault und ähnliche handeln Rotation, Zugriffskontrolle und Audit-Protokolle automatisch. Vorzuziehen, wenn sie Ihren Anforderungen entsprechen, statt manuelle AES zu verwenden.

Der häufigste Fehler, den Entwickler machen, ist, AES als vollständige Sicherheitslösung zu betrachten. Es ist ein Baustein – ein Grundbaustein. Paaren Sie es mit authentifizierter Modus (GCM), einzigartigen IVs pro Vorgang und richtiger Schlüsselverwaltung, und es ist äußerst effektiv. Verpassen Sie eines dieser Elemente und Sie haben etwas gebaut, das optisch sicher aussieht, aber nicht sicher ist.

Das könnte Ihnen auch gefallen