Metodi di crittografia per il trasferimento file a confronto
Confronto tecnico dei metodi di crittografia per il trasferimento file: AES-256, RSA, ChaCha20 e approcci end-to-end vs lato server.
I servizi di trasferimento file nel 2026 usano cinque principali approcci di crittografia: solo TLS (dati cifrati in transito ma in chiaro sul server), AES-256 at-rest lato server (il provider detiene le chiavi), AES-256-GCM lato client via Web Crypto API (end-to-end, chiave nel frammento URL), crittografia stream XChaCha20-Poly1305 (nonce esteso, usato da libsodium e Tresorit) e crittografia ibrida OpenPGP (ECC Curve25519 + chiavi di sessione AES-256, usato da Proton). La scelta giusta dipende dal modello di minaccia, dai vincoli di performance e dai requisiti normativi. Questo confronto spiega cosa fa ciascun approccio e dove fallisce.
I cinque modelli di crittografia
Modello uno: solo TLS 1.3. Il file si cifra durante il transito di rete e poi rimane in chiaro sul server. Esempi: FTP base su TLS (FTPS), qualsiasi upload HTTP POST senza crittografia at-rest. Protegge dall'intercettazione passiva della rete, non protegge da altro.
Modello due: TLS + at-rest lato server. AES-256 cifra il file archiviato; il provider detiene la master key (spesso in AWS KMS, GCP Cloud KMS o equivalente). Esempi: WeTransfer, SwissTransfer, Dropbox. Protegge contro il furto di cold storage, non protegge contro l'accesso privilegiato interno, le ingiunzioni giudiziarie o la compromissione del server live.
Modello tre: E2EE lato client con chiave simmetrica. Il browser o il client deriva una chiave a 256 bit, cifra con AES-256-GCM e inserisce la chiave nel frammento URL o in un canale out-of-band. Esempi: HexaTransfer, i discendenti del protocollo Firefox Send. Il server vede solo testo cifrato e non può decifrare in nessuna circostanza.
Modello quattro: cifrari stream autenticati. XChaCha20-Poly1305 usa nonce da 24 byte (contro i 12 byte di ChaCha20-Poly1305), rendendo infeasibili le collisioni birthday-bound su file molto grandi. Esempi: libsodium secretbox (Internxt), Tresorit Send. Scelto quando l'accelerazione hardware AES-NI non è universale (dispositivi Android datati, IoT) perché ChaCha20 gira velocemente in software.
Modello cinque: ibrido chiave pubblica + simmetrica. OpenPGP (RFC 9580, revisione 2024) usa ECC Curve25519 o RSA-4096 per cifrare una chiave di sessione AES-256 per file. Esempi: Proton Drive, crittografia file GPG tradizionale. Abilita la gestione asimmetrica delle chiavi; nessun segreto condiviso necessario tra mittente e destinatario se si dispone della chiave pubblica del destinatario.
AES-256 vs ChaCha20: cosa differisce davvero
Entrambi sono cifrari simmetrici a 256 bit. AES-256 è lo standard NIST (FIPS 197) e ha accelerazione hardware (AES-NI su x86, ARM Cryptography Extensions su mobile). Su hardware moderno, AES-256-GCM gira a 2-4 GB/s per core. ChaCha20-Poly1305 gira a 1-2 GB/s per core in software puro, più veloce di AES su hardware senza AES-NI. Per un desktop che cifra un file da 4 GB, entrambi finiscono in meno di due secondi; la rete è il collo di bottiglia. Crittograficamente, entrambi sono considerati ugualmente sicuri nel 2026.
RSA è per lo più obsoleto nel trasferimento file
RSA-4096 cifra 512 byte di plaintext per operazione. Usare RSA direttamente per cifrare un file da 1 GB è assurdo; bisognerebbe frammentare in milioni di blocchi da 512 byte. Il pattern è sempre ibrido: RSA avvolge una chiave di sessione AES-256 per file, AES cifra il contenuto. ECC Curve25519 ha sostituito RSA nella maggior parte dei nuovi design perché è più veloce, usa chiavi più piccole (ECC a 256 bit equivale a sicurezza RSA a 3072 bit) ed è resistente agli attacchi di timing. OpenPGP nel 2024 raccomanda ora Curve25519 (X25519 per lo scambio di chiavi) sopra RSA. RSA lo trovi ancora nei deployment SFTP legacy.
Perché le chiavi nel frammento URL sono importanti
HexaTransfer e la discendenza del protocollo Firefox Send inseriscono la chiave di crittografia nel frammento URL (la parte dopo #). I browser sono specificati (RFC 3986) per non trasmettere mai i frammenti nella richiesta HTTP. Ciò significa che il server riceve una richiesta tipo GET /file/abc123 ma non vede mai il frammento contenente la chiave. Quando l'utente incolla o clicca sull'URL completo, il frammento rimane nella memoria del browser e alimenta la decifratura lato client. Questo è il modo architetturalmente elegante per consegnare un link E2EE condivisibile senza un canale ausiliario.
E2EE vs lato server: il test del modello di minaccia
La crittografia lato server protegge da una cosa: il furto fisico del dispositivo di archiviazione. Se il disco viene rubato, la crittografia AES-256 at-rest mantiene i dati opachi finché qualcuno non compromette il KMS. La crittografia end-to-end protegge da tutto ciò che il server potrebbe fare: ingiunzione giudiziaria, accesso privilegiato interno, ransomware che raggiunge i dati live o coercizione statale. Se il tuo modello di minaccia è "un disco viene rubato da un data center," il lato server va bene. Se è "un governo, un avversario o un concorrente costringe il servizio a consegnare i dati," solo l'E2EE ti protegge.
La crittografia autenticata non è opzionale
AES-CBC semplice senza MAC consente attacchi padding oracle (BEAST, Lucky13) che possono decifrare il testo cifrato con query chosen-ciphertext. Il trasferimento file moderno deve usare AEAD: AES-256-GCM (NIST SP 800-38D) o ChaCha20-Poly1305 (RFC 8439). Il tag Poly1305 o il tag GCM autentica il testo cifrato e tutti i dati associati (dimensione del file, nonce, intestazione del filename). Se un bit si corrompe in transito, la decifratura fallisce con un errore esplicito. Chi usa ancora AES-CBC nel 2026 senza un wrapper HMAC vive nel 2010.
Derivazione della chiave per i trasferimenti protetti da password
Quando un utente digita una password per proteggere un trasferimento, non puoi usare la password direttamente come chiave AES. Ha bassa entropia ed è vulnerabile alla forza bruta. Derivazione moderna della chiave: PBKDF2-SHA-256 con 600.000 iterazioni (raccomandazione OWASP 2023), scrypt con N=2^17, o Argon2id con 19 MiB di memoria e 2 iterazioni. HexaTransfer usa PBKDF2 con 600.000 iterazioni. Tresorit usa Argon2id. Entrambi resistono al cracking della password accelerato da GPU. I provider che usano ancora PBKDF2 con 10.000 iterazioni (linee guida del 2015) sono sottoprotetti.
Tabella di confronto
| Metodo | Confidenzialità | Autenticazione | Il server vede il plaintext | Rischio post-quantum | |---|---|---|---|---| | Solo TLS 1.3 | In transito | Sì (MAC nella cipher suite) | Sì | Scambio di chiavi a rischio | | AES-256 lato server | At-rest + in transito | Sì | Sì (ha la chiave) | Basso | | AES-256-GCM lato client | Percorso completo | Sì (tag GCM) | No | Basso | | XChaCha20-Poly1305 | Percorso completo | Sì (tag Poly1305) | No | Basso | | OpenPGP (Curve25519 + AES-256) | Percorso completo | Sì (MDC/OCB) | No | Curve25519 a rischio |
Considerazioni post-quantum
L'algoritmo di Shor minaccia Curve25519 e RSA una volta che esistano computer quantistici sufficientemente grandi. I cifrari simmetrici (AES-256, ChaCha20) vengono indeboliti ma non rotti dall'algoritmo di Grover; le chiavi a 256 bit mantengono una sicurezza post-quantum di 128 bit, ancora infeasibile. Il NIST ha standardizzato ML-KEM (Kyber) nel 2024 per l'incapsulamento post-quantum delle chiavi. Signal è migrato a PQXDH nel 2023. I servizi di trasferimento file non hanno ancora adottato ampiamente il post-quantum, ma la finestra di rischio ("raccogli ora, decifra dopo") significa che gli archivi a lunga conservazione dovrebbero usare già oggi crittografia simmetrica a 256 bit.
Come scegliere il metodo giusto
Trasferimento sensibile una tantum, breve conservazione: AES-256-GCM lato client con chiavi nel frammento URL. HexaTransfer è l'implementazione. Workflow regolamentati con conformità continua: XChaCha20-Poly1305 con log di audit (Tresorit). Multi-destinatario con gestione delle chiavi: OpenPGP (Proton Drive, GPG). Distribuzione decentralizzata di grandi file: libsodium secretbox più erasure coding (Internxt su Storj). Non-sensibile ad alto volume: TLS + at-rest è accettabile.
Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.
Invia file di grandi dimensioni in modo sicuro con crittografia end-to-end
Trasferisci file fino a 10 GB gratuitamente con crittografia end-to-end. Nessun account necessario. I tuoi file vengono crittografati nel browser prima del caricamento — nessun altro può leggerli.
Invia un file