So funktioniert Ende-zu-Ende-Verschlüsselung bei Dateiübertragung

Ende-zu-Ende-Verschlüsselung bei der Dateiübertragung bedeutet: Die Bytes, die Ihr Gerät verlassen, sind mit einem Schlüssel verschlüsselt, der niemals den Server berührt – und nur Ihr vorgesehener Empfänger kann sie entschlüsseln. Das BSI empfiehlt in seiner Technischen Richtlinie TR-02102-1 AES-256-GCM als bevorzugte symmetrische Chiffre für sensitive Dateitransfers – genau das Verfahren, das reife Ende-zu-Ende-verschlüsselte Dienste einsetzen. Der Server speichert Geheimtext, sieht nichts Sinnvolles und könnte gehackt werden, ohne den Inhalt Ihrer Datei preiszugeben. Das kryptographische Rezept kombiniert fast immer eine symmetrische Chiffre wie AES-256-GCM oder ChaCha20-Poly1305 für die Datei selbst mit einem Schlüsselaustausch wie X25519 ECDH oder RSA-OAEP für das Schlüsselmaterial.

Das Bedrohungsmodell, das Ende-zu-Ende-Verschlüsselung tatsächlich abwehrt

Ende-zu-Ende-Verschlüsselung verteidigt speziell gegen: den gehackten, mit einer Vorladung belegten oder böswilligen Übertragungsanbieter; Netzwerkangreifer, die TLS-entschlüsselten Datenverkehr an Proxys abfangen; Backup-Snapshots des Speicher-Buckets, die in falsche Hände geraten; und Insider-Zugriff durch Mitarbeiter des Dienstes. Sie schützt nicht gegen Malware auf dem Gerät des Senders oder Empfängers, gegen Phishing, das den Entschlüsselungslink abfängt, oder gegen kompromittierte Empfängerkonten. Das Modell zu verstehen ist entscheidend, da „verschlüsselt" oft missbraucht wird, um „TLS während der Übertragung plus AES-at-Rest auf dem Server" zu meinen – was den Anbieter im Besitz der Schlüssel lässt und damit aus DSGVO-Sicht eine Schwachstelle darstellt.

Symmetrische Verschlüsselung für die Datei-Payload

Dateien werden mit einem symmetrischen Algorithmus verschlüsselt, da Public-Key-Kryptographie für Massendaten zu langsam ist. Die moderne Wahl ist AES-256-GCM, definiert in NIST SP 800-38D, das in einem Durchgang sowohl Vertraulichkeit als auch authentifizierte Integrität bietet. Ein zufälliger 256-Bit-Schlüssel und ein einmaliger 96-Bit-Nonce (der mit demselben Schlüssel niemals wiederverwendet wird) schützen jede Datei. ChaCha20-Poly1305, definiert in RFC 8439, ist eine Alternative, die auf Geräten ohne AES-NI-Hardwarebeschleunigung – wie älteren ARM-Prozessoren – oft schneller ist. Beide erzeugen einen Geheimtext plus einen 128-Bit-Authentifizierungs-Tag, der jede Manipulation erkennt.

Schlüsselableitung aus Passwörtern

Wenn Ende-zu-Ende-Verschlüsselung ein Passwort verwendet, ist das Passwort selbst niemals der Verschlüsselungsschlüssel – das wäre zu schwach gegen Brute-Force. Stattdessen streckt eine Schlüsselableitungsfunktion wie PBKDF2-HMAC-SHA256 mit 600.000 oder mehr Iterationen (OWASP-Empfehlung 2025), Argon2id mit m=19 MiB und t=2 (RFC 9106) oder scrypt (RFC 7914) das Passwort zu einem starken Schlüssel. Ein zufälliges 128-Bit- oder 256-Bit-Salt verhindert Rainbow-Table-Angriffe. Der resultierende Schlüssel verschlüsselt die Datei. Das Salt und die Iterationsanzahl werden zusammen mit dem Geheimtext gespeichert, damit der Empfänger den Schlüssel rekonstruieren kann, wenn er das Passwort eingibt.

Public-Key-Wrapping für kontobasierte Übertragungen

Wenn Empfänger Konten mit veröffentlichten öffentlichen Schlüsseln haben, ist keine Passworteingabe erforderlich. Der Sender generiert einen zufälligen Datei-Verschlüsselungsschlüssel (FEK), verschlüsselt die Datei mit AES-256-GCM unter Verwendung des FEK, dann verschlüsselt er den FEK für den öffentlichen Schlüssel jedes Empfängers mittels X25519-ECDH-Schlüsselaustausch nach RFC 7748, kombiniert mit HKDF-SHA256 nach RFC 5869, um einen Wrapping-Schlüssel abzuleiten, oder RSA-OAEP nach PKCS#1 v2.2 mit SHA-256. Der eingewickelte FEK liegt neben dem Geheimtext. Nur der Inhaber des privaten Schlüssels des Empfängers kann den FEK entpacken und die Datei entschlüsseln. Das ist das Signal- und WhatsApp-Modell für Nachrichten, angepasst für Datei-Payloads.

Linkbasierte Ende-zu-Ende-Verschlüsselung mit URL-Fragmenten

Ein cleverer Trick bei Browser-basierten Übertragungen: den Entschlüsselungsschlüssel im URL-Fragment zu speichern (der Teil nach #). Fragmente werden niemals in einer HTTP-Anfrage an den Server gesendet. Ein Link wie https://example.com/d/abc123#k=B9kZtR... trägt die Datei-ID serverseitig und den Schlüssel clientseitig. Der Browser lädt den Geheimtext herunter, liest das Fragment in JavaScript und entschlüsselt lokal. Der Dienst sieht den Schlüssel nie. Der Vorbehalt: Wenn der Link irgendwo durchsickert – in Logs, Screenshots, Messenger-App-Vorschauen – leckt der Schlüssel mit.

Integrität mit AEAD und Hashes

Authenticated Encryption with Associated Data (AEAD)-Modi wie GCM und ChaCha20-Poly1305 verhindern Manipulation. Ein einzelner Bitflip im Geheimtext lässt die Validierung des Authentifizierungs-Tags fehlschlagen, und die Entschlüsselungsfunktion gibt einen Fehler zurück statt ungültigem Klartext. Zusätzlich zu AEAD berechnen viele Implementierungen einen SHA-256- oder BLAKE3-Hash des Klartexts als Manifest-Eintrag, damit der Empfänger nach der Entschlüsselung verifizieren kann, dass die Datei dem entspricht, was der Sender beabsichtigte. Das ist besonders wichtig für große Dateien, die in Chunks übertragen werden.

Chunk-basierte Verschlüsselung für große Dateien

Eine 10-GB-Datei in einer AES-GCM-Operation zu verschlüsseln erfordert, 10 GB im Zustand zu halten – das ist in Browsern unpraktisch. Reale Implementierungen teilen die Datei in Chunks, typischerweise 1 bis 16 MB jeweils, und verschlüsseln jeden Chunk unabhängig mit einem abgeleiteten Unterschlüssel und einem zählerbasierenden Nonce. Das age-Verschlüsselungstool verwendet 64-KB-Chunks mit ChaCha20-Poly1305. Chunk-Grenzen ermöglichen es Browsern auch, die Entschlüsselung über die Streams API zu streamen – den Download auf die Festplatte zu beginnen, bevor die gesamte Datei angekommen ist – und unterstützen fortsetzbare Uploads bei Netzwerkunterbrechungen.

Transportsicherheit zusätzlich zur Ende-zu-Ende-Verschlüsselung

TLS 1.3, definiert in RFC 8446, ist auch zusätzlich zur Ende-zu-Ende-Verschlüsselung wichtig – nicht für die Vertraulichkeit der Payload (die ist bereits verschlüsselt), sondern für den Schutz von Metadaten: Dateinamen, Größen und Timing. TLS 1.3 mit forward-secret Schlüsselaustausch wie X25519 bedeutet, dass selbst wenn der langfristige Schlüssel des Servers später kompromittiert wird, aufgezeichnete Sitzungen nicht entschlüsselt werden können. Certificate Pinning oder HSTS-Preload verhindert Downgrade-Angriffe. Gemeinsam schützen Ende-zu-Ende-Verschlüsselung plus TLS 1.3 sowohl den Dateiinhalt als auch das Betriebsmuster – wer was an wen sendet.

Häufige Implementierungsfehler

Drei Fehler wiederholen sich. Erstens: Nonces mit demselben Schlüssel in AES-GCM wiederverwenden – das zerstört die Vertraulichkeit katastrophal; immer einen frischen Zufalls-Nonce oder einen Zähler verwenden, der sich nie wiederholt. Zweitens: Kryptographie mit selbst entwickelten Routinen statt geprüfter Bibliotheken wie libsodium, Web Crypto API (SubtleCrypto) oder BoringSSL implementieren – Constant-Time-Operationen sind entscheidend für die Verhinderung von Timing-Angriffen. Drittens: Datei-Metadaten nicht zusammen mit dem Inhalt authentifizieren; wenn die Identität des Senders, der Dateiname oder die Empfängerliste nicht in den AAD (Associated Authenticated Data) eingeschlossen sind, kann ein Angreifer Metadaten unentdeckt austauschen. HexaTransfer begegnet diesen Risiken durch standardmäßige Web-Crypto-Primitive client-seitig mit geprüften Mustern.

Verifizieren, ob ein Dienst wirklich Ende-zu-Ende-Verschlüsselung bietet

Marketingaussagen kritisch lesen. Echte Ende-zu-Ende-Verschlüsselung bedeutet, dass der Anbieter Dateien nicht entschlüsseln kann, selbst wenn er durch eine gerichtliche Anordnung dazu gezwungen wird. Suchen Sie nach: veröffentlichter technischer Dokumentation mit genauen Algorithmen (AES-256-GCM, X25519, HKDF, PBKDF2-Iterationszahlen), Open-Source-Client-Code, der geprüft werden kann, und einem Bedrohungsmodell, das anerkennt, was Ende-zu-Ende-Verschlüsselung schützt und was nicht. Dienste, die serverseitige Passwortwiederherstellung für verschlüsselte Dateien anbieten, führen keine echte Ende-zu-Ende-Verschlüsselung durch – sie halten die Schlüssel. Dienste, die „Zero-Knowledge" behaupten, sollten das mit einer kryptographischen Protokollbeschreibung belegen, nicht nur mit einem Slogan.

Kostenlos ausprobieren auf hexatransfer.com — kein Konto erforderlich, bis zu 10 GB.