Cos'è la crittografia lato client? Il browser fa il lavoro

La crittografia lato client significa che il tuo browser o app cifra i file sul tuo dispositivo prima che qualsiasi cosa tocchi la rete. Il server riceve solo testo cifrato — l'output AES-256-GCM indistinguibile dal rumore casuale — e la chiave di decrittazione non lascia mai il client. Questo è l'opposto della crittografia lato server, dove il fornitore detiene le chiavi e tecnicamente può leggere i tuoi file. La Web Crypto API (window.crypto.subtle) rende questo possibile in qualsiasi browser moderno senza plugin, girando a circa 2–3 GB/s su hardware AES-NI. Servizi come HexaTransfer, SwissTransfer, Tresorit Send e Proton Drive usano questo modello per garantire che i file rimangano privati anche se il servizio stesso viene compromesso.

Il browser come motore crittografico

Cinque anni fa, la vera crittografia richiedeva l'installazione di un'app desktop o l'uso di PGP da riga di comando. La Web Crypto API, standardizzata dal W3C nel 2017, ha cambiato tutto. Espone AES-GCM, RSA-OAEP, ECDH, HMAC, PBKDF2 e SHA-256 direttamente a JavaScript in esecuzione in qualsiasi browser principale — Chrome, Firefox, Safari, Edge.

Le performance non sono più il problema. Le istruzioni Intel AES-NI raggiungono 3–5 GB/s per core per AES-256-GCM. Le Cryptography Extensions ARM sui chip Apple M-series e Qualcomm Snapdragon offrono un throughput simile. Cifrare un file da 1 GB nel browser richiede circa 300–500 ms su un laptop di fascia media.

La sfida rimanente è gestire file più grandi della memoria del browser. La Streams API e ReadableStream permettono al codice di elaborare i file in chunk da 4 MB, cifrando ogni chunk indipendentemente con un IV unico in modalità counter. È così che i servizi spingono il limite a 10 GB o più.

Un flusso minimo di crittografia lato client

Ecco la sequenza che un tipico servizio basato su browser esegue:

// 1. Genera una chiave AES casuale a 256 bit
const key = await crypto.subtle.generateKey(
  { name: "AES-GCM", length: 256 }, true, ["encrypt", "decrypt"]
);

// 2. Legge il file in chunk
const file = fileInput.files[0];
const chunkSize = 4 * 1024 * 1024;

// 3. Cifra ogni chunk con un IV unico a 12 byte
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. Carica [iv || ciphertext] sul server
}

// 5. Esporta la chiave e incorporala nel frammento URL di condivisione
const keyBytes = await crypto.subtle.exportKey("raw", key);
const shareUrl = `https://example.com/d/${fileId}#k=${base64url(keyBytes)}`;

Il server vede byte dall'aspetto casuale, un ID file e nient'altro. La chiave esiste solo nella memoria del browser dell'utente e nel frammento URL.

Perché questo supera la crittografia lato server

La crittografia lato server significa che il fornitore decifra su richiesta — per generare miniature, eseguire scansioni antivirus, elaborare query di ricerca o rispondere a richieste legali. Una divulgazione Apple del 2023 ha rivelato che i backup iCloud (che non erano end-to-end cifrati fino al lancio di Advanced Data Protection) erano accessibili ad Apple e quindi alle forze dell'ordine statunitensi con richieste valide.

La crittografia lato client ribalta questo. Poiché la chiave non raggiunge mai il fornitore:

I dipendenti disonesti non vedono nulla. L'ingegnere con accesso al database ottiene testo cifrato.
Le ingiunzioni producono testo cifrato. Il fornitore può rispettare i mandati consegnando il blob cifrato, inutile senza la chiave.
Le violazioni espongono testo cifrato. L'incidente LastPass del 2021 ha dimostrato l'importanza di questo — i vault rubati erano cifrati e solo gli utenti con password master deboli hanno affrontato un rischio reale.
I disservizi del fornitore non compromettono i dati. Anche se l'azienda chiude, la tua copia locale della chiave (l'URL) decifra ancora il file.

Cosa il server può ancora vedere

La crittografia lato client protegge il contenuto dei file ma non tutto. Il server tipicamente osserva:

Dimensione del file — la lunghezza del testo cifrato approssima quella del testo in chiaro (AES-GCM aggiunge 16 byte di overhead per cifratura, più l'IV a 12 byte).
Indirizzi IP di upload e download con timestamp.
Metadati di sessione dagli handshake TLS, incluso il TLS fingerprint del client.
Nomi di file cifrati — a meno che i nomi dei file non siano inclusi nel payload cifrato, potrebbero trapelare.

I buoni servizi lato client cifrano i nomi dei file come parte dell'header del testo cifrato e usano il padding a bucket (1 MB, 10 MB, 100 MB) per oscurare la dimensione. Tresorit e Proton Drive documentano esplicitamente la loro esposizione dei metadati.

Crittografia lato client protetta da password

Molti servizi permettono agli utenti di aggiungere una password in cima al frammento URL. Il flusso:

Il browser genera un salt casuale a 128 bit e deriva una chiave usando PBKDF2-HMAC-SHA-256 con 600.000 iterazioni (raccomandazione OWASP 2023) o Argon2id con memory=64 MB, iterations=3.
Il file viene cifrato con la chiave derivata.
Il salt va nel frammento URL; la password viene comunicata fuori banda.
Il destinatario digita la password, che ri-deriva la chiave localmente.

Questo trasforma una condivisione a canale singolo (l'URL è sufficiente) in a due fattori: l'aggressore ha bisogno sia del link che della password. PBKDF2 con 600.000 iterazioni rende il brute force offline costoso — circa 10 secondi per indovinata su una GPU moderna — quindi le password necessitano di 40+ bit di entropia per resistere agli aggressori determinati: pensa a 10+ caratteri da un alfabeto diversificato.

Il cambiamento della fiducia: dal servizio al codice client

La crittografia lato client sposta il confine di fiducia. Prima, ti fidavi del servizio per gestire bene il tuo testo in chiaro. Ora, ti fidi del JavaScript che il servizio spedisce al tuo browser ad ogni caricamento di pagina. Un aggiornamento malevolo potrebbe esfiltrare la chiave prima o durante la cifratura.

Esistono tre mitigazioni, con vari gradi di rigore:

Subresource Integrity (SRI) per i tag script garantisce che l'hash JS corrisponda a un valore noto.
Audit del codice da parte di aziende come Cure53, NCC Group o Trail of Bits verificano che la logica di cifratura sia corretta.
Build riproducibili permettono a terze parti di confermare che il codice distribuito corrisponde al sorgente pubblicato.
Intestazioni Content Security Policy (CSP) bloccano script di terze parti che potrebbero manomettere la cifratura.

L'approccio più rigoroso, usato da pmcrypto di Proton Mail e alcuni client basati su Electron, distribuisce binari firmati piuttosto che JavaScript fresco ad ogni visita. I servizi basati su browser negoziano un po' di questo rigore per la comodità dell'assenza di installazione.

Casi d'uso dove la crittografia lato client brilla

Alcuni scenari dove vale il primo caricamento leggermente più lento:

Documenti legali e medici. HIPAA 45 CFR § 164.312 e il privilegio avvocato-cliente traggono entrambi grande beneficio dalle architetture cieche al fornitore.
Giornalismo e protezione delle fonti. L'invio di documenti non redatti dove anche l'esposizione dei metadati comporta rischi.
Proprietà intellettuale aziendale. Pacchetti del consiglio di amministrazione, modelli finanziari, materiali M&A dove le minacce interne al fornitore di trasferimento file sono una preoccupazione realistica.
Documenti personali. Documenti fiscali, passaporti, referti medici — file che ti risulterebbe scomodo vedere in un headline di violazione del fornitore.

Per i file a bassa sensibilità (una foto di una riunione, una ricetta), la tradizionale crittografia lato server va bene.

Come riconoscere la vera crittografia lato client

Quattro segnali che un servizio implementa davvero la crittografia lato client:

I frammenti URL portano una chiave. L'URL di condivisione ha testo dopo # che sembra byte casuali codificati in base64.
Gli upload sono testo cifrato. Apri DevTools → Network durante l'upload; il corpo della richiesta dovrebbe sembrare byte casuali, non il tuo nome file.
I file grandi funzionano comunque velocemente. Un vero flusso lato client elabora i chunk in streaming; non ri-carica su un gateway di cifratura lato server.
L'informativa sulla privacy dice "non possiamo decifrare i tuoi file." Accompagnata da un white paper tecnico, non solo da testo di marketing.

Servizi che superano il test: il livello E2EE di SwissTransfer, Tresorit Send, i link condivisi di Proton Drive, Mega.nz e HexaTransfer. Servizi che non lo superano: WeTransfer (standard), Google Drive, i link di condivisione Dropbox.

Come metterlo in pratica

Se vuoi provare la crittografia lato client oggi, apri DevTools e guarda la scheda Network mentre carichi un file. Dovresti vedere un blob cifrato andare al server e una chiave nella barra degli indirizzi che non appare mai in nessuna richiesta. Questa è l'intera promessa.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.