Ende-zu-Ende-Verschlüsselung erklärt: Anfänger-Guide

Ende-zu-Ende-Verschlüsselung (E2EE) bedeutet, dass Ihre Datei auf Ihrem Gerät mit einem Schlüssel verschlüsselt wird, den nur der Empfänger rekonstruieren kann. Der Transferdienst überträgt nur Chiffretext und hält niemals den Entschlüsselungsschlüssel – Mitarbeiter, Hacker und Strafverfolgungsbehörden können den Inhalt nicht lesen. In der Praxis erzeugt Ihr Browser einen zufälligen 256-Bit-AES-Schlüssel, verschlüsselt die Datei lokal, lädt den Chiffretext hoch und platziert den Schlüssel im Freigabelink nach dem #-Fragment – das Browser nie an den Server senden. Das ist der entscheidende Kniff, der echten Datenschutz von Marketing-Sprache trennt.

Was „Ende zu Ende" wirklich bedeutet

Die zwei „Enden" sind Sie und Ihr Empfänger. Alles dazwischen – ISP-Router, CDN-Edges, die Server des Transferunternehmens, der ISP des Empfängers – sitzt in der Mitte. Mit E2EE sehen diese Zwischenstellen nur verschlüsselte Bytes. Vergleichen Sie das mit reiner Transportverschlüsselung (TLS): TLS schützt Daten von Ihrem Browser bis zum Server, dann entschlüsselt der Server sie, speichert Klartext und verschlüsselt erneut, wenn der Empfänger herunterlädt. WeTransfers Standard-Stufe funktioniert so. Das Unternehmen kann Dateien auf Anfrage herausgeben – und ist nach deutschem und EU-Recht manchmal dazu verpflichtet.

Mit E2EE hat der Anbieter selbst bei einem Durchsuchungsbeschluss nichts auszuhändigen außer zufällig aussehenden Bytes. Deshalb bestehen Journalisten, Anwälte und Ärzte zunehmend auf E2EE.

Warum TLS allein nicht ausreicht

TLS 1.3 ist ausgezeichnet darin, was es tut: einen Angreifer im Café oder einen korrumpierten ISP daran zu hindern, die Verbindung zu belauschen. Aber TLS endet am Server. Sobald der verschlüsselte Tunnel endet, verarbeitet der Server die rohe Datei. Wird dieser Server kompromittiert – wie Dropbox 2022, als Quellcode und Kundendaten abflossen – bietet TLS keinen Schutz für gespeicherte Dateien.

E2EE fügt eine zweite Schicht hinzu, die einen Servereinbruch übersteht. Die Datei ist verschlüsselt, bevor sie die Leitung berührt, und bleibt verschlüsselt, bis der Browser des Empfängers sie entschlüsselt. Selbst ein vollständiger Datenbankdump enthüllt nur Chiffretext und Metadaten.

Das Schlüsselaustausch-Problem – gelöst

Der knifflige Teil von E2EE ist, den Schlüssel zum Empfänger zu bringen, ohne dass der Server ihn sieht. Moderne browserbasierte Dienste lösen das mit dem URL-Fragment-Trick. Ein Freigabelink sieht so aus:

https://hexatransfer.com/download/abc123#k=base64-encoded-256-bit-schluessel

Browser behandeln alles nach # als clientseitiges Fragment. Wenn Sie den Link anklicken, erhält der Server nur /download/abc123 in der HTTP-Anfrage – das Fragment verlässt Ihren Browser nie. JavaScript liest dann den Schlüssel aus dem Fragment und übergibt ihn an crypto.subtle.decrypt() der Web Crypto API.

Das ist einfacher als RSA-Schlüsselaustausch oder Diffie-Hellman und funktioniert für jeden mit einem Browser. Der Kompromiss: Jeder, der den Link erhält, erhält auch die Datei – Sie müssen Links also über einen sicheren Kanal teilen (Signal, persönlich, verschlüsselte E-Mail).

Was der Server sieht – und was nicht

Bei korrekt implementierter E2EE enthalten die Server-Logs typischerweise: eine zufällige Datei-ID, Chiffretext-Größe, Upload-IP, Upload-Zeitstempel und den SHA-256-Hash des Chiffretexts zur Deduplizierung. Nicht enthalten sind: Dateiname, Dateiinhalt, Identität des Empfängers oder Entschlüsselungsschlüssel. Dateinamen werden oft zusammen mit dem Inhalt verschlüsselt und als Teil des Chiffretext-Headers gespeichert.

Ein nützlicher Test: Fragen Sie den Anbieter, was er unter einem Beschluss aushändigen würde. Ein ehrlicher E2EE-Dienst antwortet: „Verschlüsselte Blobs und IP-Logs." Kann er Klartextdateien liefern, ist die Verschlüsselung nicht Ende-zu-Ende.

Die verwendeten Algorithmen

Echte E2EE-Stacks verwenden eine kurze Liste gut geprüfter Primitiven:

AES-256-GCM für die Massen-Dateiverschlüsselung. GCM liefert sowohl Vertraulichkeit als auch Authentifizierung, sodass manipulierter Chiffretext beim Entschlüsseln fehlschlägt statt Datenmüll zu produzieren.
PBKDF2 mit mindestens 100.000 Iterationen oder Argon2id für die Schlüsselableitung aus Benutzerpasswörtern bei passwortgeschützten Transfers.
SHA-256 für Integritätshashes.
TLS 1.3 als äußere Transportschicht – doppelt gesichert ist günstig.

Meiden Sie Dienste, die noch AES-CBC ohne HMAC (manipulierbar), MD5 oder SHA-1 (kompromittiert) oder PBKDF2 mit unter 10.000 Iterationen (auf modernen GPUs per Brute-Force angreifbar) verwenden.

E2EE für Dateitransfer vs. Messaging

Signal hat E2EE für Chat mit dem Double-Ratchet-Protokoll popularisiert, das Schlüssel nach jeder Nachricht für Forward Secrecy rotiert. Dateitransfer braucht diese Komplexität nicht, weil er einmalig ist – Sie führen kein laufendes Gespräch. Ein einzelner symmetrischer Schlüssel pro Datei, frisch für jeden Upload generiert, ist sowohl einfacher als auch leichter zu prüfen.

Was Dateitransfer braucht, was Messaging nicht braucht: fortsetzbare Chunk-Uploads (Dateien können 10 GB groß sein), Integritätsverifizierung über Chunks hinweg und Links, die ohne Konto des Empfängers funktionieren. Tresorit, Proton Drive, SwissTransfer und HexaTransfer verfolgen alle diesen Ansatz mit kleinen Variationen.

Prüfen, ob ein Dienst wirklich Ende-zu-Ende verschlüsselt

Vier praktische Tests, bevor Sie einem Anbieter vertrauen:

Öffnen Sie DevTools › Netzwerk beim Hochladen einer kleinen Datei. Sehen Sie den Klartext im Request-Body, ist keine clientseitige Verschlüsselung vorhanden.
Suchen Sie nach dem Schlüssel im URL-Fragment (nach #). Fehlt das Fragment-Schlüssel, hält der Server wahrscheinlich den Schlüssel.
Lesen Sie die Datenschutzerklärung auf Formulierungen wie „Wir können Ihre Dateien nicht einsehen", verbunden mit einer technischen Begründung.
Prüfen Sie, ob der Client-Code prüfbar ist – Open Source oder zumindest dokumentiert. Geschlossene Binärdateien mit E2EE-Behauptungen sind ein Warnsignal.

Dienste, die alle vier Tests bestehen: SwissTransfer (clientseitige Verschlüsselungsstufe), Tresorit Send, Proton Drive-Freigabelinks und HexaTransfer.

Wovor E2EE nicht schützt

E2EE ist kein Allheilmittel. Es schützt Sie nicht vor:

Einem kompromittierten Endpunkt. Hat Ihr Laptop Malware, liest der Angreifer Dateien, bevor sie verschlüsselt werden.
Weitergegebenen Freigabelinks. Jeder mit dem Link kann herunterladen und entschlüsseln.
Schwachen Passwörtern bei passwortgeschützten Transfers. PBKDF2 verlangsamt Brute-Force, aber „sommer2024" fällt trotzdem in Sekunden.
Metadaten-Korrelation. Zeitstempel, Dateigrößen und IP-Adressen können noch immer eine Geschichte erzählen.

Kombinieren Sie E2EE mit ablaufenden Links (24 Stunden ist ein sinnvoller Standard), Download-Limits (oft 1 bis 10 Downloads) und starken Passwörtern für sensible Transfers.

Praktischer Selbsttest

Als schnelle Überprüfung: Laden Sie eine 5-MB-Testdatei hoch, öffnen Sie den Freigabelink in einem privaten Fenster ohne das Fragment (löschen Sie alles nach #) und versuchen Sie, herunterzuladen. Ein echter E2EE-Dienst schlägt beim Entschlüsseln fehl. Öffnet sich die Datei trotzdem, hat der Server von Anfang an den Schlüssel gehalten.

Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.