Wie Transferify Dateien in deinem Browser verschlüsselt
Jede Datei, die du mit Transferify sendest, wird in deinem Browser verschlüsselt, bevor auch nur ein Byte davon dein Gerät verlässt. Das Verfahren ist AES-256-GCM, ausgeführt von der Web Crypto API, die in deinen Browser eingebaut ist, und der Schlüssel entsteht für jeden Transfer auf deinem Gerät. Die Sendemodi unterscheiden sich nur in einem Punkt: wohin dieser Schlüssel danach geht.
Hier erklären wir den Mechanismus für alle, die ihn nachvollziehen wollen: wie der Schlüssel entsteht, wie eine Datei zerteilt und versiegelt wird, was verhindert, dass eine gespeicherte Datei verändert wird, und wer sie in welchem Modus öffnen kann.
Der Schlüssel entsteht auf deinem Gerät
Wenn du einen Transfer startest, fordert dein Browser bei der Web Crypto API einen neuen, zufälligen 256-Bit-AES-Schlüssel an. Ein Schlüssel deckt alle Dateien ab, die du zusammen sendest. Dateien, die du später zu einem gehosteten Transfer hinzufügst, bekommen einen eigenen, neuen Schlüssel.
Der Schlüssel wird nicht aus deiner E-Mail-Adresse, deinem Konto oder einem Passwort abgeleitet, also lässt sich nichts über dich nutzen, um ihn zu erraten.
Dateien werden als Datenstrom verschlüsselt, in Stücken
Dein Browser liest jede Datei als Datenstrom und verschlüsselt sie Stück für Stück. So lässt sich auch eine Datei verschlüsseln, die weit größer ist als der Arbeitsspeicher deines Geräts, ohne sie ganz zu laden.
- Gehostete Transfers nutzen für die meisten Dateien Stücke von 8 MiB.
- Sehr große gehostete Dateien nutzen ein größeres Stück, ein ganzzahliges Vielfaches von 8 MiB bis 256 MiB, damit die Datei in die Speichergrenze von 10.000 Teilen pro Datei passt.
- Peer-to-Peer-Transfers nutzen standardmäßig Stücke von 32 KiB, damit jedes verschlüsselte Stück in eine einzige Datenkanal-Nachricht passt, die jede WebRTC-Gegenstelle annimmt.
Jedes Stück wird mit AES-256-GCM versiegelt, das es verschlüsselt und ein 16 Byte langes Authentifizierungs-Tag anhängt. Ändert sich ein einziges Bit des Stücks, passt das Tag nicht mehr, und die Entschlüsselung weist das Stück ab.
Jedes Stück ist an seinen Platz gebunden
Stücke einzeln zu verschlüsseln lässt eine Lücke, wenn nichts jedes Stück an seine Position bindet: Wer die gespeicherte Kopie hat, könnte die Stücke umstellen, das letzte weglassen oder ein Stück aus einer anderen Datei einschieben. Zwei Dinge schließen diese Lücke.
Eine eigene Nonce für jedes Stück. AES-GCM braucht für jedes Stück, das es versiegelt, eine Nonce, also eine Zahl, die nur einmal verwendet wird. Der verschlüsselte Datenstrom jeder Datei beginnt mit einem 8-Byte-Wert, den dein Browser für diese Datei wählt und in den Kopf des Datenstroms schreibt, und jedes Stück hängt seinen eigenen 4-Byte-Zähler an. Innerhalb einer Datei teilen sich keine zwei Stücke eine Nonce. Zwischen Dateien sind die 8-Byte-Werte zufällig oder aus einem Geheimnis abgeleitet, das dein Browser hält, also ist eine Wiederholung verschwindend unwahrscheinlich. Eine Nonce unter demselben Schlüssel wiederzuverwenden ist das Einzige, was bei AES-GCM nie passieren darf.
Authentifizierte Positionsdaten. Jedes Stück wird zusammen mit einem kurzen Etikett versiegelt, das den Transfer, die Datei und den Index des Stücks nennt und angibt, ob es das letzte Stück der Datei ist. Das Etikett wird nicht mit dem Stück gespeichert. Der Browser des Empfängers baut es für die Datei, die er angefordert hat, selbst nach, also lässt sich ein Stück nur genau an der Stelle entschlüsseln, für die es versiegelt wurde.
| Wäre die gespeicherte Kopie ... | Was beim Download passiert |
|---|---|
| Auch nur um ein Bit verändert | Dieses Stück besteht die Tag-Prüfung nicht, und der Download stoppt |
| Umgestellt | Der Index des Stücks passt nicht, also schlägt die Prüfung fehl |
| Mit einem Stück einer anderen Datei oder eines anderen Transfers vertauscht | Die Datei oder der Transfer im Etikett passt nicht, also schlägt die Prüfung fehl |
| Gekürzt | Das neue letzte Stück wurde als „nicht das letzte“ versiegelt, also schlägt die Prüfung fehl |
| Um zusätzliche Daten verlängert | Das echte letzte Stück ist nicht mehr das letzte, also schlägt die Prüfung fehl |
| Mit einer anderen Größe gemeldet | Die entschlüsselte Größe wird mit der Größe verglichen, die der Download angekündigt hat, also schlägt die Prüfung fehl |
Eine fehlgeschlagene Prüfung stoppt den Download und verwirft, was gerade geschrieben wurde. Ein Empfänger bekommt also die exakte Datei oder einen Fehler, nie eine stillschweigend beschädigte Kopie.
Die Browser der Absender schreiben dieses Etikett seit Oktober 2026. Dateien, die davor gespeichert wurden, tragen ein früheres Etikett, das nur den Transfer und den Index des Stücks nennt, und die Browser der Empfänger lesen sie weiterhin.
Wohin der Schlüssel geht: drei Fälle
Die Datei wird in jedem Fall gleich verschlüsselt. Was sich unterscheidet, ist, wie der Empfänger den Schlüssel bekommt.
| Was wir vergleichen | Gehostet, Standard | Gehostet, Zero-Knowledge | Peer-to-Peer |
|---|---|---|---|
| Wie der Schlüssel zum Empfänger kommt | Von uns eingepackt und gespeichert, von unserem Dienst ausgepackt, wenn der Link geöffnet wird | Nur im Link, nach dem „#“ | Nur im Link, nach dem „#“ |
| Was wir speichern | Die verschlüsselte Datei und den Schlüssel, eingepackt mit einem Schlüssel im AWS Key Management Service | Nur die verschlüsselte Datei | Nichts: Die Datei wird nie auf unseren Servern gespeichert |
| Wer sonst den Schlüssel bekommen kann | Unser Dienst, über den Schlüsselverwaltungsdienst | Niemand | Niemand |
| Kann Transferify die Datei entschlüsseln? | Ja, technisch | Nein | Nein |
Gehostet, Standardmodus: Der Schlüssel wird für unseren Dienst eingepackt
Im Standardmodus packt dein Browser den Dateischlüssel ein, bevor irgendetwas gesendet wird. Er verschlüsselt den Schlüssel mit RSA-OAEP (SHA-256) unter der öffentlichen Hälfte eines 3072-Bit-RSA-Schlüsselpaars, dessen private Hälfte im AWS Key Management Service (KMS) liegt. Der rohe Schlüssel ist nie Teil einer Anfrage. Den eingepackten Schlüssel speichern wir im Datensatz der Datei.
Wenn ein Empfänger den Link öffnet, prüft unser Dienst zuerst, dass der Link nicht abgelaufen ist und dass das Passwort stimmt, falls du eines gesetzt hast. Erst dann bittet er KMS, den Schlüssel auszupacken, und gibt ihn über HTTPS an den Browser des Empfängers zurück. Die Entschlüsselung übernimmt der Browser des Empfängers. Unser Dienst entschlüsselt keine Dateiinhalte.
In diesem Modus sind wir also technisch in der Lage, eine gehostete Datei zu entschlüsseln, und das sagen wir auch. Dafür bekommst du einen kurzen Link ohne Schlüssel darin, einen Link, den du aus deiner Transferliste erneut kopieren kannst, und Links, die unser Dienst per E-Mail an deine Empfänger senden kann. Ein Passwort, das du in diesem Modus setzt, wird an unseren Dienst gesendet, nur als Hash gespeichert und geprüft, bevor der Schlüssel herausgegeben wird.
Gehostet, Zero-Knowledge-Modus: Der Schlüssel bleibt im Link
Im Zero-Knowledge-Modus sendet dein Browser überhaupt kein Schlüsselmaterial. Der Schlüssel kommt in den Freigabelink, hinter das Zeichen „#“. Browser senden diesen Teil einer Adresse nicht mit, wenn sie eine Seite anfordern, also erhalten unsere Server ihn nie. Die Seite des Empfängers liest den Schlüssel aus dem Link, entfernt ihn sofort aus der Adressleiste und entschlüsselt den Download auf dem Gerät des Empfängers.
Setzt du zusätzlich ein Passwort, trägt der Link statt des rohen Schlüssels einen eingepackten Schlüssel. Dein Browser leitet aus dem Passwort mit PBKDF2 (SHA-256, 600.000 Durchläufe, ein zufälliges 16-Byte-Salt) einen Schlüssel zum Einpacken ab und versiegelt damit den Dateischlüssel. Der Browser des Empfängers wiederholt das mit dem Passwort, das er eingibt. Das Passwort und der rohe Schlüssel erreichen uns nie, und ein falsches Passwort scheitert einfach beim Auspacken auf dem Gerät des Empfängers.
Weil der Schlüssel nur im Link existiert, kann unser Dienst einen Zero-Knowledge-Link nicht per E-Mail an deine Empfänger senden: Die E-Mail würde einen Link ohne seinen Schlüssel enthalten. Einen Zero-Knowledge-Link teilst du selbst, über einen Kanal, dem du vertraust.
Peer-to-Peer: doppelt verschlüsselt
Ein Peer-to-Peer-Transfer wird nie auf unseren Servern gespeichert. Dein Browser erzeugt trotzdem für jeden Instant-Transfer einen Schlüssel, setzt ihn hinter das „#“ im Link und versiegelt damit jedes Stück, bevor es in die WebRTC-Verbindung geht. Diese Verbindung ist selbst mit DTLS verschlüsselt. Den Grund für die zweite Schicht erklärt wie ein Peer-to-Peer-Transfer funktioniert.
Was die Verschlüsselung abdeckt und was nicht
Die Verschlüsselung schützt den Inhalt deiner Dateien. Was unser Dienst verarbeitet, um einen Transfer auszuführen, steht in unserer Datenschutzerklärung.
Zwei weitere Grenzen sollte man klar benennen:
- Ein Link funktioniert für jeden, der ihn hat. Teile ihn also nur dort, wo du auch die Datei teilen würdest, und schicke ein Passwort über einen anderen Kanal.
- Verschlüsselung im Browser kann eine Datei nicht auf einem Gerät schützen, das bereits kompromittiert ist, auf keiner der beiden Seiten.
Probier es aus
Die Verschlüsselung läuft bei jedem Transfer, auf jedem Plan, ohne dass du etwas einrichten musst. Sende jetzt eine Datei, und der Schlüssel entsteht in deinem Browser in dem Moment, in dem du startest.
Häufige Fragen
Werden meine Dateien verschlüsselt, bevor sie mein Gerät verlassen?
Ja. Jede gehostete und jede Peer-to-Peer-Datei wird in deinem Browser mit AES-256-GCM verschlüsselt, bevor auch nur ein Byte davon gesendet wird, auf jedem Plan. Es gibt keinen Weg, eine Datei unverschlüsselt zu senden.
Kann Transferify meine Dateien entschlüsseln?
Im standardmäßigen gehosteten Modus technisch ja. Wir verwahren den Dateischlüssel, eingepackt mit einem Schlüssel, der im AWS Key Management Service liegt, und wenn ein Empfänger den Link öffnet, packt unser Dienst ihn aus und gibt ihn an dessen Browser. So funktioniert ein kurzer Link ohne Schlüssel darin. Im Zero-Knowledge-Modus und bei Peer-to-Peer-Transfers reist der Schlüssel nur im Teil des Links nach dem „#“, den Browser nicht an Server senden, also erhalten wir ihn nie.
Was passiert, wenn jemand die gespeicherte Datei verändert?
Der Download schlägt fehl, statt eine beschädigte Datei zu liefern. Jedes Stück trägt ein Authentifizierungs-Tag, das an seine Position, seine Datei und seinen Transfer gebunden ist, also lässt sich eine veränderte, umgestellte, vertauschte oder gekürzte Datei nicht entschlüsseln.