Wat is client-side encryptie? Uw browser doet het werk

Client-side encryptie betekent dat je browser of app bestanden versleutelt op je apparaat voordat er iets het netwerk raakt. De server ontvangt alleen versleutelde tekst — AES-256-GCM-uitvoer die niet te onderscheiden is van willekeurige ruis — en de decoderingssleutel verlaat de client nooit. Dit is het tegenovergestelde van serverside versleuteling, waarbij de provider de sleutels bewaart en technisch gezien je bestanden kan lezen. De Web Crypto API (window.crypto.subtle) maakt dit mogelijk in elke moderne browser zonder plug-ins, draaiend op ongeveer 2–3 GB/s op AES-NI-hardware. Diensten als HexaTransfer, SwissTransfer, Tresorit Send en Proton Drive gebruiken dit model om te garanderen dat bestanden privé blijven zelfs als de service zelf wordt gecompromitteerd.

De browser als cryptografische motor

Vijf jaar geleden vereiste echte versleuteling het installeren van een desktopapp of het gebruik van PGP op de commandoregel. De Web Crypto API, gestandaardiseerd door W3C in 2017, veranderde dit. Het stelt AES-GCM, RSA-OAEP, ECDH, HMAC, PBKDF2 en SHA-256 rechtstreeks beschikbaar aan JavaScript dat in elke gangbare browser draait — Chrome, Firefox, Safari, Edge.

Prestaties zijn niet langer de bottleneck. Intel AES-NI-instructies halen 3–5 GB/s per kern voor AES-256-GCM. De Cryptografie-extensies van ARM op Apple M-serie en Qualcomm Snapdragon-chips leveren vergelijkbare doorvoer. Een bestand van 1 GB versleutelen in de browser duurt ruwweg 300–500 ms op een mid-range laptop.

De resterende uitdaging is het omgaan met bestanden groter dan het browsergeheugen. De Streams API en ReadableStream laten code bestanden verwerken in blokken van 4 MB, waarbij elk blok onafhankelijk wordt versleuteld met een unieke counter-mode IV. Zo kunnen services de grens optrekken naar 10 GB of meer.

Een minimale client-side versleutelingsflow

Hier is de volgorde die een typische browsergebaseerde service volgt:

// 1. Genereer een willekeurige 256-bits AES-sleutel
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]
);

// 2. Lees het bestand in blokken
const file = fileInput.files[0];
const chunkSize = 4 * 1024 * 1024;

// 3. Versleutel elk blok met een unieke 12-byte IV
for (let offset = 0; offset < file.size; offset += chunkSize) {
  const chunk = file.slice(offset, offset + chunkSize);
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv }, key, await chunk.arrayBuffer()
  );
  // 4. Upload [iv || ciphertext] naar de server
}

// 5. Exporteer de sleutel en embed die in het URL-fragment
const keyBytes = await crypto.subtle.exportKey("raw", key);
const shareUrl = `https://example.com/d/${fileId}#k=${base64url(keyBytes)}`;

De server ziet willekeurig uitziende bytes, een bestands-ID en verder niets. De sleutel bestaat alleen in het browsergeheugen van de gebruiker en het URL-fragment.

Waarom dit serverside versleuteling overtreft

Serverside versleuteling betekent dat de provider op verzoek ontsleutelt — om miniaturen te genereren, virusscannen uit te voeren, zoekopdrachten te verwerken of op juridische eisen te reageren. Een Apple-openbaarmaking in 2023 onthulde dat iCloud-back-ups (die niet end-to-end versleuteld waren totdat Advanced Data Protection werd geïntroduceerd) toegankelijk waren voor Apple en daarmee voor de Amerikaanse rechtshandhaving onder geldige verzoeken.

Client-side keert dit om. Omdat de sleutel de provider nooit bereikt:

• Malafide medewerkers zien niets. De engineer met databasetoegang krijgt versleutelde tekst.
• Gerechtelijke bevelen produceren versleutelde tekst. De provider kan voldoen aan bevelen door de versleutelde blob over te handigen, die nutteloos is zonder de sleutel.
• Inbreuken lekken versleutelde tekst. Het LastPass-incident van 2021 liet dit zien — gestolen kluizen waren versleuteld, en alleen gebruikers met zwakke hoofdwachtwoorden liepen echt risico.
• Provideruitval compromitteert geen gegevens. Zelfs als het bedrijf omvalt, ontsleutelt jouw lokale kopie van de sleutel (de URL) het bestand nog steeds.

Wat de server nog steeds kan zien

Client-side encryptie beschermt bestandsinhoud maar niet alles. De server waarneemt doorgaans:

• Bestandsgrootte — de versleutelde tekstlengte benadert de plaintext-lengte (AES-GCM voegt 16 bytes overhead toe per versleuteling, plus de 12-byte IV).
• Upload- en download-IP-adressen met tijdstempels.
• Sessiemetadata van TLS-handshakes, inclusief de TLS-vingerafdruk van de client.
• Versleutelde bestandsnamen — tenzij bestandsnamen zijn opgenomen in de versleutelde payload, kunnen ze lekken.

Goede client-side diensten versleutelen bestandsnamen als onderdeel van de versleutelde tekst-header en vullen op naar emmergroottes (1 MB, 10 MB, 100 MB) om grootte te verhullen. Tresorit en Proton Drive documenteren hun metadata-blootstelling expliciet.

Wachtwoordbeveiligde client-side encryptie

Veel diensten laten gebruikers een wachtwoord toevoegen bovenop het URL-fragment. De flow:

1. De browser genereert een willekeurig 128-bits salt en leidt een sleutel af met PBKDF2-HMAC-SHA-256 met 600.000 iteraties (OWASP 2023-aanbeveling) of Argon2id met memory=64 MB, iterations=3.
2. Het bestand wordt versleuteld met de afgeleide sleutel.
3. De salt gaat in het URL-fragment; het wachtwoord wordt buiten de band gecommuniceerd.
4. De ontvanger typt het wachtwoord, dat de sleutel lokaal opnieuw afleidt.

Dit maakt een enkelvoudig kanaal (URL is voldoende) tot tweefactorig: de aanvaller heeft zowel de link als het wachtwoord nodig. PBKDF2 met 600.000 iteraties maakt offline brute force ruwweg 10 seconden per gissing kosten op een moderne GPU, dus wachtwoorden hebben 40+ bits entropie nodig om vastberaden aanvallers te weerstaan — denk aan 10+ tekens uit een divers alfabet.

De vertrouwensverschuiving: van dienst naar clientcode

Client-side encryptie verschuift de grens van vertrouwen. Vroeger vertrouwde je de dienst om goed met je plaintext om te gaan. Nu vertrouw je de JavaScript die de dienst bij elke paginabezoek naar je browser stuurt. Een kwaadaardige update zou de sleutel kunnen exfiltreren vóór of tijdens versleuteling.

Drie mitigaties bestaan, in verschillende mate van strengheid:

• Subresource Integrity (SRI) voor scripttags zorgt ervoor dat de JS-hash overeenkomt met een bekende waarde.
• Codeaudits door bedrijven als Cure53, NCC Group of Trail of Bits verifiëren dat de versleutelingslogica klopt.
• Reproduceerbare builds laten onafhankelijke partijen bevestigen dat de geleverde code overeenkomt met gepubliceerde broncode.
• Content Security Policy (CSP)-headers blokkeren scripts van derden die kunnen knoeien met versleuteling.

De strengste aanpak, gebruikt door Proton Mail's pmcrypto en sommige Electron-gebaseerde clients, levert ondertekende binaire bestanden in plaats van verse JavaScript per bezoek. Browsergebaseerde diensten ruilen wat van deze strengheid in voor zero-install gemak.

Gebruikssituaties waar client-side uitblinkt

Een paar scenario's waarbij client-side encryptie de enigszins langzamere eerste laadtijd waard is:

• Juridische en medische documenten. HIPAA 45 CFR § 164.312 en advocaat-cliëntprivilege profiteren beiden sterk van voor-de-provider-blinde architecturen.
• Journalistiek en bronbescherming. Ongeredigeerde documenten verzenden waarbij zelfs metadata-blootstelling risico met zich meebrengt.
• Bedrijfs-IP. Bestuurspakketten, financiële modellen, fusie- en overnamematerialen waarbij insiderbedreigingen bij de bestandsoverdrachtsaanbieder een realistisch bezorgdheid zijn.
• Persoonlijke documenten. Belastingdocumenten, paspoorten, medische tests — bestanden die je ongemakkelijk zou vinden om in een persbericht over een inbreuk te zien.

Voor bestanden met weinig gevoeligheid (een vergaderingsfoto, een recept) is traditionele serverside versleuteling prima.

Echte client-side encryptie herkennen

Vier tekenen dat een dienst daadwerkelijk client-side versleuteling doet:

1. URL-fragmenten bevatten een sleutel. De deel-URL heeft tekst na # die eruitziet als base64-gecodeerde willekeurige bytes.
2. Uploads zijn versleutelde tekst. Open DevTools → Netwerk tijdens upload; de aanvraagtekst moet eruitzien als willekeurige bytes, niet als je bestandsnaam.
3. Grote bestanden werken nog steeds snel. Een echte client-side flow streamt blokken; het uploadt niet opnieuw naar een serverside versleutelingsgateway.
4. Het privacybeleid zegt "we kunnen je bestanden niet ontsleutelen." Gekoppeld aan een technisch witboek, niet alleen marketingtekst.

Diensten die doorstaan: de E2EE-laag van SwissTransfer, Tresorit Send, Proton Drive-gedeelde links, Mega.nz en HexaTransfer. Diensten die niet doorstaan: WeTransfer (standaard), Google Drive, Dropbox-deellinks.

Aan de slag

Als je client-side encryptie vandaag wilt uitproberen, open DevTools en bekijk het Netwerk-tabblad tijdens het uploaden van een bestand. Je zou een versleutelde blob naar de server moeten zien gaan en een sleutel in je adresbalk die nooit in een verzoek verschijnt. Dat is de hele belofte.

Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.