AES-Verschlüsselung / -Entschlüsselung — GCM, CBC, CTR und ECB im Browser
AES-Verschlüsselung / -Entschlüsselung
Verschlüsseln oder entschlüsseln Sie mit AES-128, AES-192 oder AES-256 (FIPS 197) im Modus GCM (authentifizierte Verschlüsselung), CBC, CTR oder ECB. Schlüssel sind Rohbytes als Hex oder Base64 oder werden aus einem Passwort mit PBKDF2-HMAC-SHA256 abgeleitet. GCM unterstützt AAD und zeigt das Authentifizierungs-Tag gesondert an; die Ausgaben von CBC, CTR und ECB sind mit openssl enc kompatibel. Für Hashes siehe den Hash-Generator, für Message Authentication Codes den HMAC-Generator, für ältere Chiffren die Seite Legacy-Chiffren dieser Reihe. Alles läuft lokal — Schlüssel und Klartext verlassen Ihren Tab nie. Dateien bis 200 MB.
Alles, was Sie hier eingeben, bleibt in diesem Tab — das bedeutet aber nicht „sicher für produktive Geheimnisse“. Der Browserspeicher, Erweiterungen und neugierige Blicke sehen, was Sie einfügen. Nutzen Sie diese Seite zum Lernen, Prüfen und Abgleichen, nicht zum Verarbeiten echter Kundendaten.
Richtung:Modus:Ausgabe:
GCM = AES-GCM mit 12-Byte-Nonce und 128-Bit-Authentifizierungs-Tag (AEAD: Vertraulichkeit + Integrität). Der Standard, wenn Sicherheit das Ziel ist.
Schlüssel(Rohbytes: 16, 24 oder 32 Byte = AES-128/192/256; die Länge des Eingefügten bestimmt den Wert)
Hex verträgt Leerzeichen, Doppelpunkte und 0x-Präfixe.
Salt (Hex, 8–16 Byte):
Iterationen:Schlüsselgröße:
Das Salt wird zusammen mit dem Chiffretext übertragen — wer entschlüsselt, braucht dasselbe Passwort, Salt, dieselbe Iterationszahl und Schlüsselgröße. OWASP empfiehlt mindestens 600.000 PBKDF2-HMAC-SHA256-Iterationen.
IV / Nonce(GCM: 12 Byte; CBC/CTR: 16 Byte — Hex)
Verwenden Sie bei GCM oder CTR niemals dieselbe Nonce mit demselben Schlüssel.
AAD(zusätzlich authentifizierte Daten — authentifiziert, aber nicht verschlüsselt; optional)
Tag-Länge:
Authentifizierungs-Tag(Hex, wie diese Seite es beim Verschlüsseln ausgibt — zum Entschlüsseln erforderlich)
Plaintext text (the data to encrypt, UTF-8 encoded)
Datei auswählen oder hier per Drag & Drop ablegen Die Datei wird lokal in 8 MB großen Blöcken gelesen; nichts wird hochgeladen. Bis zu 200 MB.
Ciphertext (eine Zeile: Modus, Schlüsselgröße, Wert; Parameter in den Zeilen darunter)
Die Parameterzeilen halten den genauen Schlüsselwert, den IV, die AAD-Größe und das Tag fest, sodass sich ein kopiertes Ergebnis auf jedem anderen Rechner reproduzieren lässt.
Welchen Modus soll ich wählen? GCM ist die Standardantwort: Es verschlüsselt und authentifiziert — die Tag-Zeile macht Manipulationen erkennbar (entschlüsseln Sie mit einem gekippten Tag-Byte, verweigert die Seite die Arbeit). CBC verbirgt Blockmuster, bietet aber keine Integrität; kombinieren Sie es mit einem HMAC (siehe HMAC-Generator), wenn Sie es verwenden müssen. CTR macht AES zur Stromchiffre — keine Auffüllung, aber eine wiederverwendete Nonce mit demselben Schlüssel ist sowohl bei CTR als auch bei GCM katastrophal. ECB ist hier nur zur Kompatibilität und zu Lehrzwecken: Gleiche Klartextblöcke ergeben gleiche Chiffretextblöcke (der berühmte ECB-Pinguin).
OpenSSL-Kompatibilität — CBC- und CTR-Ausgaben dieser Seite (PKCS#7-Auffüllung, Rohschlüssel) lassen sich mit dem Befehl openssl enc hin- und zurückrechnen: openssl enc -aes-256-cbc -K <64-Hex-Schlüssel> -iv <32-Hex-IV> -in msg.txt -out msg.enc openssl enc -d -aes-256-cbc -K <Schlüssel> -iv <IV> -in msg.enc -out msg.txt Dasselbe funktioniert mit -aes-128-cbc, -aes-192-cbc, -aes-256-ctr (16-Byte-IV = Startzählerblock). Beachten Sie: openssl enc unterstützt kein GCM — verwenden Sie für authentifizierte Verschlüsselung diese Seite oder openssl aesgcm ab OpenSSL 3.3.
Stattdessen das chinesische nationale Verschlüsselungsverfahren? SM4 (GB/T 32907-2016) — die in der chinesischen kommerziellen Kryptografie vorgeschriebene Blockchiffre mit derselben 128-Bit-Blockgröße und Schlüssellänge wie AES, aber eigenem Schlüsselplan und eigener S-Box — läuft auf einer eigenen Seite im ECB- und CBC-Modus: SM4-Verschlüsselung / -Entschlüsselung. Die übrige SM-Reihe findet sich dort ebenfalls: SM3 (Hash), SM2 (Public-Key) und SM9 (identitätsbasierte Kryptografie).
Selbsttest Führt die Engines der Seite gegen unabhängige Anker aus: Known-Answer-Vektoren für alle vier Modi (von einer unabhängigen nativen Implementierung erzeugt), GCM-Tag-Vektoren mit und ohne AAD, Kreuzprüfungen der WebCrypto-Engine gegen die reine JavaScript-AES-Engine, GCM-Hin-und-zurück sowie Negativtests (manipuliertes Tag und falscher Schlüssel müssen fehlschlagen). Es wird nichts gesendet.
AES von Grund auf erklärt
In einem Satz: AES ist die weltweit genormte Blockchiffre — sie verwürfelt 16-Byte-Blöcke unter einem 128-, 192- oder 256-Bit-Schlüssel. Der Modus, in dem Sie sie betreiben (GCM, CBC, CTR, ECB), bestimmt, wie die Blöcke verkettet werden, wofür der IV dient und ob Manipulationen erkennbar sind. Wählen Sie GCM, sofern Sie keinen Grund dagegen haben.
Was AES selbst ist (FIPS 197)
Die Blockchiffre. AES (das Rijndael-Verfahren, 2001 vom NIST als FIPS 197 genormt) verschlüsselt genau 16 Byte auf einmal. Die Schlüssellänge — 16, 24 oder 32 Byte — wählt AES-128, -192 oder -256 und die Anzahl interner Runden (10, 12 bzw. 14). Jede Runde mischt den Block mit aus Ihrem Schlüssel abgeleiteten Rundenschlüsseln, durch Substitutionstabellen, Zeilenverschiebungen und Spaltenmischungen. Kein praktischer Angriff bricht die Chiffre selbst: Die realen Fehler liegen fast immer beim Modus, beim IV oder bei der Schlüsselverwaltung — darum geht es im Rest dieser Seite.
Warum überhaupt ein Modus? Weil Nachrichten selten genau 16 Byte lang sind. Der Modus verbindet die Blockverschlüsselungen: ECB verschlüsselt Blöcke unabhängig voneinander; CBC verknüpft jeden Block per XOR mit dem vorherigen Chiffretextblock; CTR verschlüsselt einen Zähler und verknüpft ihn wie eine Stromchiffre mit den Daten; GCM baut auf CTR auf und fügt ein Authentifizierungs-Tag hinzu. AES bleibt gleich — der Modus ändert alles an den Garantien, die Sie erhalten.
Schlüssel und Passwörter. Ein AES-Schlüssel sind 16, 24 oder 32 zufällige Byte. Ein menschliches Passwort ist das nicht: Die Passwortoption dieser Seite leitet mit PBKDF2-HMAC-SHA256 einen geeigneten Schlüssel ab (Standard 600.000 Iterationen, die OWASP-Basis von 2023 — Einzelheiten zur Schlüsselableitung im HMAC-Generator). Verwenden Sie niemals einen Passwortstring direkt als AES-Schlüssel: Seine Entropie ist nur ein kleiner Bruchteil seiner Länge.
Die vier Modi im Vergleich
Modus
IV / Nonce
Integrität
Hinweise
GCM
12 Byte, pro Nachricht eindeutig
Ja — Tag mit 96 bis 128 Bit
AEAD: überall der empfohlene Standard (TLS 1.3, SSH, Dateiformate). Akzeptiert außerdem AAD.
CBC
16 Byte, nicht vorhersagbar
Nein
PKCS#7-Auffüllung; klassisch, benötigt aber ein MAC daneben. Padding-Oracle-Fehler sind die klassische CBC-Falle.
CTR
16 Byte Startzähler
Nein
Keine Auffüllung, Stromchiffre-artig, wahlfreier Zugriff; Wiederverwendung der Nonce mit demselben Schlüssel gibt Klartext XOR Klartext preis.
ECB
keine
Nein
Gleiche Blöcke ergeben gleichen Chiffretext. Die ECB-Pinguin-Demonstration. Nur zur Kompatibilität.
IV-Regeln in einem Absatz. Der IV ist kein Geheimnis — übertragen Sie ihn zusammen mit dem Chiffretext —, aber seine Eindeutigkeitsregeln unterscheiden sich: CBC braucht einen nicht vorhersagbaren IV; GCM und CTR verlangen nur, dass dieselbe Nonce mit demselben Schlüssel nie wiederverwendet wird (bei GCM ist die Wiederverwendung noch schlimmer: sie gibt den Authentifizierungsschlüssel preis). Die Schaltfläche „Zufalls-IV“ nutzt den sicheren Zufallsgenerator des Browsers; „Alles Nullen“ dient nur der Reproduktion von Testvektoren, nicht echten Nachrichten.
Auffüllung. CBC und ECB benötigen volle Blöcke; die PKCS#7-Auffüllung hängt daher 1 bis 16 Byte an, deren Wert jeweils der Länge der Auffüllung entspricht. Deshalb wachsen CBC-Chiffretexte um bis zu 16 Byte, und die Entschlüsselung mit dem falschen Schlüssel scheitert meist mit einem Auffüllungsfehler. CTR und GCM arbeiten als Stromchiffre und brauchen keine Auffüllung — die Länge des Chiffretexts entspricht genau der des Klartexts (probieren Sie das Beispiel im CTR-Modus aus: 43 Byte hinein, 43 Byte heraus).
CFB und OFB (die beiden übrigen klassischen Modi) sind auf dieser Seite nicht implementiert: Sie arbeiten wie CTR als Stromchiffre, bieten aber keinen Vorteil dagegen und bestehen heute vor allem in älteren Protokollen fort.
Was GCM hinzufügt (AEAD, Tags, AAD)
Authentifizierte Verschlüsselung. GCM = CTR-Verschlüsselung plus ein GHASH-Authentifizierer über Chiffretext, IV und AAD. Das Ausgabe-Tag ist ein Fingerabdruck von allem: Ändert man ein einziges Bit von Chiffretext, IV oder AAD, passt das Tag nicht mehr, sodass der Empfänger nachweisen kann, dass die Nachricht unverändert ist und von einem Schlüsselinhaber stammt. CBC+HMAC erreicht dasselbe nur, wenn man es richtig kombiniert (Encrypt-then-MAC) — GCM ist dies von vornherein richtig.
AAD. Zusätzliche authentifizierte Daten werden im Klartext übertragen, sind aber durch das Tag abgedeckt: Protokollkopfzeilen, Dateinamen, Algorithmenkennungen. Der Empfänger muss exakt dieselben AAD-Bytes angeben, sonst schlägt die Tag-Prüfung fehl — genau das ist der Zweck.
Tag-Länge. Das Standard-Tag mit 128 Bit wird empfohlen; kürzere Tags (96 bis 120 Bit) tauschen Fälschungssicherheit gegen Größe. Unter 96 Bit verschlechtern sich die Sicherheitsbeweise von GCM rasch, weshalb diese Seite dort aufhört.
Die Nonce-Katastrophe. Wird eine 12-Byte-GCM-Nonce mit demselben Schlüssel wiederverwendet, verrät das die XOR-Verknüpfung der beiden Klartexte und den Authentifizierungs-Teilschlüssel — danach sind Fälschungen für alle künftigen Nachrichten unter diesem Schlüssel möglich. Systeme, die Eindeutigkeit nicht garantieren können, verwenden Varianten, die Nonce-Missbrauch widerstehen (AES-GCM-SIV, RFC 8452).
Ankerwerte — auf dieser Seite nachvollziehen
Die erste Zeile ist das bekannte Einzelblock-Beispiel aus FIPS 197; die übrigen wurden von einer unabhängigen nativen Implementierung (OpenSSL über Node.js) erzeugt und auf den Engines dieser Seite erneut geprüft. Fügen Sie Schlüssel, IV und Eingabe in die Seite ein, um jede Zeile nachzuvollziehen.
Fall
Eingaben
Erwartete Ausgabe
AES-128 einzelner Block (im Stil von FIPS 197)
key 000102..0f, plaintext 00112233..ff
69c4e0d86a7b0430d8cdb78070b4c55a
AES-128-GCM
key 000102..0f, IV 606162..6b, plaintext 0011..ef ×2
ct 275f095bedfda377063fee326128892188377b410698ed03a022b9971bb4bdbe, tag 87ea7770714048977de2fd8dac645ecf
AES-256-GCM, gleich, aber mit AAD deadbeef
key 000102..1f
ct eacab966ff15e518f48f5390be502fbc2756ccee0dcfff36a282c50bf5593ae7, tag aead900e895c88252d0388d7aefce5c8
AES-256-CBC
key 000102..1f, IV 101112..1f, plaintext 0011..ef ×2
ECB verwenden, weil kein IV nötig ist. Die Bequemlichkeit ist die Falle: Blockmuster bleiben im Chiffretext erhalten (verschlüsseln Sie eine Bitmap, und das Bild bleibt sichtbar). ECB ist nur für einzelne Blöcke oder genau 16 Byte lange Zufallsschlüssel akzeptabel — in der Praxis sollte man es bewusst nicht verwenden.
Nonce/IV wiederverwenden. Bei GCM oder CTR mit demselben Schlüssel ist dies der eine Fehler, der alles auf einmal zerstört. Zählerbasierte Systeme (wie die Schaltfläche „Zufalls-IV“ dieser Seite) existieren, um ihn unmöglich zu machen.
Den IV für geheim halten. Ist er nicht. Speichern oder übertragen Sie ihn zusammen mit dem Chiffretext. Ihn zu verbergen bringt nichts und verleitet nur zur Wiederverwendung.
Ein Passwort direkt als Schlüssel verwenden."hunter2hunter2hunter2hunter2" hat 32 Byte, aber nicht 256 Bit Entropie — es ist ein Wörterbuchwort mit Auffüllung. Leiten Sie den Schlüssel mit PBKDF2 ab (auf dieser Seite integriert) oder erzeugen Sie einen Zufallsschlüssel.
Annehmen, CBC erkenne Manipulationen. Kippt man in CBC-Chiffretext ein Bit, „gelingt“ die Entschlüsselung und liefert stillschweigend verfälschten Klartext. Nur das GCM-Tag (oder ein explizites HMAC) macht Manipulationen sichtbar.
GCM-Chiffretexte auf Gleichheit vergleichen. Bei zufälligen Nonces wird derselbe Klartext jedes Mal anders verschlüsselt — das ist gewollt. Deterministische Verschlüsselung ist ein anderes, spezielles Werkzeug.
FAQ
Ist AES-128 noch sicher, oder brauche ich 256? Beide sind gegen realistische Angreifer sicher; die bekannten Angriffe verringern den Sicherheitsabstand nur geringfügig. AES-256 ist vor allem für langfristig geheime Daten und zur Absicherung gegen Quantencomputer relevant (der Grover-Algorithmus halbiert die Schlüsselstärke, sodass AES-256 etwa 128 Bit entspricht).
Warum kann openssl enc kein GCM? Der Befehl enc ist älter als AEAD und kann kein Tag transportieren; OpenSSL 3.3 hat dafür einen eigenen Befehl aesgcm eingeführt. Die GCM-Ausgabe dieser Seite führt das Tag in einer eigenen Zeile, damit Sie beides gezielt verschieben können.
Was ist Schlüsselumhüllung (AES-KW)? Ein spezieller Modus, um andere Schlüssel in festen 64-Bit-Blöcken zu verschlüsseln, mit eigener Integritätsprüfung. Er wird hier nicht angeboten, weil Ein- und Ausgaben schlüsselartig und nicht nachrichtenartig sind — Fehlanwendung ist dabei der Normalfall.
Warum ist mein CTR-Chiffretext so lang wie der Klartext, der CBC-Text aber länger? CTR und GCM arbeiten wie Stromchiffren (keine Auffüllung); CBC und ECB füllen mit PKCS#7 auf einen vollen 16-Byte-Block auf. Der Längenunterschied ist beabsichtigt, kein Fehler.
Kann ich etwas entschlüsseln, das woanders verschlüsselt wurde? Ja, wenn Sie Modus, Schlüssel, IV (und bei GCM das Tag) genau kennen. Die Ausgabezeilen dieser Seite halten all das genau fest, sodass Sie Parameter zwischen Werkzeugen übertragen können — der OpenSSL-Kasten oben zeigt die passenden Befehlszeilen.
