Versleutelingsmethoden voor bestandsoverdracht in detail
Technische vergelijking van versleutelingsmethoden voor bestandsoverdracht, waaronder AES-256, RSA, ChaCha20 en end-to-end versus server-side benaderingen.
Bestandsoverdrachtdiensten gebruiken in 2026 vijf hoofdbenaderingen voor versleuteling: alleen TLS (gegevens versleuteld tijdens transport maar leesbaar op de server), server-side AES-256 in rust (provider beheert de sleutels), client-side AES-256-GCM via Web Crypto API (end-to-end, sleutel in URL-fragment), XChaCha20-Poly1305 stroomversleuteling (verlengde nonce, gebruikt door libsodium en Tresorit) en OpenPGP hybride versleuteling (Curve25519 ECC + AES-256 sessiesleutels, gebruikt door Proton). De juiste keuze hangt af van dreigingsmodel, prestatievereisten en regelgeving. Deze vergelijking legt uit wat elke methode doet en waar elke methode faalt.
De vijf versleutelingsmodellen
Model één: alleen TLS 1.3. Het bestand versleutelt tijdens netwerktransport en staat vervolgens als leesbare tekst op de server. Voorbeelden: basis FTP over TLS (FTPS), elke HTTP POST-upload zonder in-rust-versleuteling. Beschermt tegen passief meeluisteren op het netwerk, beschermt tegen niets anders.
Model twee: TLS + server-side in rust. AES-256 versleutelt het opgeslagen bestand; de provider beheert de hoofdsleutel (vaak in AWS KMS, GCP Cloud KMS of equivalent). Voorbeelden: WeTransfer, SwissTransfer, Dropbox. Beschermt tegen diefstal van koude opslag, beschermt niet tegen insider-toegang, dagvaarding of live serverkompromittering.
Model drie: client-side E2EE met symmetrische sleutel. De browser of client leidt een 256-bit sleutel af, versleutelt met AES-256-GCM en plaatst de sleutel in een URL-fragment of buiten-band kanaal. Voorbeelden: HexaTransfer, Send (Firefox Send-protocol-nakomelingen). De server ziet alleen versleutelde tekst en kan deze onder geen enkele omstandigheid ontsleutelen.
Model vier: geauthenticeerde stroomcijfers. XChaCha20-Poly1305 gebruikt 24-byte nonces (versus 12-byte in ChaCha20-Poly1305), waardoor birthday-bound-botsingen onhaalbaar zijn bij zeer grote bestanden. Voorbeelden: libsodium secretbox (Internxt), Tresorit Send. Gekozen wanneer AES-NI hardwareversnelling niet universeel is (oudere Android-apparaten, IoT) omdat ChaCha20 snel draait in software.
Model vijf: hybride publieke sleutel + symmetrisch. OpenPGP (RFC 9580, revisie 2024) gebruikt ECC Curve25519 of RSA-4096 om een per-bestand AES-256 sessiesleutel te versleutelen. Voorbeelden: Proton Drive, traditionele GPG-bestandsversleuteling. Maakt asymmetrisch sleutelbeheer mogelijk; geen gedeeld geheim nodig tussen verzender en ontvanger als je de openbare sleutel van de ontvanger hebt.
AES-256 versus ChaCha20: wat werkelijk verschilt
Beide zijn 256-bit symmetrische cijfers. AES-256 is de NIST-standaard (FIPS 197) en heeft hardwareversnelling (AES-NI op x86, ARM Cryptography Extensions op mobiel). Op moderne hardware draait AES-256-GCM op 2-4 GB/s per kern. ChaCha20-Poly1305 draait op 1-2 GB/s per kern in pure software — sneller dan AES op hardware zonder AES-NI. Voor een desktop die een 4 GB-bestand versleutelt voltooien beide het werk in minder dan twee seconden; het netwerk is de bottleneck. Cryptografisch worden beide in 2026 als even veilig beschouwd.
RSA is grotendeels dood in bestandsoverdracht
RSA-4096 versleutelt 512 byte per operatie. RSA direct gebruiken om een 1 GB-bestand te versleutelen is absurd; je zou het in miljoenen blokken van 512 byte moeten verdelen. Het patroon is altijd hybride: RSA omhult een per-bestand AES-256 sessiesleutel, AES versleutelt de inhoud. ECC Curve25519 heeft RSA in de meeste nieuwe ontwerpen vervangen omdat het sneller is, kleinere sleutels heeft (256-bit ECC staat gelijk aan 3072-bit RSA-beveiliging) en bestand is tegen timingaanvallen. OpenPGP in 2024 beveelt nu Curve25519 (X25519 voor sleuteluitwisseling) aan boven RSA. RSA tref je nog aan in legacy SFTP-implementaties.
Waarom URL-fragment sleutels belangrijk zijn
HexaTransfer en de Firefox Send-protocollijn plaatsen de versleutelingssleutel in het URL-fragment (het deel na #). Browsers zijn gespecificeerd (RFC 3986) om fragmenten nooit te verzenden in het HTTP-verzoek. Dat betekent dat de server een verzoek ontvangt zoals GET /bestand/abc123 maar het fragment met de sleutel nooit ziet. Wanneer de gebruiker de volledige URL plakt of erop klikt, blijft het fragment in het geheugen van de browser en stuurt de client-side ontsleuteling aan. Dit is de architectureel elegante manier om een deelbare E2EE-link te leveren zonder een zijkanaal.
End-to-end versus server-side: de dreigingsmodeltest
Server-side versleuteling beschermt tegen één ding: fysieke diefstal van het opslagapparaat. Als de schijf gestolen wordt, houdt AES-256 in rust de gegevens onleesbaar totdat iemand het KMS compromitteert. End-to-end versleuteling beschermt tegen alles wat de server zou kunnen doen: dagvaarding, insider-toegang, ransomware die live gegevens bereikt of staatsdwang. Als je dreigingsmodel "schijf gestolen uit datacentrum" is, is server-side prima. Als het "overheid, tegenstander of concurrent dwingt de dienst gegevens af te staan" is, beschermt alleen E2EE je.
Geauthenticeerde versleuteling is niet optioneel
Gewone AES-CBC zonder MAC maakt padding oracle-aanvallen mogelijk (BEAST, Lucky13) die versleutelde tekst kunnen ontsleutelen met chosen-ciphertext-queries. Moderne bestandsoverdracht moet AEAD gebruiken: AES-256-GCM (NIST SP 800-38D) of ChaCha20-Poly1305 (RFC 8439). De Poly1305-tag of GCM-tag authenticeert de versleutelde tekst en eventuele bijbehorende gegevens (bestandsgrootte, nonce, bestandsnaamheader). Als een bit omslaat tijdens transport, mislukt ontsleuteling luid. Wie in 2026 nog AES-CBC verzendt zonder HMAC-wrapper leeft in 2010.
Sleutelafleiding voor wachtwoordbeveiligde overdrachten
Wanneer een gebruiker een wachtwoord typt om een overdracht te beveiligen, kun je het wachtwoord niet rechtstreeks als AES-sleutel gebruiken. Het heeft lage entropie en is vatbaar voor brute force. Moderne sleutelafleiding: PBKDF2-SHA-256 met 600.000 iteraties (OWASP 2023-aanbeveling), scrypt met N=2^17, of Argon2id met 19 MiB geheugen en 2 iteraties. HexaTransfer gebruikt PBKDF2 met 600.000 iteraties. Tresorit gebruikt Argon2id. Beide weerstaan GPU-versneld wachtwoord kraken. Providers die nog PBKDF2 gebruiken met 10.000 iteraties (richtlijn 2015) zijn onderbeveiligd.
Vergelijkingstabel
| Methode | Vertrouwelijkheid | Authenticatie | Server ziet leesbare tekst | Kwantumrisico | |---|---|---|---|---| | Alleen TLS 1.3 | Tijdens transport | Ja (MAC in cipher suite) | Ja | Sleuteluitwisseling kwetsbaar | | Server-side AES-256 | In rust + tijdens transport | Ja | Ja (heeft sleutel) | Laag | | Client-side AES-256-GCM | Volledig pad | Ja (GCM-tag) | Nee | Laag | | XChaCha20-Poly1305 | Volledig pad | Ja (Poly1305-tag) | Nee | Laag | | OpenPGP (Curve25519 + AES-256) | Volledig pad | Ja (MDC/OCB) | Nee | Curve25519 kwetsbaar |
Post-kwantumoverwegingen
Shors algoritme bedreigt Curve25519 en RSA zodra grote kwantumcomputers bestaan. Symmetrische cijfers (AES-256, ChaCha20) worden verzwakt maar niet gebroken door Grovers algoritme; 256-bit sleutels behouden 128-bit post-kwantumsterkte, nog steeds onhaalbaar. NIST standaardiseerde ML-KEM (Kyber) in 2024 voor post-kwantum sleutelinkapseling. Signal migreerde in 2023 naar PQXDH. Bestandsoverdrachtdiensten hebben post-kwantum nog niet breed geadopteerd, maar het risicovenster ("nu oogsten, later ontsleutelen") betekent dat langetermijnarcheven vandaag al 256-bit symmetrische versleuteling moeten gebruiken.
Een methode kiezen
Eenmalige gevoelige overdracht, korte bewaartijd: client-side AES-256-GCM met URL-fragment sleutels. HexaTransfer is de implementatie. Doorlopende compliance-gereguleerde workflows: XChaCha20-Poly1305 met auditlogboeken (Tresorit). Meerdere ontvangers met sleutelbeheer: OpenPGP (Proton Drive, GPG). Grote gedecentraliseerde distributie: libsodium secretbox plus erasure coding (Internxt op Storj). Niet-gevoelig, hoog volume: TLS + in rust is aanvaardbaar.
Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.
Verstuur grote bestanden veilig met end-to-end-versleuteling
Draag bestanden tot 10 GB gratis over met end-to-end-versleuteling. Geen account nodig. Uw bestanden worden in uw browser versleuteld voordat ze worden geüpload — niemand anders kan ze lezen.
Een bestand verzenden