Come funziona la crittografia end-to-end nel trasferimento file

La crittografia end-to-end per il trasferimento di file significa che i byte che lasciano il vostro dispositivo sono cifrati con una chiave che non tocca mai il server, e solo il destinatario previsto può decifrarli. Il server conserva solo testo cifrato, non vede nulla di significativo, e potrebbe essere violato senza esporre il contenuto del vostro file. Il GDPR, all'articolo 32, cita esplicitamente la cifratura come misura tecnica adeguata: il Garante per la protezione dei dati personali e l'ACN (Agenzia per la Cybersicurezza Nazionale) nelle proprie linee guida per la sicurezza dei sistemi informativi indicano la crittografia end-to-end come standard di riferimento per la trasmissione di dati personali. La ricetta crittografica prevede quasi sempre un cifrario simmetrico come AES-256-GCM o XChaCha20-Poly1305 per il file stesso, avvolto da uno scambio di chiavi come X25519 ECDH o RSA-OAEP per il materiale della chiave. Ecco esattamente come funziona in pratica.

Il modello di minaccia che la crittografia end-to-end affronta

La crittografia E2EE difende specificamente contro: il provider di trasferimento violato, intimato giudizialmente o malevolo; gli attaccanti di rete che intercettano il traffico TLS decifrato ai proxy; gli snapshot di backup del bucket di storage che cadono in mani sbagliate; e l'accesso insider da parte di dipendenti del servizio. Non difende contro il malware sul dispositivo del mittente o del destinatario, il phishing che cattura il link di decifratura, o gli account del destinatario compromessi. Comprendere il modello è importante, perché "cifrato" viene spesso usato impropriamente per indicare "TLS in transito più AES a riposo sul server", il che lascia al provider il controllo delle chiavi.

Crittografia simmetrica per il payload del file

I file vengono cifrati con un algoritmo simmetrico perché la crittografia a chiave pubblica è troppo lenta per i dati in blocco. La scelta moderna è AES-256-GCM, definita in NIST SP 800-38D, che fornisce sia confidenzialità che integrità autenticata in un unico passaggio. Una chiave casuale a 256 bit e un nonce univoco a 96 bit (mai riutilizzato con la stessa chiave) proteggono ogni file. XChaCha20-Poly1305, definito in RFC 8439 e RFC 8103, è un'alternativa spesso più veloce sui dispositivi privi di accelerazione hardware AES-NI, come i processori ARM più vecchi. Entrambi producono un testo cifrato più un tag di autenticazione a 128 bit che rileva qualsiasi manomissione.

Derivazione della chiave dalle password

Quando la crittografia E2EE usa una password, la password stessa non è mai la chiave di cifratura: sarebbe troppo debole contro gli attacchi a forza bruta. Invece, una funzione di derivazione della chiave come PBKDF2-HMAC-SHA256 con 600.000 o più iterazioni (guida OWASP 2025), Argon2id con m=19 MiB e t=2 (RFC 9106), o scrypt (RFC 7914) allunga la password in una chiave forte. Un salt casuale a 128 o 256 bit previene gli attacchi con rainbow table. La chiave risultante cifra il file. Il salt e il conteggio delle iterazioni vengono conservati con il testo cifrato così il destinatario può ricostruire la chiave quando inserisce la password.

Wrapping a chiave pubblica per i trasferimenti basati su account

Quando i destinatari hanno account con chiavi pubbliche pubblicate, non è necessario inserire una password. Il mittente genera una chiave casuale di cifratura del file (FEK), cifra il file con AES-256-GCM usando la FEK, poi cifra la FEK verso la chiave pubblica di ciascun destinatario usando l'accordo di chiave X25519 ECDH per RFC 7748 combinato con HKDF-SHA256 per RFC 5869 per derivare una chiave di wrapping, oppure RSA-OAEP per PKCS#1 v2.2 con SHA-256. La FEK avvolta sta accanto al testo cifrato. Solo il titolare della chiave privata del destinatario può svolgere la FEK e decifrare il file. Questo è il modello di Signal e WhatsApp per i messaggi, adattato per i payload di file.

Crittografia E2EE basata su link tramite frammenti URL

Un trucco elegante nei trasferimenti basati su browser consiste nel conservare la chiave di decifratura nel frammento URL (la parte dopo #). I frammenti non vengono mai inviati al server in una richiesta HTTP. Un link come https://hexatransfer.com/d/abc123#k=B9kZtR... porta l'ID del file lato server e la chiave lato client. Il browser scarica il testo cifrato, legge il frammento in JavaScript e decifra localmente. Il servizio non vede mai la chiave. L'avvertenza è che se il link trapela da qualche parte — log, screenshot, anteprime di app di messaggistica — la chiave trapela con esso.

Integrità con AEAD e hash

I modi di Authenticated Encryption with Associated Data (AEAD) come GCM e ChaCha20-Poly1305 prevengono la manomissione. Un singolo flip di bit nel testo cifrato causa il fallimento della validazione del tag di autenticazione, e la funzione di decifratura restituisce un errore invece di testo in chiaro spazzatura. Oltre all'AEAD, molte implementazioni calcolano un hash SHA-256 o BLAKE3 del testo in chiaro come voce del manifesto, così il destinatario può verificare dopo la decifratura che il file corrisponda all'intenzione del mittente. Questo è importante per i file di grandi dimensioni trasferiti in blocchi, dove una consegna parziale potrebbe altrimenti avere successo in alcune parti e fallire silenziosamente sulle ultime.

Crittografia a blocchi per file di grandi dimensioni

Cifrare un file da 10 GB in una singola operazione AES-GCM richiede di mantenere 10 GB di stato, il che è impraticabile nei browser. Le implementazioni reali dividono il file in blocchi — tipicamente da 1 MB a 16 MB ciascuno — e cifrano ogni blocco indipendentemente con una sotto-chiave derivata e un nonce basato su contatore. Lo strumento di crittografia age, definito su age-encryption.org, usa blocchi da 64 KB con ChaCha20-Poly1305. I confini dei blocchi consentono anche ai browser di eseguire la decifratura in streaming tramite la Streams API, avviando il download su disco prima che arrivi l'intero file, e supportano gli upload ripristinabili quando si verificano interruzioni di rete.

Sicurezza del trasporto in aggiunta alla crittografia E2EE

TLS 1.3, definito in RFC 8446, conta ancora in aggiunta alla crittografia E2EE — non per la confidenzialità del payload (il payload è già cifrato) ma per la privacy dei metadati: nomi dei file, dimensioni e tempistica. TLS 1.3 con scambio di chiavi forward-secret come X25519 significa che anche se la chiave a lungo termine del server viene compromessa in seguito, le sessioni registrate non possono essere decifrate. Il certificate pinning o il preload HSTS previene gli attacchi di downgrade. Insieme, E2EE più TLS 1.3 protegge sia il contenuto del file che il pattern operativo di chi sta inviando cosa a chi.

Errori comuni di implementazione

Tre errori ricorrono. Primo, il riutilizzo dei nonce con la stessa chiave in AES-GCM compromette catastroficamente la confidenzialità: usate sempre un nonce casuale fresco o un contatore che non si ripeta mai. Secondo, implementare la crittografia con routine fatte in casa invece di librerie verificate come libsodium, la Web Crypto API (SubtleCrypto) o BoringSSL: le operazioni a tempo costante sono importanti per prevenire gli attacchi di temporizzazione. Terzo, non autenticare i metadati del file insieme al contenuto: se l'identità del mittente, il nome del file o la lista dei destinatari non sono nell'AAD (Associated Authenticated Data), un attaccante può scambiare i metadati senza essere rilevato. HexaTransfer affronta questi problemi usando primitive Web Crypto standard lato client con pattern verificati.

Verificare se un servizio fa davvero la crittografia E2EE

Leggete le affermazioni di marketing con scetticismo. La vera crittografia E2EE significa che il provider non può decifrare i file nemmeno se costretto da un ordine del tribunale. Cercate documentazione tecnica pubblicata che descriva gli algoritmi esatti (AES-256-GCM, X25519, HKDF, conteggi delle iterazioni PBKDF2), codice client open source che possa essere verificato, e un modello di minaccia che riconosca cosa la crittografia E2EE difende e cosa no. I servizi che offrono il recupero della password lato server sui file cifrati non stanno facendo vera crittografia E2EE: tengono le chiavi. I servizi che affermano la "zero-knowledge" dovrebbero supportarla con una descrizione del protocollo crittografico, non solo con uno slogan.

Provalo su hexatransfer.com — gratuito, senza account, massimo 10 GB.