Eine Datei verschlüsseln — und den Schlüssel auf einem anderen Weg schicken

Was das Werkzeug wirklich mit deiner Datei macht

Genauigkeit lohnt sich hier, denn „AES-256“ auf einem Knopf sagt fast nichts — dieselben drei Buchstaben decken hervorragende und kaputte Konstruktionen ab. Diese ruft die WebCrypto-Implementierung des Browsers im Modus AES-GCM auf, also authentifizierte Verschlüsselung: Sie verbirgt nicht nur den Inhalt, sie belegt auch, dass er nicht verändert wurde. Der Schlüssel hat 256 Bit. Das Authentifizierungs-Tag hat 128 Bit, und das lässt sich ohne eine Zeile Code prüfen: Aus 71 Byte Klartext wurden 87 Byte Chiffrat — genau die sechzehn Zusatzbytes, die RFC 5116 für AES-256-GCM vorsieht.

Eine Passphrase ist kein Schlüssel, sie muss erst zu einem werden. Das Werkzeug nutzt PBKDF2-HMAC-SHA256 über 150 000 Iterationen mit einem 16-Byte-Salt aus der kryptografischen Zufallsquelle des Browsers. Das Salt ist bei jeder Verschlüsselung neu — genau das verhindert, dass eine vorberechnete Tabelle viele Dateien auf einmal abdeckt. Die Nonce hat 12 Byte und wechselt ebenfalls jedes Mal; geprüft, indem dieselbe Datei zweimal mit derselben Passphrase verschlüsselt und verglichen wurde: anderes Salt, andere Nonce, anderes Chiffrat. Beide stehen im Klartext am Anfang der Ausgabe, und das ist richtig so, nicht nachlässig. Salt und Nonce sind keine Geheimnisse; sie müssen nur eindeutig sein, und wer entschlüsselt, braucht sie, um den Schlüssel nachzubauen.

Die Authentifizierungshälfte ist keine Zierde. Kippe irgendwo im Chiffrat ein einziges Bit, und die Entschlüsselung verweigert sich; kippe ein einziges Bit der gespeicherten Nonce, verweigert sie sich ebenfalls; gib eine Passphrase, die sich um einen Großbuchstaben unterscheidet, und wieder Fehlanzeige. In jedem Fall bekommst du einen Fehler, nie eine Datei voll plausibel aussehendem Müll. Dieser Unterschied wiegt schwerer, als er klingt: Ein Modus ohne Authentifizierung, etwa AES-CBC ohne separate Integritätsprüfung, gibt beschädigte Daten klaglos zurück, und wer die Datei unterwegs verändern kann, vermag diesen Schaden mitunter zu lenken.

Der Fehler, den alle machen: Der Schlüssel reist mit der Datei

So sieht es aus. Du verschlüsselst die Gehaltstabelle, hängst die .enc-Datei an eine E-Mail und tippst — die Empfängerin braucht sie ja — die Passphrase in dieselbe Nachricht. Oder in eine Folgenachricht, was sorgfältiger wirkt und es nicht ist. Oder als Antwort im selben Verlauf, was schlimmer ist, weil beide Hälften nun in einer Unterhaltung liegen, die jede Suche gemeinsam zutage fördert. Welche Variante auch immer: Du hast ein Schloss angebracht und den Schlüssel an die Tür geklebt.

Warum „ich schicke sie in einer zweiten Mail“ scheitert: Es ändert nichts daran, wer mitlesen kann. Transportverschlüsselung ist hier nicht das Bedrohungsmodell — Post zwischen großen Anbietern ist auf der Leitung längst verschlüsselt. Wogegen du dich wirklich wehrst, ist jemand, der das Postfach liest: ein übernommenes Konto, ein unversperrt liegen gelassenes Telefon, eine geteilte Familienadresse, ein Arbeitgeber mit rechtmäßigem Zugriff aufs Archiv, ein geleaktes Backup, ein weitergeleiteter Verlauf, der einen Empfänger zu viel aufgesammelt hat. Jeder dieser Fälle legt die zweite Mail genauso offen wie die erste. Zwei Nachrichten im selben Postfach sind ein Kanal, der zufällig zweimal benutzt wurde.

Was ein zweiter Kanal wirklich bedeutet

Ein zweiter Kanal muss sich in dem unterscheiden, was tatsächlich versagt. Drei Achsen lohnen die Trennung. Ein anderes Medium — E-Mail gegen Stimme gegen Papier —, damit ein gebrochenes Protokoll nicht beide Hälften ausliefert. Ein anderes Konto — dein Arbeitspostfach gegen einen privaten Messenger —, damit nicht eine Zugangsdatei beide öffnet. Und ein anderes Gerät, damit ein gestohlenes oder verseuchtes Telefon nicht Datei und Passphrase nebeneinander trägt. Schick die Datei vom Laptop und die Passphrase aus der Messenger-App desselben Laptops, und du hast den Schlüssel über den Schreibtisch geschoben, nicht aus dem Raum.

Deshalb ist eine am Telefon vorgelesene Passphrase wirklich besser und nicht bloß altmodisch. Sie hinterlässt keine Kopie: keine Nachricht, die man später durchsucht, kein Backup, das leakt, keinen versehentlich weitergeleiteten Verlauf, kein Archiv, das eine Administratorin in zwei Jahren öffnet. Sie abzufangen verlangt, in genau dem Moment in der Leitung zu sein, in dem sie gesprochen wird — ein weit engerer und weit teurerer Angriff als in Ruhe ein Postfach zu lesen. Sie liefert außerdem etwas, das kein Kanal allein bietet: Du erkennst die Stimme und weißt damit, wer sie bekommen hat. Sprich langsam, nutze das NATO-Alphabet für alles Mehrdeutige, und lass sie zurücklesen.

Was vergessen wird: Die Empfängerin muss sie öffnen können

Eine verschlüsselte Datei, die am anderen Ende niemand entschlüsseln kann, ist keine Sicherheit, sondern eine gescheiterte Zustellung — und die übliche Reparatur ist schlimmer als das Ausgangsproblem, weil am Ende jemand die Datei „nur dieses eine Mal“ unverschlüsselt noch einmal schickt. Prüfe also die Gegenseite, bevor du sendest. Die .enc-Datei dieses Werkzeugs hat gar keinen Header: Ihre ersten Bytes sind das rohe Zufallssalt, ohne Magic Number, ohne Version, ohne Algorithmusnamen und ohne ursprünglichen Dateinamen. Das ist ein eigenes Layout. Es ist kein ZIP, keine OpenPGP-Nachricht, keine age-Datei, keine Ausgabe von openssl enc — und nichts davon wird sie öffnen.

Die praktische Folge ist allerdings eine gute: Weil das Werkzeug vollständig im Browser läuft, muss die Empfängerin nichts installieren, kein Konto anlegen und keinem Server die Datei anvertrauen. Sie öffnet dieselbe Seite, lädt die .enc-Datei, tippt die Passphrase und drückt Entschlüsseln — der Klartext landet in ihren Downloads. In keine Richtung wird etwas hochgeladen. Der Satz, der mit der Datei mitgeht, ist also nicht der Passworthinweis, sondern die Adresse der Seite. Und diesen Satz schick ruhig über denselben Kanal wie die Datei, denn er ist kein Geheimnis; nur die Passphrase wechselt die Straße.

Wenn die Passphrase verloren ist

Nichts lässt sich tun. Nicht von der Seite, nicht von einem Support, nicht von dir. Es gibt kein Konto mit einer Kopie, keinen Wiederherstellungsschlüssel, keine Hinterlegung und keine Hintertür — der Schlüssel existierte nie irgendwo außer im Speicher des Tabs, der ihn erzeugt hat, und er wurde im Moment aus der Passphrase abgeleitet. Verlierst du die Passphrase, ist die Datei ein Block Rauschen und bleibt Rauschen. Das gehört klar gesagt, denn man setzt standardmäßig einen Wiederherstellungsweg voraus, wie beim Passwort eines Webmail-Kontos.

Und das ist die Konstruktion bei der Arbeit, nicht beim Versagen. Ein Wiederherstellungsweg ist per Definition ein zweiter Zugang, und einen zweiten Zugang kann auch ein Angreifer nehmen — oder ein Gericht kann jemanden zwingen, ihn zu öffnen. Die richtige Antwort ist nicht, sich eine Hintertür zu wünschen, sondern die Passphrase dauerhaft abzulegen, bevor du sie brauchst: ein Eintrag im Passwortmanager, an den Dateinamen geknüpft, oder Papier in einer Schublade, wenn die Datei in fünf Jahren noch zählen soll. Nimm eine Passphrase, die du diktieren kannst, denn wahrscheinlich wirst du müssen. Vier oder fünf zusammenhanglose Wörter schlagen ein verunstaltetes Einzelwort auf beiden Feldern: stärker, und sie überstehen das Vorlesen.

Eine ehrliche Schwäche: die Iterationszahl

Nicht das Verfahren ist hier die dünnste Stelle, sondern die Schlüsselableitung. PBKDF2 gibt es, um Raten teuer zu machen, und der Preis wird über die Iterationszahl eingestellt. Dieses Werkzeug nimmt 150 000. Das OWASP Password Storage Cheat Sheet, die Referenz, von der die meisten Verteidiger ausgehen, empfiehlt derzeit 600 000 für PBKDF2-HMAC-SHA256. Der ausgelieferte Wert ist ein Viertel davon und vervierfacht damit den Durchsatz eines offline ratenden Angreifers. Auf einem Kern gemessen brauchen 150 000 Iterationen rund 36 Millisekunden pro Versuch: Ein gewöhnlicher Kern probiert also etwa 28 Passphrasen pro Sekunde; Spezialhardware schafft weit mehr, und PBKDF2 kommt ihr stärker entgegen als eine speicherhungrige Funktion wie Argon2id.

Das macht das Werkzeug nicht unsicher und ändert nichts am Verfahren, am Salt oder an der Nonce, die alle stimmen. Es verschiebt, woher die Sicherheit kommt: Bei leichterer Schlüsselableitung liegt mehr Last auf der Passphrase selbst. Eine Passphrase aus vier zufällig aus einer großen Wortliste gezogenen Wörtern bleibt so oder so außer Reichweite; ein Wörterbuchwort mit angehängter Ziffer war nie durch Iterationszahlen geschützt. Wähle die Passphrase, als gäbe es überhaupt keine Streckung — dann hört der Unterschied zwischen 150 000 und 600 000 auf, dich zu betreffen.

Häufige Fragen

Reicht AES-256-GCM für sich allein?

Für die Verschlüsselung selbst ja — es ist ein standardisierter authentifizierter Modus, und die Browser-Implementierung ist dieselbe, die HTTPS nutzt. Aber ein Verfahren schützt nur, was der Schlüssel schützt. Hier wird der Schlüssel aus deiner Passphrase abgeleitet: Die wirkliche Obergrenze ist die Passphrase, und der wirkliche Fehlerfall ist, sie über denselben Kanal wie die Datei zu schicken. Dagegen kann AES-256-GCM nichts ausrichten.

Warum steht das Salt offen am Anfang der Datei?

Weil es kein Geheimnis ist und nie eines sein sollte. Ein Salt sorgt dafür, dass dieselbe Passphrase jedes Mal einen anderen Schlüssel ergibt — das verhindert, dass eine vorberechnete Tabelle viele Dateien auf einmal angreift. Es muss nur eindeutig sein, nicht verborgen. Für die Nonce gilt dasselbe. Wer entschlüsselt, braucht beides, um den Schlüssel nachzubauen; sie müssen also mit dem Chiffrat reisen. Sie zu verstecken hieße, sie zu verschlüsseln, wofür man einen Schlüssel bräuchte — und schon ist man wieder am Anfang.

Kann ich die Passphrase einfach in einer zweiten Mail schicken?

Nein, und es ist die häufigste Spielart des Fehlers. Zwei Mails an dieselbe Adresse landen im selben Postfach, im selben Archiv und im selben Backup. Wer die eine lesen kann, liest auch die andere, und eine Suche nach dem Absendernamen fördert beide nebeneinander zutage. Das ist kein zweiter Kanal, sondern derselbe Kanal, zweimal benutzt. Wechsle das Medium — Stimme oder ein Messenger auf einem anderen Konto —, sonst kauft die Verschlüsselung nur die Zeit, die jemand zum Scrollen braucht.

Kann die Empfängerin die .enc-Datei mit 7-Zip, GPG oder openssl öffnen?

Nein. Der Container hat ein eigenes Layout — 16 Byte Salt, 12 Byte Nonce, dann Chiffrat und Tag — ohne Magic Number, ohne Versionsbyte und ohne Algorithmuskennung, sodass kein Standardwerkzeug ihn überhaupt erkennt. Die Empfängerin öffnet dieselbe Seite in ihrem eigenen Browser, lädt die Datei, tippt die Passphrase und drückt Entschlüsseln; nichts wird installiert, nichts hochgeladen. Sag ihr in derselben Nachricht wie die Datei, welche Seite sie öffnen soll. Dieser Teil ist kein Geheimnis.

Ich habe die Passphrase verloren — ist wirklich nichts zu machen?

Wirklich nichts. Der Schlüssel existierte nur in dem Tab, der ihn erzeugt hat, im Moment der Verschlüsselung aus der Passphrase abgeleitet; nirgends und von niemandem wird eine Kopie aufbewahrt. Es gibt keinen Wiederherstellungsschlüssel, keine Hinterlegung und keinen Support-Weg, und dieses Fehlen ist Absicht: Jeder Wiederherstellungspfad ist ein zweiter Zugang, den auch ein Angreifer nehmen könnte. Erinnerst du dich ungefähr an die Passphrase, bleibt nur, Varianten von Hand zu probieren — jeder Versuch kostet etwa eine zwanzigstel Sekunde.