AES-256 Verschlüsselung

AES (Advanced Encryption Standard) ist ein weit verbreiteter symmetrischer Verschlüsselungsstandard. „Symmetrisch“ bedeutet: derselbe Schlüssel wird zum Verschlüsseln und Entschlüsseln verwendet. AES-256 bezeichnet dabei eine Schlüssellänge von 256 Bit. In realen Systemen entsteht Sicherheit jedoch nicht allein durch „AES-256“, sondern durch die korrekte Wahl des Betriebsmodus, saubere Nonce/IV-Regeln, solides Key-Management und ein konsequentes Fehler- und Betriebsmodell.

Das Wichtigste in 60 Sekunden

• Nimm AEAD (praktisch: AES-GCM) statt „AES-256 irgendwie“.
• Nonce/IV darf nie wiederverwendet werden – bei GCM ist Nonce-Reuse fatal.
• Auth-Tag immer prüfen und bei Fehler sofort abbrechen (keine Teil-Ausgaben, kein „trotzdem weiter“).
• Keys niemals im Code; nutze KMS/Vault/DPAPI/HSM und plane Rotation.
• Speichere Metadaten sauber: Algorithmus/Version, Key-ID, Nonce, Tag, AAD-Kontext, Ciphertext.

Was muss gespeichert werden?

Damit eine verschlüsselte Nachricht später zuverlässig entschlüsselt werden kann (und zwar ohne Sicherheitslücken), brauchst du ein klares, versioniertes Speicherformat. Die eigentliche „AES-256“-Bitlänge ist nur ein Detail; entscheidend ist, dass Nonce, Tag und Kontext korrekt und eindeutig bleiben.

Feld	Warum es nötig ist	Typische Größe/Beispiel
version	Damit du später Formate ändern kannst, ohne Daten zu verlieren.	z. B. 1
alg	Damit klar ist, wie entschlüsselt werden muss.	AES-256-GCM
keyId	Damit du den passenden Schlüssel (oder KEK im KMS) findest.	UUID/ARN/Name
nonce / iv	Für GCM zwingend erforderlich; muss pro Key/Message unique sein.	typisch 12 Bytes
ciphertext	Die verschlüsselten Nutzdaten.	variabel
tag	Integrität/Authentizität; ohne korrektes Tag keine Entschlüsselung.	typisch 16 Bytes
aadInfo	Kontext, der „mit-authentifiziert“ wird (z. B. User-ID, Zweck, Tenant, Schema-Version).	variabel

Wichtig: Nonce und Tag sind keine „Optionen“. Wenn du sie verlierst, ist die Entschlüsselung unmöglich – und wenn du Nonces wiederverwendest, kann die Sicherheit komplett brechen.

Die häufigsten Fehler (und wie du sie vermeidest)

„Ich hab AES-256, also bin ich sicher“

AES ist nur die Blockchiffre. Ohne sicheren Modus, korrekte Nonce und Key-Management ist das keine robuste Lösung. Praktisch heißt das: AES-GCM (AEAD), Tag prüfen, Key sauber verwalten.

Nonce/IV wird aus Versehen wiederverwendet

Bei GCM ist Nonce-Reuse besonders gefährlich. Nimm entweder Counter/Sequenz pro Key oder sehr kontrollierte Random-Nonces mit Kollisionsschutz. Trenne Keys pro Kontext (Tenant/Service) und rotiere.

Auth-Tag wird ignoriert

Wenn das Tag nicht stimmt, ist die Nachricht kompromittiert oder falsch. Der einzig richtige Umgang: abort. Kein „best effort“, kein „Teil-Parse“ vorher.

Schlüssel liegt im Code oder in Config

Keys gehören in KMS/Vault/HSM/DPAPI und müssen rotierbar sein. Ein Leak in Git oder Logs ist sonst ein Totalschaden.

Was AES-256 konkret leistet

AES verschlüsselt Datenblöcke mit 128 Bit Blockgröße. Die Schlüssellänge (128, 192 oder 256 Bit) beeinflusst die Schlüsselsuche (Brute Force) in der Theorie, aber in der Praxis sind Implementierung und Betriebsmodus meist der entscheidendere Faktor. Ein starker Algorithmus schützt nur dann, wenn Schlüssel geschützt sind und Integrität sowie Nonce-Regeln korrekt umgesetzt werden.

Betriebsmodi: warum „AES-256“ ohne Modus nicht aussagekräftig ist

AES ist ein Blockcipher. Um beliebig lange Daten zu verschlüsseln, wird ein Betriebsmodus verwendet. Der Modus bestimmt, wie aus AES-Blockoperationen ein Verfahren für Streams, Dateien oder Nachrichten entsteht. Ein häufiger Fehler ist, nur „AES-256“ zu nennen, ohne den Modus zu definieren. Für moderne Anwendungen ist ein AEAD-Verfahren (Authenticated Encryption with Associated Data) meist die beste Wahl.

AES-GCM (AEAD): Standardwahl mit klaren Regeln

GCM kombiniert Verschlüsselung mit einer Authentifizierung (Tag). Das Tag stellt sicher, dass Manipulationen erkannt werden. Wenn das Tag nicht passt, muss die Entschlüsselung fehlschlagen (fail closed). GCM benötigt zusätzlich eine Nonce (häufig 12 Byte). Die wichtigste Regel: pro Schlüssel darf eine Nonce niemals wiederverwendet werden. Wiederverwendung kann Sicherheit brechen.

Nonce/IV: Eindeutigkeit zuverlässig garantieren

„Nonce eindeutig“ klingt einfach, ist aber ein Betriebskriterium. In verteilten Systemen (mehrere Instanzen/Threads/Pods) muss die Nonce-Erzeugung so gestaltet sein, dass es auch unter Parallelität, Retries und Restarts nicht zu Kollisionen kommt.

• Zufällige Nonces: geeignet, wenn eine kryptografisch sichere Zufallsquelle genutzt wird und das Volumen nicht extrem ist.
• Counter-basierte Nonces: pro Schlüssel ein monotoner Zähler; kollisionsfrei, benötigt aber atomare Persistenz.
• Partitionierung: Nonce kann aus (nodeId + counter) bestehen, damit mehrere Nodes disjunkte Bereiche nutzen.
• Retries: ein Retry darf nicht „halb“ wiederholen. Entweder idempotent dieselbe Operation wiederholen oder bewusst neu verschlüsseln (dann neue Nonce und neuer Ciphertext).

AAD: Metadaten manipulationssicher binden

Additional Authenticated Data (AAD) wird nicht verschlüsselt, aber in die Authentifizierung einbezogen. Dadurch werden Metadaten, die später unverändert sein müssen, an den Ciphertext gebunden.

Key-Management: der Punkt, an dem Projekte gewinnen oder verlieren

Schlüssel dürfen nicht im Quellcode oder in Repositories stehen, nicht in Clients eingebaut werden und nicht in Logs/Telemetry landen. Professionelle Umsetzungen trennen Daten und Schlüssel und nutzen Secret Stores, KMS/HSM, Rollenmodelle und Audits.

• Keine Hardcodes: Schlüssel nicht in Code, nicht in Konfig-Repos, nicht im Frontend.
• Least Privilege: Dienste erhalten nur die minimal nötigen Key-Rechte.
• Rotation: geplanter Wechsel von Keys inklusive Migrationspfad.
• Auditierbarkeit: Key-Nutzung nachvollziehbar, ohne Key-Material zu loggen.

Envelope Encryption: skalierbares Muster

Konzept: 1) dataKey = random(32 bytes) 2) nonce = random/unique (z.B. 12 bytes) 3) ciphertext, tag = AES-GCM(dataKey, nonce, plaintext, aad) 4) wrappedKey = KMS.Wrap(masterKeyId, dataKey) 5) speichern: version + alg + keyId + wrappedKey + nonce + ciphertext + tag + aadMeta

Do & Don’t

Threat Model

• Offline-Zugriff: Data-at-Rest + Key Separation.
• Manipulation: AEAD/TLS, fail closed.
• Berechtigungen: Autorisierung + Audits.
• Prozess kompromittiert: zusätzliche Isolation/Monitoring.

Praxisbeispiele

.NET (AesGcm)

using var gcm = new System.Security.Cryptography.AesGcm(key); gcm.Encrypt(nonce, plaintext, ciphertext, tag, aad); gcm.Decrypt(nonce, ciphertext, tag, plaintext, aad);

Java (JCA)

Cipher c = Cipher.getInstance("AES/GCM/NoPadding"); GCMParameterSpec spec = new GCMParameterSpec(128, nonce); c.init(Cipher.ENCRYPT_MODE, key, spec); c.updateAAD(aad); byte[] out = c.doFinal(plaintext);

Rotation & Migration

- read: decrypt(keyId aus Metadaten) - write: encrypt(activeKeyId) - optional: re-encrypt bei Zugriff

Fehlerbehandlung

Bei Integritätsfehlern keine Teilresultate. Fehlermeldungen ohne sensible Details. Bei CBC/CTR nur mit MAC, Oracles vermeiden.

Operative Sicherheit

• Logs: keine Keys/Nonces/Tags/Klartext.
• Crashdumps: Zugriff einschränken.
• Secrets: Secret Store/KMS.

Tests

• Roundtrip
• Tag-Manipulation
• AAD-Manipulation
• Metadaten-Validation
• Parallelität/Nonce-Kollisionen

Vertiefung: Datenmodelle, Serialisierung und Grenzfälle

In vielen Anwendungen werden verschlüsselte Daten serialisiert (JSON/Protobuf/DB-Felder). Hier passieren Fehler: falsche Base64-Decodes, verlorene Bytes, unklare Felder oder stille Trunkierung. Ein robustes Schema definiert: welche Felder sind Bytes, welche sind Text, und welche Validierungen müssen vor dem Decrypt passieren. Vor allem gilt: Längen prüfen (Nonce/Tag), Versionen prüfen und nur bekannte Algorithmen akzeptieren.

• Bytes vs. Text: Ciphertext/Tag/Nonce sind Bytes. Base64 ist nur Transportdarstellung.
• Input Validation: vor Decrypt prüfen: Mindestlängen, Version, Alg-ID, expected tag length.
• Replay/Copy-Paste: AAD so wählen, dass Ciphertexte nicht in andere Kontexte verschoben werden können.
• Key Separation: unterschiedliche Keys für unterschiedliche Zwecke (z.B. Daten vs. Token) vermeiden Seiteneffekte.