tools / aes
aes/
Symmetrische AES-Verschlüsselung und -Entschlüsselung. Modus, Padding, Format von Schlüssel und IV sowie Zeichensatz sind frei wählbar, die Ergebnisse stimmen mit Java und CryptoJS überein, und dein Schlüssel verlässt den Browser nie.
Klartext
Chiffretext
Verlauf
Nach jeder erfolgreichen Ver- oder Entschlüsselung wird automatisch ein Eintrag gespeichert. Die letzten 20 bleiben erhalten, ausschließlich im Browser dieses Geräts. Schlüssel werden nie gespeichert, IVs und entschlüsselter Klartext aber schon – leere den Verlauf daher, wenn du an einem öffentlichen Computer fertig bist.
AES, DES und RSA: Was sie sind und worin sie sich unterscheiden
AES und DES sind symmetrische Verfahren: Zum Ver- und Entschlüsseln dient derselbe Schlüssel, so wie ein Schlüssel eine Tür sowohl auf- als auch abschließt. Sie sind schnell und eignen sich für große Datenmengen; schwierig ist nur, den Schlüssel sicher zur Gegenseite zu bringen.
DES ist ein alter Standard aus den 1970er-Jahren mit nur 56 Bit effektiver Schlüssellänge. Mit spezieller Hardware oder Rechner-Clustern lässt er sich heute per Brute-Force knacken und taugt deshalb nur noch zur Anbindung von Altsystemen, die ihn weiter verwenden. AES hat DES als Standard abgelöst. Es nutzt Schlüssel mit 128, 192 oder 256 Bit, ist derzeit praktisch nicht angreifbar und die erste Wahl zum Verschlüsseln von Daten.
RSA ist asymmetrisch: Es gibt ein Schlüsselpaar. Den öffentlichen Schlüssel kann man an jeden weitergeben, er dient zum Verschlüsseln; den privaten Schlüssel behältst du für dich, mit ihm wird entschlüsselt – wie bei einem Briefkasten, in den jeder Briefe einwerfen kann, den aber nur du aufschließen kannst. Man muss vorab keinen gemeinsamen Schlüssel vereinbaren, dafür ist RSA langsam und kann pro Durchgang nur einige hundert Byte verschlüsseln. In der Praxis kombiniert man beides: RSA verschlüsselt einen zufällig erzeugten AES-Schlüssel für die Gegenseite, und AES verschlüsselt die eigentlichen Daten.
Was ist ein Verschlüsselungsmodus, und welchen soll ich wählen?
AES verschlüsselt immer nur 16 Byte auf einmal; der Modus legt fest, wie längere Daten in Blöcke zerlegt und wie die Blöcke miteinander verknüpft werden. ECB verschlüsselt jeden Block für sich, dadurch ergibt gleicher Inhalt gleichen Chiffretext und Muster werden sichtbar – nicht empfohlen. CBC verknüpft jeden Block vor dem Verschlüsseln mit dem vorherigen Chiffretextblock, den ersten mit dem IV; das ist die häufigste Wahl. CFB, OFB und CTR machen aus AES einen Schlüsselstrom, der Byte für Byte per XOR mit den Daten verknüpft wird, daher ist kein Padding nötig. GCM ergänzt CTR um ein Authentifizierungs-Tag: Wurde der Chiffretext verändert, schlägt die Entschlüsselung fehl. Heute ist GCM der empfohlene Modus.
Wofür sind IV und Padding da?
Der IV (Initialisierungsvektor) sorgt dafür, dass derselbe Inhalt bei jeder Verschlüsselung anders aussieht. Er muss nicht geheim sein und kann zusammen mit dem Chiffretext übertragen werden, darf aber mit demselben Schlüssel nie wiederverwendet werden – bei GCM gilt das besonders. Außer ECB brauchen alle Modi einen IV: Bei GCM werden 12 Byte empfohlen, bei allen anderen Modi müssen es genau 16 Byte sein.
ECB und CBC verlangen, dass die Datenlänge ein Vielfaches von 16 Byte ist; zu kurze Daten werden gemäß dem gewählten Padding aufgefüllt. PKCS5Padding und PKCS7Padding sind bei AES identisch und am weitesten verbreitet. ZeroPadding füllt mit Nullen auf und entfernt beim Entschlüsseln alle Null-Bytes am Ende – endet der Klartext selbst auf Null-Bytes, gehen auch sie verloren. NoPadding füllt nichts auf, die passende Länge musst du selbst sicherstellen. GCM braucht kein Padding.
Zuordnung zu Java und CryptoJS
Java: Cipher.getInstance("AES/CBC/PKCS5Padding") bedeutet CBC mit PKCS5Padding; bei nur "AES" gilt standardmäßig ECB mit PKCS5Padding. In Java funktionieren CTR und GCM nur mit NoPadding, und das GCM-Tag muss 96 bis 128 Bit lang sein. CryptoJS.pad.Pkcs7 in CryptoJS entspricht PKCS7Padding; ZeroPadding, AnsiX923, Iso10126 und Iso97971 heißen in beiden gleich. Übergibst du CryptoJS.AES.encrypt eine Passphrase als String, leitet es den Schlüssel selbst ab und liefert ein Ergebnis, das mit U2FsdGVkX1 beginnt; das wird hier nicht unterstützt – übergib stattdessen einen Schlüssel mit 16, 24 oder 32 Byte und einen IV.
Was sind GCM-Tag und AAD?
Das Tag ist der Prüfwert, den GCM berechnet; es bildet die letzten Bytes des Chiffretexts (bei 128 Bit sind das 16 Byte). AAD sind zusätzliche authentifizierte Daten, etwa ein Nachrichtenkopf. Sie werden nicht verschlüsselt, fließen aber in die Prüfung ein: Beim Entschlüsseln musst du genau dieselben AAD angeben, sonst schlägt die Prüfung fehl.
Häufige Fragen
Was tun bei „Der Schlüssel hat N Byte“ oder „Der IV hat N Byte“?
Prüfe zuerst, ob das Format stimmt: Dieselben 32 Zeichen sind im Format string 32 Byte, im Format hex aber nur 16 Byte. Ein AES-Schlüssel muss 16, 24 oder 32 Byte lang sein, und außer bei ECB und GCM muss der IV genau 16 Byte haben. Hier wird nichts automatisch mit Nullen aufgefüllt oder abgeschnitten; die aktuelle Byte-Zahl steht neben den Beschriftungen von Schlüssel und IV. Beim Format string richtet sich die Zahl nach dem gewählten Zeichensatz: Ein chinesisches Schriftzeichen belegt in UTF-8 3 Byte. Verarbeitet dein Backend das Passwort vorher, etwa durch Auffüllen mit Nullen oder Hashing, berechne zuerst die endgültigen Bytes und gib sie als hex oder base64 ein.
Was tun, wenn beim Entschlüsseln „ungültiges Padding“ gemeldet wird?
Das heißt, der zuletzt entschlüsselte Block entspricht nicht der gewählten Padding-Regel. Meist weicht einer der Parameter (Schlüssel, IV, Modus oder Padding) von dem ab, was beim Verschlüsseln verwendet wurde, oder der Chiffretext wurde nicht vollständig kopiert. Vergleiche jeden Parameter mit der verschlüsselnden Seite; auch ein falsches Schlüssel- oder Chiffretextformat (hex statt base64 oder umgekehrt) führt zu diesem Fehler. ZeroPadding und NoPadding prüfen das Padding nicht und melden diesen Fehler daher nie, bei falschen Parametern kommt dann aber Datenmüll heraus.
Der Anfang des entschlüsselten Texts ist unleserlich, oder es heißt, das Ergebnis sei kein gültiger UTF-8-Text
Prüfe zuerst den IV. Ist der Chiffretext länger als ein Block, verdirbt ein falscher IV bei CBC und CFB nur den ersten 16-Byte-Block; der Rest wird korrekt entschlüsselt und es erscheint kein Padding-Fehler – am Anfang steht also Zeichensalat, danach korrekter Text. Heißt es, das Ergebnis sei kein gültiger Text, kann auch der Zeichensatz vom Verschlüsseln abweichen, etwa weil die Gegenseite GBK verwendet hat. Stellst du das Ausgabeformat auf hex, kannst du zunächst prüfen, ob die entschlüsselten Bytes selbst stimmen.
Was tun, wenn die GCM-Entschlüsselung „Tag-Prüfung nicht bestanden“ meldet?
Das heißt, Schlüssel, IV, AAD oder Tag-Länge weichen vom Verschlüsseln ab, oder der Chiffretext wurde verändert. Hier werden die letzten Bytes der Eingabe als Tag behandelt, die Länge richtet sich nach der Option „Tag-Länge“ (standardmäßig 128 Bit, also 16 Byte). Chiffretext und Tag müssen deshalb zusammen eingegeben werden; bekommst du das Tag separat, hänge es zuerst an den Chiffretext an. Das AAD-Format ist standardmäßig hex – ändere es, wenn du einen Text als string einträgst. Wurden beim Verschlüsseln keine AAD verwendet, lass sie auch beim Entschlüsseln leer.
Das Ergebnis passt nicht zu Java, Python oder einem anderen Backend – wie finde ich den Fehler?
Prüfe der Reihe nach: Modus und Padding, Format und Byte-Zahl von Schlüssel und IV, Zeichensatz sowie Ein- und Ausgabeformat. Klartext im Format string wird nicht von Leerzeichen am Anfang und Ende bereinigt – schon ein zusätzlicher Zeilenumbruch am Ende ergibt andere Daten. CTR, CFB und OFB füllen hier ebenfalls nach dem gewählten Padding auf; mit PKCS5Padding ist der Chiffretext daher länger als der Klartext, und verwendet das Backend NoPadding, wähle auch hier NoPadding. CFB ist hier die Variante mit 128-Bit-Vollblock-Rückkopplung und passt daher nicht zu einem Backend mit CFB8.
Soll der Chiffretext hex oder base64 sein, und was passiert bei falscher Wahl?
Richte dich nach der Ausgabe der Gegenseite: Besteht der Text nur aus 0-9 und a-f, ist es hex; enthält er Groß- und Kleinbuchstaben, + oder / oder endet er auf =, ist es base64. Eine falsche Wahl beim Entschlüsseln führt nicht immer sofort zu einem Fehler, denn jedes Hex-Zeichen ist auch ein gültiges Base64-Zeichen; man erhält dann nur falsche Bytes, was sich später als „kein Vielfaches von 16“ oder als ungültiges Padding zeigt. Base64 mit - und _ (URL-sichere Form) oder mit fehlendem = wird erkannt, Leerzeichen, Doppelpunkte und ein 0x-Präfix in hex werden ignoriert.
Was speichert der Verlauf, und wird er hochgeladen?
Er liegt nur im localStorage des Browsers auf diesem Gerät und wird nie hochgeladen; der Seitencode stellt keinerlei Netzwerkanfragen. Nach jeder erfolgreichen Ver- oder Entschlüsselung kommt ein Eintrag dazu, höchstens 20 werden behalten, und Einträge, deren Eingabe oder Ergebnis über 20.000 Zeichen lang ist, werden nicht aufgezeichnet. Ein Eintrag enthält die Parameter, IV, AAD, Eingabe und Ergebnis sowie einen aus dem Schlüssel berechneten 8-stelligen Fingerabdruck (die Zeichen hinter dem # in jedem Eintrag, an denen man erkennt, ob es derselbe Schlüssel ist), aber nie den Schlüssel selbst. Nach einem Klick auf „Übernehmen“ musst du den Schlüssel also erneut eingeben. Jeder Eintrag lässt sich einzeln löschen; an einem öffentlichen Computer klickst du nach der Nutzung auf „Verlauf leeren“.
Kann ich einen zufälligen Schlüssel oder IV automatisch erzeugen lassen?
Nein. Es gibt keinen Button zum Erzeugen, Schlüssel und IV gibst du selbst ein. Gleicher Klartext, Schlüssel, IV und gleiche Parameter liefern immer dasselbe Ergebnis; nur beim ISO10126-Padding werden Zufallsbytes beigemischt, sodass sich das Ergebnis ändert. Brauchst du Zufallswerte, erzeuge sie selbst – zum Beispiel gibt openssl rand -hex 16 auf der Kommandozeile 16 Byte aus, die du mit dem Format hex eintragen kannst.