Verschlüsselungsmethoden für Dateiübertragung im Detailvergleich
Technischer Vergleich von Verschlüsselungsmethoden für die Dateiübertragung: AES-256, RSA, ChaCha20 sowie Ende-zu-Ende vs. serverseitige Ansätze.
Dienste zur Dateiübertragung setzen 2026 auf fünf Verschlüsselungsansätze: reines TLS (Daten während des Transits verschlüsselt, auf dem Server jedoch im Klartext), serverseitiges AES-256 im Ruhezustand (Anbieter hält die Schlüssel), clientseitiges AES-256-GCM über die Web Crypto API (Ende-zu-Ende, Schlüssel im URL-Fragment), XChaCha20-Poly1305-Stromverschlüsselung (erweitertes Nonce, genutzt von libsodium und Tresorit) sowie OpenPGP-Hybridverschlüsselung (Curve25519 ECC + AES-256-Session-Schlüssel, eingesetzt von Proton). Die richtige Wahl hängt vom Bedrohungsmodell, den Performance-Anforderungen und regulatorischen Vorgaben ab. Dieser Vergleich erklärt, was jeder Ansatz leistet — und wo er versagt.
Die fünf Verschlüsselungsmodelle
Modell eins: Nur TLS 1.3. Die Datei wird während der Übertragung verschlüsselt und liegt danach unverschlüsselt auf dem Server. Beispiele: einfaches FTP über TLS (FTPS), jeder HTTP-POST-Upload ohne Ruhezustand-Verschlüsselung. Schützt gegen passives Mithören im Netzwerk — sonst gegen nichts.
Modell zwei: TLS + serverseitige Ruhezustand-Verschlüsselung. AES-256 verschlüsselt die gespeicherte Datei; der Anbieter hält den Hauptschlüssel (häufig in AWS KMS, GCP Cloud KMS oder vergleichbaren Systemen). Beispiele: WeTransfer, SwissTransfer, Dropbox. Schützt gegen physischen Diebstahl des Speichermediums — nicht aber gegen Insider-Zugriff, behördliche Anordnungen oder kompromittierte Live-Server.
Modell drei: Clientseitige E2EE mit symmetrischem Schlüssel. Browser oder Client leitet einen 256-Bit-Schlüssel ab, verschlüsselt mit AES-256-GCM und platziert den Schlüssel im URL-Fragment oder einem Seitenkanal. Beispiele: HexaTransfer, Send (Firefox-Send-Protokoll-Nachfolger). Der Server sieht ausschließlich Chiffretext und kann unter keinen Umständen entschlüsseln.
Modell vier: Authentifizierte Stromchiffren. XChaCha20-Poly1305 verwendet 24-Byte-Nonces (gegenüber 12-Byte bei ChaCha20-Poly1305), wodurch Birthday-Bound-Kollisionen bei sehr großen Dateien ausgeschlossen sind. Beispiele: libsodium secretbox (Internxt), Tresorit Send. Wird bevorzugt, wenn AES-NI-Hardware-Beschleunigung nicht universell verfügbar ist (ältere Android-Geräte, IoT), da ChaCha20 in reiner Software schnell läuft.
Modell fünf: Hybrid-Public-Key + symmetrisch. OpenPGP (RFC 9580, Revision 2024) verwendet ECC Curve25519 oder RSA-4096, um einen dateiweiten AES-256-Session-Schlüssel zu verschlüsseln. Beispiele: Proton Drive, klassische GPG-Dateiverschlüsselung. Ermöglicht asymmetrisches Schlüsselmanagement; kein gemeinsames Geheimnis zwischen Sender und Empfänger erforderlich, sofern der öffentliche Schlüssel vorliegt.
AES-256 vs. ChaCha20: Die eigentlichen Unterschiede
Beide sind 256-Bit-Symmetriechiffren. AES-256 ist der NIST-Standard (FIPS 197) und verfügt über Hardware-Beschleunigung (AES-NI auf x86, ARM Cryptography Extensions auf Mobilgeräten). Auf moderner Hardware läuft AES-256-GCM mit 2–4 GB/s pro Kern. ChaCha20-Poly1305 erreicht in reiner Software 1–2 GB/s pro Kern — auf Hardware ohne AES-NI ist es schneller als AES. Für einen Desktop, der eine 4-GB-Datei verschlüsselt, sind beide in unter zwei Sekunden fertig; das Netzwerk ist der Engpass, nicht die Kryptografie. Kryptografisch gelten beide in 2026 als gleichwertig sicher.
RSA ist bei Dateiübertragungen weitgehend überholt
RSA-4096 verschlüsselt pro Operation 512 Byte Klartext. RSA direkt zum Verschlüsseln einer 1-GB-Datei einzusetzen wäre absurd — die Datei müsste in Millionen 512-Byte-Blöcke fragmentiert werden. Das Muster lautet daher stets: RSA umhüllt einen dateiweiten AES-256-Session-Schlüssel, AES verschlüsselt den Inhalt. ECC Curve25519 hat RSA in den meisten neuen Designs abgelöst, weil es schneller ist, kleinere Schlüssel hat (256-Bit ECC entspricht der Sicherheit von 3072-Bit RSA) und gegen Timing-Angriffe resistent ist. OpenPGP empfiehlt seit 2024 Curve25519 (X25519 für den Schlüsselaustausch) gegenüber RSA. RSA taucht noch in Legacy-SFTP-Deployments auf.
Warum URL-Fragment-Schlüssel entscheidend sind
HexaTransfer und die Firefox-Send-Protokoll-Linie platzieren den Verschlüsselungsschlüssel im URL-Fragment (dem Teil nach #). Browser sind per Spezifikation (RFC 3986) angewiesen, Fragmente niemals in der HTTP-Anfrage zu übertragen. Der Server empfängt eine Anfrage wie GET /file/abc123, sieht das den Schlüssel enthaltende Fragment jedoch nie. Klickt der Nutzer die vollständige URL an oder fügt sie ein, verbleibt das Fragment im Browserspeicher und ermöglicht die clientseitige Entschlüsselung. Das ist die architektonisch elegante Methode, einen teilbaren E2EE-Link ohne Seitenkanal bereitzustellen.
Ende-zu-Ende vs. serverseitig: Der Bedrohungsmodell-Test
Serverseitige Verschlüsselung schützt gegen genau eine Sache: physischen Diebstahl des Speichermediums. Ist die Festplatte gestohlen, hält die AES-256-Ruhezustand-Verschlüsselung Daten opak, bis jemand das KMS kompromittiert. Ende-zu-Ende-Verschlüsselung schützt gegen alles, was der Server tun könnte: behördliche Anordnungen, Insider-Zugriff, Ransomware auf Live-Daten oder staatlichen Zwang. Lautet das Bedrohungsmodell „Festplatte wird aus einem Rechenzentrum gestohlen", ist serverseitig ausreichend. Lautet es „Behörde, Angreifer oder Konkurrent zwingt den Dienst zur Datenherausgabe", schützt nur E2EE.
Authentifizierte Verschlüsselung ist nicht optional
Reines AES-CBC ohne MAC ermöglicht Padding-Oracle-Angriffe (BEAST, Lucky13), die Chiffretext mit Chosen-Ciphertext-Anfragen entschlüsseln können. Moderne Dateiübertragung muss AEAD verwenden: AES-256-GCM (NIST SP 800-38D) oder ChaCha20-Poly1305 (RFC 8439). Der Poly1305-Tag oder GCM-Tag authentifiziert den Chiffretext und zugehörige Daten (Dateigröße, Nonce, Dateiname-Header). Kippt ein Bit im Transit, schlägt die Entschlüsselung lautstark fehl. Wer 2026 noch AES-CBC ohne HMAC-Wrapper ausliefert, lebt kryptografisch im Jahr 2010.
Schlüsselableitung bei passwortgeschützten Übertragungen
Wenn ein Nutzer ein Passwort zum Schutz einer Übertragung eingibt, darf das Passwort nicht direkt als AES-Schlüssel verwendet werden. Es hat geringe Entropie und ist anfällig für Brute-Force. Moderne Schlüsselableitung: PBKDF2-SHA-256 mit 600.000 Iterationen (OWASP-Empfehlung 2023), scrypt mit N=2^17 oder Argon2id mit 19 MiB Speicher und 2 Iterationen. HexaTransfer verwendet PBKDF2 mit 600.000 Iterationen. Tresorit verwendet Argon2id. Beide widerstehen GPU-beschleunigtem Passwortknacken. Anbieter, die noch PBKDF2 mit 10.000 Iterationen (Leitlinie von 2015) einsetzen, sind unzureichend abgesichert.
Vergleichstabelle
| Methode | Vertraulichkeit | Authentifizierung | Server sieht Klartext | Quantenrisiko | |---|---|---|---|---| | Nur TLS 1.3 | Im Transit | Ja (MAC in Cipher-Suite) | Ja | Schlüsselaustausch gefährdet | | Serverseitiges AES-256 | Ruhezustand + Transit | Ja | Ja (hält Schlüssel) | Gering | | Clientseitiges AES-256-GCM | Vollständiger Pfad | Ja (GCM-Tag) | Nein | Gering | | XChaCha20-Poly1305 | Vollständiger Pfad | Ja (Poly1305-Tag) | Nein | Gering | | OpenPGP (Curve25519 + AES-256) | Vollständiger Pfad | Ja (MDC/OCB) | Nein | Curve25519 gefährdet |
Post-Quanten-Überlegungen
Shors Algorithmus bedroht Curve25519 und RSA, sobald leistungsfähige Quantencomputer existieren. Symmetrische Chiffren (AES-256, ChaCha20) werden durch Grovers Algorithmus geschwächt, aber nicht gebrochen; 256-Bit-Schlüssel behalten 128-Bit-Post-Quanten-Stärke, die nach heutigem Stand undurchführbar ist. NIST hat 2024 ML-KEM (Kyber) für Post-Quanten-Schlüsselkapselung standardisiert. Signal migrierte 2023 zu PQXDH. Dienste zur Dateiübertragung haben Post-Quanten noch nicht breit übernommen, aber das Risikofenster („Jetzt ernten, später entschlüsseln") zeigt: Langfristig archivierte Daten sollten schon heute mit 256-Bit-Symmetrieverschlüsselung gesichert werden.
Die passende Methode wählen
Einmalige vertrauliche Übertragung, kurze Aufbewahrung: clientseitiges AES-256-GCM mit URL-Fragment-Schlüsseln — HexaTransfer ist die Implementierung. Laufende DSGVO-regulierte Workflows: XChaCha20-Poly1305 mit Audit-Logs (Tresorit). Mehrere Empfänger mit Schlüsselmanagement: OpenPGP (Proton Drive, GPG). Große dezentrale Verteilung: libsodium secretbox plus Erasure Coding (Internxt auf Storj). Nicht-sensible Hochvolumen-Übertragungen: TLS + Ruhezustand-Verschlüsselung ist akzeptabel.
Auf hexatransfer.com testen — kostenlos, ohne Konto, bis 10 GB.
Große Dateien sicher mit Ende-zu-Ende-Verschlüsselung senden
Übertragen Sie Dateien bis zu 10 GB kostenlos mit Ende-zu-Ende-Verschlüsselung. Kein Konto erforderlich. Ihre Dateien werden in Ihrem Browser verschlüsselt, bevor sie hochgeladen werden — niemand sonst kann sie lesen.
Datei senden