AES-256 Encrypt / Decrypt Online - Free, In-Browser

AES-256 ist der Advanced Encryption Standard mit einem 256-Bit-Schlüssel, dem größten der drei Standard-AES-Schlüsselgrößen. Er wird von NIST und NSA Suite B zum Schutz von Informationen bis TOP SECRET genehmigt. Ein 256-Bit-Schlüssel bedeutet, dass eine Brute-Force-Suche 2^256 Möglichkeiten abdeckt, astronomisch jenseits jeder aktuellen oder absehbaren Rechenbemühung. Der praktische Grund, 256 gegenüber 128 zu wählen, ist eine größere Sicherheitsmarge gegen zukünftige Kryptoanalyse und gegen Grovers Algorithmus, der rund 128 Bits effektive Post-Quanten-Sicherheit hinterlässt.

Ja, sofern das Werkzeug vollständig in deinem Browser läuft und deinen Klartext nie an einen Server sendet. Diese Seite verwendet die native Web-Crypto-API des Browsers (dieselbe Implementierung, die für TLS verwendet wird) und führt Salz-Generierung, PBKDF2-Schlüsselableitung, AES-Verschlüsselung und Base64-Kodierung lokal durch. Nichts wird hochgeladen, protokolliert oder in persistenten Speicher geschrieben. Du kannst das in den DevTools-Netzwerk-Einstellungen bestätigen und nach dem Laden der Seite sogar die Internetverbindung trennen. Das verbleibende Risiko ist dein eigenes Gerät - Malware kann Klartext vor der Verschlüsselung lesen, egal welches Werkzeug du verwendest.

Sie unterscheiden sich in Schlüssellänge, Rundenanzahl und Sicherheitsmarge. AES-128 verwendet einen 128-Bit-Schlüssel und 10 Runden; AES-192 verwendet 192 Bit und 12 Runden; AES-256 verwendet 256 Bit und 14 Runden. Alle drei sind gegen jeden bekannten klassischen Angriff sicher. AES-128 ist auf Hardware ohne AES-NI etwa 40 Prozent schneller pro Byte als AES-256, aber der Unterschied ist auf modernen CPUs vernachlässigbar. AES-256 für Langzeitarchive wählen, AES-128 wenn ein älteres System einschränkt, AES-192 nur wenn ein Compliance-Profil es vorschreibt.

GCM verwenden, sofern kein spezifischer Grund für eine andere Wahl besteht. AES-GCM ist authentifizierte Verschlüsselung: Es bietet sowohl Vertraulichkeit als auch Integrität in einem Durchgang, sodass ein manipulierter Chiffretext beim Entschlüsseln erkannt wird, anstatt still Müll zurückzugeben. AES-CBC und AES-CTR bieten nur Vertraulichkeit, sodass ein Angreifer, der den Chiffretext modifiziert, Klartext-Bytes ohne Erkennung korrumpieren kann. CBC ist bekannt für Padding-Oracle-Angriffe. CBC oder CTR nur wählen, um mit einem System zu interoperieren, das GCM nicht unterstützt.

Nein. Alles läuft in deinem Browser über die Web-Crypto-API. Klartext, Passwort, Salz, IV und Chiffretext werden lokal erstellt und verbraucht, nie über das Netzwerk serialisiert oder in persistenten Speicher geschrieben. Du kannst nach dem Laden der Seite die Internetverbindung trennen und das Werkzeug funktioniert weiterhin. Die einzigen Bytes, die über das Netzwerk gehen, sind die statischen Seitenassets selbst, gecacht von Cloudflare.

Jeder Verschlüsseln-Klick generiert ein frisches 16-Byte-Zufallssalz und einen frischen IV (12 Bytes für GCM, 16 für CBC und CTR). Beide werden innerhalb der Base64-Ausgabe gespeichert, sodass das Entschlüsseln sie wiederherstellen kann. Die Randomisierung von Salz und IV bedeutet, dass identische Klartexte nie identische Chiffretexte erzeugen, sodass ein Angreifer durch Vergleich von Ausgaben nichts lernt. Einen IV mit demselben Schlüssel wiederzuverwenden ist katastrophal in jedem AES-Modus, weshalb das Werkzeug ihn bei jedem Aufruf neu generiert.

Der Chiffretext ist ohne das korrekte Passwort mathematisch nicht wiederherstellbar. AES kombiniert mit PBKDF2 bei 100.000 Iterationen hat keine Hintertür, keinen Master-Schlüssel, kein Passwort-Reset. Das Brute-Forcing eines starken Passworts (eine lange zufällige Passphrase oder ein 16-Zeichen-Passwort-Manager-Ergebnis) ist innerhalb jedes realistischen Zeitrahmens nicht machbar. Das Passwort in einem Passwort-Manager speichern oder an einem physisch sicheren Ort aufschreiben. Es verlieren und die verschlüsselten Daten sind dauerhaft unzugänglich - das ist der Sinn.

Nur wenn das andere Werkzeug dasselbe Format implementiert. Diese Seite stellt einen Drei-Byte-Header (<code>version | mode | keyBits</code>) vor dem <code>salt | iv | ciphertext</code>-Layout voran und verwendet PBKDF2-HMAC-SHA-256 bei 100.000 Iterationen mit einem 16-Byte-Salz. Für die Integration mit benutzerdefiniertem Code die Header-Parsing replizieren, <code>crypto.subtle.importKey</code> + <code>deriveKey</code> mit übereinstimmenden Parametern verwenden und den entsprechenden AES-Modus ausführen.

Ja. Das Werkzeug kodiert Text als UTF-8 mit <code>TextEncoder</code> vor der Verschlüsselung und dekodiert genauso nach der Entschlüsselung, sodass Chinesisch, Arabisch, Kyrillisch und Emoji alle einen vollständigen Round-Trip überleben. Rohe Binärdaten (Bilder, PDFs) werden über diese reines-Text-Schnittstelle nicht unterstützt; dafür zuerst die Binärdaten mit dem <a href="/de/tools/base64-encode-decode/">Base64-Werkzeug</a> Base64-kodieren und den resultierenden Text verschlüsseln.

Es gibt kein Protokolllimit unter 2^39 Bytes pro AES-GCM-Schlüssel, aber der Browser-Speicher ist das praktische Limit. Eingaben bis etwa einem Megabyte verschlüsseln in weit unter einer Sekunde. Dutzende Megabytes frieren den Tab kurz während PBKDF2 ein, und alles nahe einem Gigabyte riskiert den Absturz der Seite. Für große Dateien ein Streaming-Desktop- Werkzeug wie <code>openssl enc</code>, <code>age</code> oder <code>gpg --symmetric</code> bevorzugen.