AES-Verschlüsselung — Text sicher im Browser verschlüsseln

Was macht dieses Tool genau?

Du gibst einen Klartext und eine Passphrase ein, das Tool verschlüsselt beides mit AES — symmetrisch, das heißt Verschlüsseln und Entschlüsseln teilen sich denselben Schlüssel. Im Decrypt-Modus drehst du den Vorgang um. Beides läuft vollständig im Browser über die Web Crypto API, eine standardisierte Schnittstelle, die jeder moderne Browser seit etwa 2015 bereitstellt. Kein Server-Roundtrip, kein Konto, kein Tracking. Du kannst die Seite offline laden (PWA) und die Funktion arbeitet weiter.

Ausgabe als Base64 (kompakter, gut für Mail/Chat) oder Hex (gut für Logs und Debug-Vergleiche). Der Output enthält drei Teile direkt hintereinander: das zufällige Salt für die Schlüsselableitung, das zufällige Initialisierungs-Vektor (IV), und den eigentlichen Ciphertext. Das Output-Layout ist explizit dokumentiert, sodass du den Ciphertext auch mit OpenSSL, Python oder jedem anderen AES-fähigen Stack entschlüsseln kannst.

Warum überhaupt Browser-AES und nicht ein Online-Tool?

Drei der bekanntesten Online-AES-Tools — aesencryption.net, encryption-decryption.online, devglan.com — nehmen deinen Klartext und deine Passphrase entgegen und schicken beides per HTTPS-POST an einen Server. Der Server verschlüsselt und schickt den Ciphertext zurück. Das ist absurd: eine Cipher, deren Sinn die Geheimhaltung des Klartexts ist, leakt den Klartext an einen fremden Server, bevor sie überhaupt rechnet. HTTPS schützt die Verbindung, aber nicht den Server-Operator, nicht die Cloud-Provider-Logs, nicht den potentiellen Angreifer mit Server-Zugriff.

Browser-AES dreht das um: dein Klartext und deine Passphrase bleiben im JavaScript-Kontext des Browser-Tabs. Sie werden durch die crypto.subtle-API verschlüsselt, die direkt im Browser-Engine läuft — der gleiche Code, den der Browser für TLS-Handshakes nutzt. Output: der Ciphertext erscheint im Tab. Du kopierst ihn, leitest ihn weiter, der Klartext liegt nie woanders.

Welche Algorithmen bietet das Tool und warum genau diese drei?

AES-256-GCM ist Standard und Empfehlung. AES (Advanced Encryption Standard) ist seit 2001 NIST-zertifiziert (FIPS 197) und gilt als ungebrochen — keine bekannte praktische Methode reduziert die effektive Schlüsselstärke unter die Brute-Force-Grenze. Mit 256-Bit-Schlüssel ist es selbst gegen Quantencomputer-Angriffe per Grover-Algorithmus noch komfortabel (effektive Sicherheit halbiert sich auf 128 Bit). GCM (Galois/Counter Mode) liefert zusätzlich einen Authentifikations-Tag — Manipulationen am Ciphertext werden beim Entschlüsseln erkannt. Spezifikation: NIST SP 800-38D.

AES-128-GCM ist die schnellere Variante mit 128-Bit-Schlüssel. Cryptographisch immer noch stark; sinnvoll, wenn die Performance auf alter Hardware oder im Embedded-Kontext zählt. Für die meisten Browser-Use-Cases ist der Geschwindigkeits-Unterschied vernachlässigbar.

AES-256-CBC ist der klassische Modus ohne Authentifikations-Tag. PKCS#7-Padding sorgt dafür, dass beliebige Klartext-Längen verschlüsselt werden können. Wichtiger Hinweis im Tool: CBC erkennt Manipulationen am Ciphertext NICHT. Wenn jemand ein Bit umlegt, entschlüsselt es zu Müll, ohne Fehler zu werfen — gefährlich bei Daten, die ohne Prüfsumme weiterverarbeitet werden. Wir bieten CBC nur an, weil viele Legacy-Systeme (alte Java-Apps, manche IoT-Firmwares) ausschließlich CBC unterstützen. Für neue Daten: GCM bevorzugen.

Was wir bewusst nicht anbieten: AES-ECB (Electronic Codebook). ECB ist kryptographisch gebrochen, weil identische Klartext-Blöcke identischen Ciphertext produzieren. Das macht Muster im Klartext sichtbar — der berühmte ECB-Pinguin demonstriert es: ein per ECB verschlüsseltes Bild zeigt die Silhouette des Originals. Andere Online-Tools bieten ECB als Option an, oft sogar als Standard — wir blocken es hard.

Wie funktioniert PBKDF2 und warum brauche ich das?

Eine Passphrase ist kein Schlüssel. Eine typische Passphrase hat 20–40 Bit Entropie, AES braucht 128 oder 256 Bit. Die Lücke schließt eine Key Derivation Function (KDF) — sie streckt die Passphrase auf die volle Schlüssel-Länge und macht Brute-Force durch viele wiederholte Hash-Operationen teuer.

Wir nutzen PBKDF2 mit SHA-256 als Hash-Funktion und 100.000 Iterationen. Das ist die OWASP-2024-Mindestempfehlung für PBKDF2-HMAC-SHA-256. Jeder Verschlüsselungs-Vorgang generiert ein zufälliges 16-Byte-Salt, das mit dem Ciphertext zusammen gespeichert wird. Salt verhindert Rainbow-Table-Angriffe: zwei Nutzer mit derselben Passphrase erhalten unterschiedliche Schlüssel.

Es gibt modernere KDFs — Argon2 (gewinner des Password Hashing Competition 2015), scrypt (memory-hard) — die gegen GPU-Brute-Force noch resistenter sind. Browser-Web-Crypto unterstützt Argon2 bisher nicht nativ; das müsste über WebAssembly nachgerüstet werden, was unsere Zero-Dependency-Linie bricht. PBKDF2 mit 100.000 SHA-256-Iterationen ist für Educational-Use ausreichend.

Was steht in dem Output-Blob wirklich drin?

Der Ciphertext-Output ist eine Aneinanderreihung von drei Komponenten, Base64- oder Hex-codiert:

[Salt:16 Byte][IV:12 Byte für GCM, 16 Byte für CBC][Ciphertext (+16 Byte Auth-Tag bei GCM):variabel]

Beim Entschlüsseln liest das Tool die ersten 16 Bytes als Salt, die nächsten 12 (oder 16 bei CBC) als IV, und behandelt den Rest als Ciphertext + optionaler Auth-Tag. Diese Layout-Konvention ist nicht NIST-standardisiert — verschiedene AES-Tools nutzen verschiedene Reihenfolgen. Wir dokumentieren sie explizit, damit du Interoperabilität nachbauen kannst.

Externes Entschlüsseln mit Python (cryptography library):

import base64
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.kdf.pbkdf2 import PBKDF2HMAC
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

blob = base64.b64decode("DEIN_BASE64_OUTPUT")
salt, iv, ct = blob[:16], blob[16:28], blob[28:]
kdf = PBKDF2HMAC(algorithm=hashes.SHA256(), length=32, salt=salt, iterations=100000)
key = kdf.derive(b"DEINE_PASSPHRASE")
plaintext = AESGCM(key).decrypt(iv, ct, None)
print(plaintext.decode("utf-8"))

OpenSSL-CLI deckt diesen Layout-Mix nicht direkt mit openssl enc ab, weil OpenSSL ein eigenes Salt-Prefix verwendet. Für reine OpenSSL-Kompatibilität müsstest du Salt und IV manuell extrahieren und openssl enc -K <hex> -iv <hex> aufrufen — aufwändig. Python oder Node sind die ergonomischeren Wege.

Wie sicher ist die Passphrase wirklich?

Die Sicherheit der gesamten Verschlüsselung steht und fällt mit der Passphrase. AES-256 kann mathematisch nicht gebrochen werden — aber wenn die Passphrase ‘Geheim123’ ist, knackt eine GPU sie binnen Stunden, egal wie stark die Cipher ist.

Daumenregeln für 2026:

• Unter 8 Zeichen, eine Klasse (nur Kleinbuchstaben): unsicher, in Sekunden bis Minuten brute-force-bar.
• 8–11 Zeichen, gemischte Klassen: Stunden bis Tage gegen eine moderne GPU mit 100.000 PBKDF2-Iterationen.
• 12–15 Zeichen, gemischte Klassen: Wochen bis Monate. Akzeptabel für niedrig-bedrohte Use-Cases.
• 16+ Zeichen, gemischte Klassen oder Diceware-Pattern: Jahre bis Jahrzehnte. Empfohlen.
• Diceware mit 6 Wörtern aus einer 7776-Wörter-Liste: ~77 Bit Entropie, praktisch unknackbar gegen Brute-Force bis 2050+.

Der Stärke-Indikator unter dem Passphrase-Feld ist eine grobe Heuristik (Länge + Klassen-Mix), kein zxcvbn-Niveau. Er warnt rot bei offensichtlich schwachen Eingaben, gelb bei Grenzfällen, grün ab solider Länge.

Was das Tool bewusst nicht kann

Dateien verschlüsseln. Der MVP nimmt nur Text entgegen. Bulk-File-Encryption ist Phase-2-Backlog — sie braucht Chunked-Reading + Progress-UI + Download-Blob-Handling. Workaround heute: kleine Dateien Base64-kodieren (Browser-Built-in oder unser Base64 Encoder) und den Base64-String verschlüsseln.

Asymmetrische Krypto. Diese Klasse (RSA, Elliptische Kurven, PGP, age) hat fundamental andere UX: ein öffentlicher und ein privater Schlüssel, Schlüsselverwaltung, Vertrauensmodell. Eigenes Tool falls nötig, nicht in das AES-Tool reinquetschen.

Cloud-Speicher für Schlüssel. Anti-Use-Case. Eine Cipher, deren Schlüssel auf einem Server liegt, ist eine Cloud-Datenbank mit Schritt drumherum.

Custom Salt oder Custom IV. Foot-Gun. Nutzer würden statische IVs setzen und damit die Sicherheit zerstören. Bewusst nicht exponiert.

Argon2 oder scrypt als KDF-Alternative. PBKDF2 ist Web-Crypto-nativ. Argon2 bräuchte WebAssembly (libsodium), erweitert den Bundle. Erst dann evaluieren, wenn die Bedrohungsmodelle das wirklich rechtfertigen.

Educational Use — was bedeutet das konkret?

Dieses Tool ist gebaut für Lern- und Alltagsgebrauch: einen kurzen Notiztext geheim halten, einen Treffpunkt verschlüsselt teilen, eine API-Phrase im Notizbuch sichern, das AES-Konzept hands-on verstehen. Es ist nicht gebaut für:

• DSGVO-pflichtige Verschlüsselung von Personenbezogenen Daten in Geschäftskontexten — dafür braucht es zertifizierte Hardware-Token, qualifizierte Signaturen, ein dokumentiertes Schlüssel-Management mit Rotation und Backup-Strategie.
• Schutz vor staatlichen Akteuren oder Geheimdiensten — solche Bedrohungsmodelle erfordern Hardware-Security-Module (HSM), Secure Enclaves, Air-Gapped Maschinen, Forward Secrecy auf Protokoll-Ebene.
• Medizinische, finanzielle oder anwaltliche Compliance-Verschlüsselung — siehe HIPAA, PCI-DSS, eIDAS-Anforderungen.

Für diese Use-Cases sind die richtigen Werkzeuge GnuPG (für Datei-/Mail-Verschlüsselung mit Web-of-Trust), age (modern, schlanker), HashiCorp Vault oder AWS-KMS-äquivalente (für Server-Side-Key-Management), oder qualifizierte Signaturdienste nach eIDAS.

Educational Use bedeutet: das Tool ist mathematisch korrekt, es nutzt FIPS-validierte Primitive, Output ist interoperabel mit professionellen Krypto-Stacks. Aber die Threat-Model-Annahmen — Passphrase im Kopf, kein HSM, kein Audit-Log, kein Schlüssel-Rotation-Workflow — passen nur zu niedrig-bedrohten Use-Cases.

Wie reagiert die Web Crypto API auf Browser-Versionen?

Stabil und cross-browser seit etwa 2017. Konkret:

• Chrome / Edge: seit Version 37 (2014).
• Firefox: seit Version 34 (2014).
• Safari (macOS / iOS): seit Safari 11 / iOS 11 (2017).

Die hier verwendeten Methoden (crypto.subtle.encrypt, crypto.subtle.decrypt, crypto.subtle.deriveKey, crypto.subtle.importKey, crypto.getRandomValues) sind alle in der W3C Web Cryptography API Recommendation (2017) spezifiziert und in allen Major-Browsern voll implementiert. Auf Mobile-Safari iOS 11+ und Chrome-Mobile gilt dasselbe. Kein Polyfill nötig, kein Fallback.

Wann checkt jemand, ob die Cipher wirklich lokal läuft?

DevTools-Netzwerk-Tab öffnen (Cmd+Option+I auf Mac, F12 auf Windows), Tool ausführen — kein Network-Request während der Verschlüsselung. Service-Worker installiert PWA-Caching: Seite kann offline laden, AES funktioniert weiter, kein Netz-Aufruf. Source-Code im Browser einsehbar (Sources-Tab → Component AesVerschluesselungTool.svelte) — die Krypto-Aufrufe sind direkt nachvollziehbar.

Wer braucht so ein Tool im Alltag?

• Entwickler:innen, die schnell eine API-Phrase, einen Treffpunkt oder einen Test-Token im Mail oder Slack-DM verschlüsselt teilen wollen, ohne PGP-Schlüsselaustausch aufzusetzen.
• Lehrende und Lernende in Krypto-Vorlesungen, die das AES-Konzept hands-on durchspielen wollen: was passiert wenn ich eine Passphrase ändere, wie sehen IV-Variationen aus, was bedeutet PKCS#7-Padding.
• Journalist:innen mit niedrig-bedrohten Quellen-Kontakten, die einen kurzen Notiztext aus einem Recherche-Notebook über Mail weiterleiten möchten.
• Privatpersonen mit einem Notizbuch voller Passwörter, die das Notizbuch verschlüsselt in der Cloud sichern wollen (Klartext bleibt offline, Ciphertext geht in iCloud/Dropbox/Drive).

In jedem dieser Fälle gilt: dieses Tool ist eine Bewährungs-Stufe oberhalb von „Klartext in Cloud” und unterhalb von „GnuPG-Workflow mit HSM”. Es schließt eine Lücke, die andere Online-Tools mit ihrem Server-Roundtrip schlicht nicht schließen können.

Häufige Fragen

Die wichtigsten Antworten findest du oben im FAQ-Block — sie werden als strukturiertes JSON-LD (FAQPage) für Suchmaschinen ausgegeben.

Welche Tools passen dazu?

Weitere Tools aus dem kittokit-Ökosystem, die im selben Kontext nützlich sind:

• Hash Generator — MD5/SHA-1/SHA-256/SHA-384/SHA-512-Hashes von Text berechnen, vollständig im Browser.
• Passwort-Generator — Zufällige starke Passphrasen erzeugen, perfekt für AES-Schlüssel.
• JWT Decoder — JWT-Tokens dekodieren ohne Server-Roundtrip.