Crittografia end-to-end spiegata: guida per principianti

La crittografia end-to-end (E2EE) significa che il tuo file viene scramblato sul tuo dispositivo con una chiave che solo il destinatario può ricostruire. Il servizio di trasferimento sposta testo cifrato ma non detiene mai la chiave di decrittazione, quindi il personale, gli hacker e le citazioni in giudizio governative non possono leggere il contenuto. In pratica, il tuo browser genera una chiave AES casuale a 256 bit, cifra il file localmente, carica il testo cifrato e inserisce la chiave nel link di condivisione dopo il frammento # — che i browser non inviano mai al server. Questo è l'intero trucco, ed è ciò che separa la privacy reale dal marketing.

Cosa significa davvero "end-to-end"

I due "end" sei tu e il tuo destinatario. Tutto in mezzo — i router ISP, gli edge CDN, i server dell'azienda di trasferimento, l'ISP del destinatario — sta nel mezzo. Con l'E2EE, questi hop intermedi vedono solo byte cifrati. Confronta questo con la sola crittografia a livello di trasporto (TLS): TLS protegge i dati dal tuo browser al server, poi il server li decifra, memorizza il testo in chiaro e li ricifra quando il destinatario scarica. Il livello standard di WeTransfer funziona così. L'azienda può (e per legge statunitense ed europea a volte deve) consegnare i file su richiesta.

Con E2EE, anche se un procuratore consegna al provider un mandato, il provider non ha nulla da consegnare tranne byte dall'aspetto casuale. Questa proprietà è il motivo per cui giornalisti, avvocati e medici la richiedono sempre di più.

Perché solo TLS non è sufficiente

TLS 1.3 è eccellente in quello che fa: impedire a un attaccante in un bar o a un ISP disonesto di spiare la connessione. Ma TLS termina al server. Una volta che il tunnel cifrato finisce, il server elabora il file grezzo. Se quel server viene compromesso — come è successo a Dropbox nel 2022 quando codice sorgente e alcuni dati dei clienti sono trapelati — TLS offre zero protezione per i file seduti in storage.

L'E2EE aggiunge un secondo strato che sopravvive alla compromissione del server. Il file è cifrato prima di toccare il filo e rimane cifrato fino a quando il browser del destinatario non lo decifra. Anche un dump completo del database rivela solo testo cifrato e metadati.

Il problema dello scambio di chiavi, risolto

La parte complicata dell'E2EE è far arrivare la chiave al destinatario senza che il server la veda. I servizi moderni basati su browser risolvono questo con il trucco del frammento URL. Un link di condivisione si presenta così:

https://hexatransfer.com/download/abc123#k=chiave-256-bit-base64

I browser trattano tutto ciò che sta dopo # come un frammento lato client. Quando fai clic sul link, il server riceve solo /download/abc123 nella richiesta HTTP — il frammento non lascia mai il tuo browser. JavaScript poi legge la chiave dal frammento, recupera il testo cifrato e lo decifra localmente usando il metodo crypto.subtle.decrypt() della Web Crypto API.

Questo è più semplice dello scambio di chiavi RSA o Diffie-Hellman e funziona per chiunque abbia un browser. Il compromesso: chiunque ottenga il link ottiene il file, quindi devi ancora condividere i link attraverso un canale sicuro (Signal, di persona, un'email cifrata).

Cosa vede il server e cosa non può vedere

Con E2EE correttamente implementata, i log del server contengono tipicamente: un ID file casuale, la dimensione del testo cifrato, l'IP di upload, il timestamp di upload e l'hash SHA-256 del testo cifrato per la deduplicazione. Non vede: il nome del file, il contenuto del file, l'identità del destinatario o la chiave di decrittazione. I nomi dei file sono spesso cifrati insieme al contenuto e memorizzati come parte dell'intestazione del testo cifrato.

Un test utile: chiedi al provider cosa consegnerebbe sotto un mandato. Un servizio E2EE onesto dirà "blob cifrati e log IP." Se possono produrre file in chiaro, la crittografia non è end-to-end.

Gli algoritmi sotto il cofano

Le implementazioni E2EE reali convergono su un breve elenco di primitive ben verificate:

• AES-256-GCM per la crittografia in blocco dei file. GCM fornisce sia riservatezza che autenticazione, quindi il testo cifrato manomesso non riesce a decifrarsi piuttosto che produrre spazzatura.
• PBKDF2 con almeno 100.000 iterazioni, o Argon2id, per derivare le chiavi dalle password degli utenti quando viene aggiunta la protezione con password.
• SHA-256 per gli hash di integrità.
• TLS 1.3 come trasporto esterno, perché la doppia protezione è economica.

Evita i servizi che usano ancora AES-CBC senza HMAC (malleabile), MD5 o SHA-1 (rotti), o PBKDF2 con meno di 10.000 iterazioni (bruteforce-able su GPU moderne).

E2EE per il trasferimento di file vs. la messaggistica

Signal ha reso popolare l'E2EE per le chat usando il protocollo Double Ratchet, che ruota le chiavi dopo ogni messaggio per la forward secrecy. Il trasferimento di file non ha bisogno di quella complessità perché è un'operazione unica — non stai mantenendo una conversazione continua. Una singola chiave simmetrica per file, generata nuova per ogni upload, è sia più semplice che più facile da verificare.

Quello di cui il trasferimento di file ha bisogno e la messaggistica no: upload a chunk riprendibili (i file possono essere da 10 GB), verifica dell'integrità tra i chunk, e link che funzionano senza che il destinatario abbia un account. Tresorit, Proton Drive, SwissTransfer e HexaTransfer adottano tutti questo approccio con variazioni minori.

Verificare se un servizio è davvero end-to-end

Quattro test pratici prima di fidarsi di un provider:

1. Apri DevTools > Network mentre carichi un piccolo file. Se vedi il testo in chiaro nel corpo della richiesta, non è cifrato lato client.
2. Cerca la chiave nel frammento URL (dopo #). Nessuna chiave di frammento di solito significa che il server detiene la chiave.
3. Leggi l'informativa sulla privacy per il linguaggio come "non possiamo accedere ai tuoi file" abbinato a una descrizione tecnica del perché.
4. Controlla se il codice client è verificabile — open source o almeno documentato. I binari chiusi con affermazioni E2EE sono una bandiera gialla.

I servizi che superano tutti e quattro: SwissTransfer (livello di crittografia lato client), Tresorit Send, i link di condivisione di Proton Drive e HexaTransfer.

Cosa l'E2EE non protegge

L'E2EE non è magica. Non ti protegge da:

• Un endpoint compromesso. Se il tuo laptop ha malware, l'attaccante legge i file prima della crittografia.
• Link di condivisione trapelati. Chiunque abbia il link può scaricare e decifrare.
• Password deboli sui trasferimenti protetti da password. PBKDF2 rallenta il brute force, ma "estate2024" cade in secondi.
• Correlazione dei metadati. Timestamp, dimensioni dei file e indirizzi IP possono ancora raccontare una storia.

Abbina l'E2EE a link con scadenza (24 ore è un valore predefinito sensato), limiti di download (spesso da 1 a 10 download) e password forti per i trasferimenti sensibili.

Mettila alla prova

Per un rapido controllo di sanità: carica un file di test da 5 MB, apri il link di condivisione in una finestra privata senza il frammento (elimina tutto ciò che segue #), e prova a scaricare. Un vero servizio E2EE non riuscirà a decifrare. Se il file si apre comunque, il server deteneva la chiave dall'inizio.

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