AES-256: Die Chiffre, die Betriebsart und die Grenzen

AES-256 ist eine Blockchiffre mit einem 256-Bit-Schlüssel, standardisiert in FIPS 197. Sie formt einen festen Datenblock unter einem Schlüssel zu Chiffrat um. Die Zahl 256 beschreibt allein die Länge dieses Schlüssels. Über Ihre Dateien, Ihr Gerät oder die Person am Schlüssel sagt sie nichts.

Zwei weitere Entscheidungen wiegen ähnlich schwer. Die Betriebsart legt fest, wie die Chiffre mit Daten umgeht, die länger als ein Block sind. Die Schlüsselableitung legt fest, wie aus Ihrer Passphrase ein Schlüssel wird. AES-256-GCM ist eine mögliche Kombination, AES-256-CBC eine andere. Beide teilen dieselbe Chiffre und unterscheiden sich fast überall sonst.

CBC verkettet jeden Block mit dem vorherigen und verdeckt so Muster im Klartext. Für sich genommen erkennt es keine Manipulation: Wer einzelne Chiffrat-Bits kippt, richtet vorhersehbaren Schaden an, ohne den Schlüssel zu kennen. GCM hängt zusätzlich einen Authentifizierungs-Tag über das Chiffrat, beschrieben in NIST SP 800-38D. Eine veränderte Datei lässt sich dann nicht mehr entschlüsseln, statt falsche Daten zu liefern.

Ein zweiter Unterschied betrifft das, was Sie wiederverwenden dürfen. CBC braucht für jede Nachricht einen frischen, zufälligen Initialisierungsvektor. GCM braucht einen Nonce, der sich unter demselben Schlüssel niemals wiederholt. Eine wiederholte GCM-Nonce ist einer der wenigen Fehler, die das Verfahren grundsätzlich brechen; deshalb erzeugen Bibliotheken sie selbst und überlassen Ihnen diese Wahl nur selten.

Die Schlüssellänge sagt nichts darüber, wie der Schlüssel entstanden ist. Ein Schlüssel aus einer kurzen oder mehrfach genutzten Passphrase ist so schwach wie diese Passphrase, unabhängig davon, was die Chiffre leistet. PBKDF2, beschrieben in RFC 8018, und ähnliche Verfahren machen Rateversuche teuer. Ein Kennwort, das in einer öffentlichen Liste steht, retten sie nicht.

Auch über die Endpunkte sagt Verschlüsselung nichts. Schadsoftware auf dem Gerät, eine Browser-Erweiterung mit Seitenzugriff oder ein eingeschleustes Skript sehen Ihren Klartext, bevor überhaupt eine Chiffre läuft. Ein Teil der Metadaten bleibt ebenfalls sichtbar: Dateigröße, Zeitstempel und die Tatsache, dass eine Übertragung stattgefunden hat.

Die Web Crypto API führt AES-256-GCM im Browser aus und kann einen Schlüssel als nicht exportierbar halten. Skripte können diese Rohbytes des Schlüssels dann nicht auslesen. Ihre Passphrase muss die Seite trotzdem erhalten, und alles, was in dieser Seite läuft, kann mitlesen, was Sie eintippen. Die Herkunft der Seite wiegt deshalb schwerer als die Wahl der Betriebsart.

Ein nicht exportierbarer Schlüssel hilft in einem schmalen Fall. Wer später eine Kopie des Speichers oder einen Speicherauszug anfertigt, hebt einen nie exportierbaren Schlüssel schwerer heraus. Gegen Code, der während Ihrer Eingabe in der Seite läuft, richtet er nichts aus, und ein bereits kompromittiertes Gerät übersteht er nicht.

Fragen Sie zuerst, wogegen Sie sich schützen. Ein verlorenes Notebook, ein geteilter Upload-Ordner und ein Anbieter, der alles protokolliert, verlangen unterschiedliche Entwürfe. Fragen Sie dann, wer entschlüsseln soll. Hält nur Sie den Schlüssel, deckt ein clientseitiges Werkzeug mit AES-256-GCM und einer langen Passphrase den größten Teil des Risikos ab. Muss später jemand anderes die Daten lesen, wird der Schlüsselaustausch zum schwierigen Teil.

Eine praktische Regel: Bevorzugen Sie ein Werkzeug, das authentifiziert. Ohne Tag kann eine beschädigte oder bearbeitete Datei zu falschen Daten entschlüsselt werden, und nichts in der Ausgabe warnt Sie. Dieser Fehler bleibt leise, und genau deshalb lohnt es sich, ihn konstruktiv auszuschließen.