End-to-end-encryptie uitgelegd: een gids voor beginners
Wat is end-to-end-encryptie en waarom is het belangrijk? Leer hoe E2EE uw gedeelde bestanden beschermt.
End-to-end-encryptie (E2EE) betekent dat je bestand op je eigen apparaat versleuteld wordt met een sleutel die alleen de ontvanger kan reconstrueren. De overdrachtsservice verplaatst versleutelde tekst maar heeft nooit de decoderingssleutel — dus medewerkers, hackers en gerechtelijke bevelen kunnen de inhoud niet lezen. In de praktijk genereert je browser een willekeurige 256-bits AES-sleutel, versleutelt het bestand lokaal, uploadt de versleutelde tekst en plaatst de sleutel in de deellink na het #-fragment — dat browsers nooit naar de server sturen. Dat is de hele truc, en het is wat echte privacy onderscheidt van marketingpraat.
Wat "end-to-end" werkelijk betekent
De twee "uiteinden" ben jij en je ontvanger. Alles daartussenin — ISP-routers, CDN-edges, de servers van de overdrachtsservice, de ISP van de ontvanger — bevindt zich in het midden. Met E2EE zien die tussenstops alleen versleutelde bytes. Vergelijk dit met transportlaagversleuteling alleen (TLS): TLS beschermt gegevens van je browser naar de server, waarna de server ze ontsleutelt, de plaintext opslaat en opnieuw versleutelt wanneer de ontvanger downloadt. De standaardlaag van WeTransfer werkt zo. Het bedrijf kan (en moet wettelijk soms) bestanden overhandigen op verzoek.
Met E2EE, zelfs als een openbaar aanklager de provider een bevel overhandigt, heeft de provider niets te leveren behalve willekeurig uitziende bytes. Deze eigenschap is waarom journalisten, advocaten en artsen er steeds vaker op staan.
Waarom TLS alleen niet voldoende is
TLS 1.3 is uitstekend in wat het doet: voorkomen dat een koffieshop-aanvaller of malafide ISP de verbinding afluistert. Maar TLS eindigt bij de server. Zodra de versleutelde tunnel eindigt, verwerkt de server het onbewerkte bestand. Als die server wordt gehackt — zoals bij Dropbox in 2022 toen broncode en klantdata lekten — biedt TLS nul bescherming voor bestanden in opslag.
E2EE voegt een tweede laag toe die een servercompromis overleeft. Het bestand is versleuteld voordat het de kabel raakt en blijft versleuteld totdat de browser van de ontvanger het ontsleutelt. Zelfs een volledige databasedump onthult alleen versleutelde tekst en metadata.
Het sleuteluitwisselingsprobleem, opgelost
Het lastige deel van E2EE is de sleutel naar de ontvanger krijgen zonder dat de server hem ziet. Moderne browsergebaseerde diensten lossen dit op met de URL-fragmenttruc. Een deellink ziet er zo uit:
https://hexatransfer.com/download/abc123#k=base64-encoded-256-bit-key
Browsers behandelen alles na # als een client-side fragment. Wanneer je op de link klikt, ontvangt de server alleen /download/abc123 in het HTTP-verzoek — het fragment verlaat je browser nooit. JavaScript leest vervolgens de sleutel uit het fragment, haalt de versleutelde tekst op en ontsleutelt die lokaal met de Web Crypto API's crypto.subtle.decrypt().
Dit is eenvoudiger dan RSA-sleuteluitwisseling of Diffie-Hellman en werkt voor iedereen met een browser. De afweging: iedereen die de link krijgt, krijgt het bestand, dus je moet links nog steeds via een veilig kanaal delen (Signal, persoonlijk, een versleutelde e-mail).
Wat de server ziet versus wat hij niet kan zien
Met correct geïmplementeerde E2EE bevatten serverlogboeken doorgaans: een willekeurige bestands-ID, de grootte van de versleutelde tekst, upload-IP, uploadtijdstempel en de SHA-256-hash van de versleutelde tekst voor deduplicatie. Hij ziet niet: de bestandsnaam, de bestandsinhoud, de identiteit van de ontvanger of de decoderingssleutel. Bestandsnamen worden vaak samen met de inhoud versleuteld en opgeslagen als onderdeel van de versleutelde tekst-header.
Een nuttige test: vraag de provider wat hij zou overhandigen bij een bevel. Een eerlijke E2EE-dienst zegt "versleutelde blobs en IP-logboeken." Als ze leesbare bestanden kunnen produceren, is de versleuteling niet end-to-end.
Algoritmen onder de motorkap
Echte E2EE-stacks convergeren op een korte lijst van goed geauditeerde primitieven:
- AES-256-GCM voor bulkbestandsversleuteling. GCM biedt zowel vertrouwelijkheid als authenticatie, zodat gemanipuleerde versleutelde tekst niet ontsleutelt in plaats van rommel te produceren.
- PBKDF2 met minimaal 100.000 iteraties, of Argon2id, voor het afleiden van sleutels uit gebruikerswachtwoorden wanneer wachtwoordbeveiliging wordt toegevoegd.
- SHA-256 voor integriteitscontrolehashes.
- TLS 1.3 als buitenste transport, omdat belt-and-suspenders goedkoop is.
Vermijd diensten die nog steeds AES-CBC zonder HMAC gebruiken (vervormbaar), MD5 of SHA-1 (gebroken), of PBKDF2 met minder dan 10.000 iteraties (brute-forceerbaar op moderne GPU's).
E2EE voor bestandsoverdracht versus berichten
Signal populariseerde E2EE voor chat met het Double Ratchet-protocol, dat sleutels roteert na elk bericht voor forward secrecy. Bestandsoverdracht heeft die complexiteit niet nodig omdat het eenmalig is — je onderhoudt geen doorlopend gesprek. Één symmetrische sleutel per bestand, vers gegenereerd voor elke upload, is zowel eenvoudiger als gemakkelijker te auditeren.
Wat bestandsoverdracht nodig heeft dat berichten niet hebben: hervatteerbare chunked uploads (bestanden kunnen 10 GB zijn), integriteitsverificatie over chunks en links die werken zonder dat de ontvanger een account heeft. Tresorit, Proton Drive, SwissTransfer en HexaTransfer nemen allemaal deze aanpak met kleine variaties.
Controleren of een dienst werkelijk end-to-end is
Vier praktische tests voordat je een provider vertrouwt:
- Open DevTools → Netwerk tijdens het uploaden van een klein bestand. Als je de plaintext in de aanvraagtekst ziet, is het niet client-side versleuteld.
- Zoek naar de sleutel in het URL-fragment (na
#). Geen fragmentsleutel betekent meestal dat de server de sleutel heeft. - Lees het privacybeleid op taalgebruik als "we kunnen je bestanden niet openen" gekoppeld aan een technische beschrijving waarom.
- Controleer of de clientcode auditeerbaar is — open source of minimaal gedocumenteerd. Gesloten binaire bestanden met E2EE-claims zijn een gele vlag.
Diensten die alle vier doorstaan: SwissTransfer (client-side versleutelingslaag), Tresorit Send, Proton Drive-deellinks en HexaTransfer.
Wat E2EE niet beschermt
E2EE is geen wondermiddel. Het beschermt je niet tegen:
- Een gecompromitteerd eindpunt. Als je laptop malware heeft, leest de aanvaller bestanden vóór versleuteling.
- Gelekte deellinks. Iedereen met de link kan downloaden en ontsleutelen.
- Zwakke wachtwoorden op wachtwoordbeveiligde overdrachten. PBKDF2 vertraagt brute force, maar "zomer2024" valt nog steeds in seconden.
- Metadatacorrelatie. Tijdstempels, bestandsgroottes en IP-adressen kunnen nog steeds een verhaal vertellen.
Combineer E2EE met verlopende links (24 uur is een verstandige standaard), downloadlimieten (vaak 1–10 downloads) en sterke wachtwoorden voor gevoelige overdrachten.
Zelf testen
Voor een snelle praktijktest: upload een testbestand van 5 MB, open de deellink in een privévenster zonder het fragment (verwijder alles na #) en probeer te downloaden. Een echte E2EE-dienst kan niet ontsleutelen. Als het bestand toch opent, had de server de sleutel altijd al.
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