Zo werkt end-to-end versleuteling voor bestandsoverdracht

End-to-end versleuteling bij bestandsoverdracht houdt in dat de bytes die je apparaat verlaten, versleuteld zijn met een sleutel die nooit de server bereikt — en dat alleen de beoogde ontvanger ze kan ontsleutelen. De AVG verplicht organisaties passende technische maatregelen te nemen om persoonsgegevens te beschermen; end-to-end versleuteling (E2EE) is daarvoor het krachtigste instrument dat er bestaat. De server slaat uitsluitend versleutelde data op, ziet niets bruikbaars en kan gehackt worden zonder dat de inhoud van je bestanden wordt blootgesteld. Het cryptografische recept combineert vrijwel altijd een symmetrisch cijfer zoals AES-256-GCM of XChaCha20-Poly1305 voor het bestand zelf, en een sleuteluitwisseling zoals X25519 ECDH of RSA-OAEP voor het sleutelmateriaal.

Welk bedreigingsmodel E2EE daadwerkelijk verdedigt

E2EE verdedigt specifiek tegen: de overdrachtsaanbieder die gehackt, gedagvaard of kwaadwillend is; aanvallers op het netwerk die TLS-gedecrypteerd verkeer bij proxies onderscheppen; back-upsnapshots van de opslagbucket die in verkeerde handen vallen; en insidertoegang door medewerkers van de dienst. Het verdedigt niet tegen malware op het apparaat van de afzender of ontvanger, phishing die de decryptielink onderschept, of gecompromitteerde ontvangeraccounts. Het onderscheid is cruciaal, want "versleuteld" wordt vaak misbruikt om "TLS onderweg plus AES in rust op de server" te beschrijven — een configuratie waarbij de aanbieder de sleutels bezit.

Symmetrische versleuteling voor de bestandsinhoud

Bestanden worden versleuteld met een symmetrisch algoritme, omdat publieke-sleutelcryptografie te traag is voor grote hoeveelheden data. De moderne keuze is AES-256-GCM, gedefinieerd in NIST SP 800-38D, die zowel vertrouwelijkheid als geauthenticeerde integriteit in één stap levert. Een willekeurige 256-bit sleutel en een unieke 96-bit nonce (nooit hergebruikt met dezelfde sleutel) beschermen elk bestand. XChaCha20-Poly1305, gedefinieerd in RFC 8439 en RFC 8103, is een alternatief dat vaak sneller is op apparaten zonder AES-NI-hardwareversnelling, zoals oudere ARM-processors. Beide produceren een versleuteld bericht plus een 128-bit authenticatietag die eventuele manipulatie detecteert.

Sleutelafleiding uit wachtwoorden

Wanneer E2EE een wachtwoord gebruikt, is het wachtwoord zelf nooit de versleutelingssleutel — dat zou te kwetsbaar zijn voor brute-force aanvallen. In plaats daarvan strekt een sleutelafgeleide functie zoals PBKDF2-HMAC-SHA256 met 600.000 of meer iteraties (OWASP 2025-richtlijn), Argon2id (RFC 9106) of scrypt (RFC 7914) het wachtwoord tot een sterke sleutel. Een willekeurig 128-bit of 256-bit salt voorkomt rainbow-table aanvallen. De resulterende sleutel versleutelt het bestand. Het salt en het iteratieaantal worden opgeslagen bij de versleutelde data, zodat de ontvanger de sleutel opnieuw kan berekenen wanneer hij het wachtwoord invoert.

Publieke-sleutelwrapping voor accountgebaseerde overdrachten

Wanneer ontvangers accounts hebben met gepubliceerde publieke sleutels, is wachtwoordinvoer niet nodig. De afzender genereert een willekeurige bestandsversleutelingssleutel (FEK), versleutelt het bestand met AES-256-GCM, en versleutelt daarna de FEK naar de publieke sleutel van elke ontvanger via X25519 ECDH-sleutelovereenkomst (conform RFC 7748) gecombineerd met HKDF-SHA256 (conform RFC 5869), of RSA-OAEP conform PKCS#1 v2.2 met SHA-256. Alleen de houder van de privésleutel van de ontvanger kan de FEK ontsleutelen en het bestand lezen. Dit is het Signal- en WhatsApp-model voor berichten, aangepast voor bestandsinhoud.

Linkgebaseerde E2EE via URL-fragmenten

Een slimme techniek in browsergebaseerde overdracht is het opslaan van de decryptiesleutel in het URL-fragment — het deel na het hekje. Fragmenten worden nooit meegestuurd naar de server in een HTTP-verzoek. Een link zoals https://example.com/d/abc123#k=B9kZtR... draagt de bestands-ID server-side en de sleutel client-side. De browser downloadt de versleutelde data, leest het fragment in JavaScript en decrypteert lokaal. De dienst ziet de sleutel nooit. Het voorbehoud: als de link ergens uitlekt — via logs, schermafbeeldingen of berichtvoorbeelden — lekt de sleutel mee.

Integriteit met AEAD en hashes

AEAD-modi (Authenticated Encryption with Associated Data) zoals GCM en ChaCha20-Poly1305 voorkomen manipulatie. Één bitomkering in de versleutelde data zorgt ervoor dat de authenticatietag de validatie niet doorstaat, en de decryptiefunctie geeft een fout terug in plaats van onjuiste leesbare tekst. Bovenop AEAD berekenen veel implementaties een SHA-256 of BLAKE3 hash van de leesbare tekst als manifest, zodat de ontvanger na decryptie kan verifiëren dat het bestand overeenkomt met wat de afzender bedoelde. Dit is extra relevant voor grote bestanden die in stukken overgedragen worden.

Gelaagde versleuteling voor grote bestanden

Een bestand van 10 GB in één AES-GCM-bewerking versleutelen vereist 10 GB werkgeheugen — onpraktisch in browsers. Echte implementaties splitsen het bestand in chunks van doorgaans 1 MB tot 16 MB, en versleutelen elk stuk afzonderlijk met een afgeleide subsleutel en een op tellers gebaseerde nonce. Het age-versleutelingsgereedschap gebruikt 64 KB-chunks met ChaCha20-Poly1305. Chunkgrenzen laten browsers ook streaming-decryptie uitvoeren via de Streams API, zodat het downloaden naar schijf begint voordat het hele bestand is aangekomen, en hervatbare uploads ondersteunen bij netwerkonderbrekingen.

Transportbeveiliging bovenop E2EE

TLS 1.3, gedefinieerd in RFC 8446, is nog steeds nodig naast E2EE — niet voor vertrouwelijkheid van de inhoud (die is al versleuteld), maar voor privacybescherming van metadata: bestandsnamen, groottes en tijdspatronen. TLS 1.3 met forward-secret sleuteluitwisseling via X25519 betekent dat zelfs bij later gecompromitteerde serversleutels opgenomen sessies niet ontsleuteld kunnen worden. Het NCSC beveelt TLS 1.3 uitdrukkelijk aan in zijn ICT-beveiligingsrichtlijnen. Samen beschermen E2EE plus TLS 1.3 zowel de bestandsinhoud als het patroon van wie wat naar wie verstuurt.

Veelvoorkomende implementatiefouten

Drie fouten komen steeds terug. Ten eerste: nonces hergebruiken met dezelfde sleutel in AES-GCM, wat vertrouwelijkheid rampzalig verbreekt — gebruik altijd een verse willekeurige nonce of een teller die nooit herhaalt. Ten tweede: cryptografie implementeren met zelfgemaakte routines in plaats van gecontroleerde bibliotheken zoals libsodium, de Web Crypto API (SubtleCrypto) of BoringSSL; constante-tijdoperaties zijn essentieel om timing-aanvallen te voorkomen. Ten derde: bestandsmetadata niet authenticeren samen met de inhoud — als de identiteit van de afzender, de bestandsnaam of de ontvangerlijst niet in de AAD (Associated Authenticated Data) zit, kan een aanvaller metadata onopgemerkt verwisselen. HexaTransfer pakt dit aan door standaard Web Crypto-primitieven client-side te gebruiken met gereviende patronen.

Controleren of een dienst daadwerkelijk E2EE biedt

Lees marketingclaims kritisch. Echte E2EE betekent dat de aanbieder bestanden niet kan ontsleutelen, zelfs niet op rechterlijk bevel van de Autoriteit Persoonsgegevens (AP) of een andere toezichthouder. Zoek naar gepubliceerde technische documentatie met de exacte algoritmen — AES-256-GCM, X25519, HKDF, PBKDF2-iteratieaantallen — open-source clientcode die gecontroleerd kan worden, en een bedreigingsmodel dat aangeeft waartegen E2EE wel en niet beschermt. Diensten die herstel van serverpasswords voor versleutelde bestanden aanbieden, doen geen echte E2EE: zij bezitten de sleutels.

Probeer het op https://hexatransfer.com — gratis, geen account, maximaal 10 GB.