Crittografia resistente ai quanti: sicurezza a prova di futuro
I computer quantistici minacciano la crittografia attuale. Scopri gli algoritmi post-quantistici come Kyber e Dilithium.
La crittografia resistente ai quanti protegge i file da avversari con un computer quantistico crittograficamente rilevante — uno capace di eseguire l'algoritmo di Shor abbastanza velocemente da rompere RSA-2048 o ECDH P-256 in ore. Il NIST ha finalizzato tre standard post-quantistici nell'agosto 2024: ML-KEM (FIPS 203, ex Kyber) per l'incapsulamento delle chiavi, ML-DSA (FIPS 204, ex Dilithium) per le firme, e SLH-DSA (FIPS 205, ex SPHINCS+) per le firme hash-based. Per il trasferimento file, il percorso pratico nel 2026 è ibrido: X25519-MLKEM-768 per lo scambio di chiavi, mantenendo AES-256-GCM per la cifratura bulk poiché i cifrari simmetrici perdono solo metà dei bit all'algoritmo di Grover.
Perché la crittografia simmetrica è per lo più a posto
L'algoritmo di Grover taglia la lunghezza della chiave effettiva dei cifrari simmetrici a metà — AES-256 scende a 128 bit di sicurezza quantistica, AES-128 scende a 64 e diventa violabile. Quindi la mitigazione è semplice: usa AES-256 ovunque. ChaCha20-Poly1305 regge similmente con 128 bit di sicurezza post-quantistica. Le funzioni hash sono ancora meglio posizionate; SHA-256 mantiene 128 bit di resistenza alle collisioni, SHA-384 ne mantiene 192. Il cielo non sta cadendo sulla crittografia simmetrica. Ogni strumento di trasferimento file serio usa già AES-256-GCM; non devi cambiare nulla da quella parte.
Dove si trova il vero pericolo: scambio di chiavi e firme
I primitivi a chiave pubblica sono il problema. La fattorizzazione RSA e il logaritmo discreto su curve ellittiche cadono entrambi all'algoritmo di Shor, che ha bisogno di circa 4.000 qubit logici per rompere RSA-2048. Il Kookaburra IBM del 2025 ha 4.158 qubit fisici; una volta che la correzione degli errori matura (probabilmente 2030-2035 secondo la timeline del NIST), l'attacco diventa fattibile. Ogni sessione TLS 1.3 oggi usa ECDH o X25519 per lo scambio di chiavi — è lì che morde la rottura quantistica. I file che trasferisci nel 2026 potrebbero essere decifrati nel 2035 da un attaccante che ha conservato il ciphertext. "Harvest now, decrypt later" non è ipotetico; i documenti NSA del 2013 descrivono questa strategia.
ML-KEM: il nuovo motore di scambio chiavi
ML-KEM (Module-Lattice Key Encapsulation Mechanism) è lo scambio di chiavi post-quantistico scelto dal NIST, standardizzato come FIPS 203. Tre set di parametri: ML-KEM-512 (128 bit di sicurezza quantistica), ML-KEM-768 (192 bit) e ML-KEM-1024 (256 bit). Le chiavi pubbliche sono da 800 a 1.568 byte, i ciphertext da 768 a 1.568 byte — grandi rispetto ai 32 byte di X25519, ma ancora gestibili. Chrome 131 ha introdotto X25519-MLKEM-768 ibrido di default alla fine del 2024. Cloudflare lo ha abilitato su tutti gli endpoint a dicembre 2024. Se il tuo servizio di trasferimento file gira dietro Cloudflare, il tuo handshake TLS 1.3 è già protetto post-quantisticamente.
ML-DSA per l'autenticità
ML-DSA (Module-Lattice Digital Signature Algorithm), FIPS 204, sostituisce ECDSA ed Ed25519 per le firme. Set di parametri ML-DSA-44 (128 bit), ML-DSA-65 (192 bit), ML-DSA-87 (256 bit). Le firme sono da 2.420 a 4.595 byte — rispetto ai 64 di Ed25519. Per il trasferimento file, le firme contano in due punti: autenticare il certificato TLS del server, e firmare le voci del log di audit per il non ripudio. Let's Encrypt e DigiCert pianificano entrambi l'emissione di certificati ML-DSA per il 2026-2027. Nel frattempo, i certificati ibridi contenenti sia firme Ed25519 che ML-DSA colmano il gap.
SLH-DSA come backup conservativo
SLH-DSA (FIPS 205, ex SPHINCS+) è hash-based e dipende solo dalla sicurezza di SHA-256 o SHAKE — nessuna nuova assunzione matematica. Questo è l'algoritmo da scegliere se non ci si fida dei reticoli. Le firme sono molto più grandi (da 7.856 a 49.856 byte) e più lente da calcolare, ma l'argomento di sicurezza è inattaccabile. Per i log di audit a lunga conservazione dove le firme devono essere affidabili nel 2050, SLH-DSA è la copertura. Per ogni trasferimento file di 30 secondi, è eccessivo.
Schemi ibridi: cintura e bretelle
Il deployment puramente post-quantistico è rischioso perché ML-KEM è nuovo — la crittoanalisi continuerà. Il consenso del settore, codificato in NIST SP 800-227 (bozza 2024), è ibrido: esegui sia algoritmi classici che post-quantistici in parallelo, XOR i segreti derivati. Un attaccante deve rompere entrambi per decifrare. X25519-MLKEM-768 è il default attuale per TLS; RSA-3072 + ML-KEM-768 per ambienti vincolati. Per la cifratura file a riposo, puoi cifrare in modo ibrido la chiave file AES-256 sia con un pubblico X25519 che ML-KEM e conservare entrambi i ciphertext.
Percorsi di migrazione per i sistemi esistenti
Il problema della crypto-agility è reale. La maggior parte dei codebase di trasferimento file hardcode i nomi degli algoritmi nelle configurazioni e nelle definizioni delle strutture. Refactorizza verso OID e provider pluggable così passare da ECDH a ML-KEM è un cambiamento di configurazione, non una riscrittura. L'NCSC (UK) raccomanda di completare l'inventario entro fine 2026, il rollout ibrido entro il 2028, e la migrazione completamente post-quantistica entro il 2031. CNSA 2.0 (sistemi di sicurezza nazionale USA) impone ML-KEM e ML-DSA nei nuovi sistemi entro il 2027 e ovunque entro il 2033. Il tuo fornitore di trasferimento file dovrebbe pubblicare una roadmap PQC; se non l'ha ancora menzionato nel 2026, chiedi.
Dimensioni delle chiavi, banda e il problema del mobile
ML-KEM-768 aggiunge circa 2,3 KB per handshake TLS rispetto a X25519. Su una connessione 5G sono 2 ms di latenza, invisibili. Su un link satellite con RTT di 600 ms, percettibili ma tollerabili. Per un trasferimento file da 10 GB che richiede già minuti, l'overhead è trascurabile. La preoccupazione sono i servizi ad alto numero di connessioni (un CDN origin che accetta 10.000 handshake/secondo) dove l'overhead di memoria scala. HexaTransfer e servizi simili che girano dietro Cloudflare scaricano questo costo all'edge.
Firme su file da verificare decenni dopo
Il caso davvero interessante sono le firme digitali su file destinati ad essere verificabili nel 2060. Un contratto .pdf firmato con Ed25519 nel 2026 potrebbe essere non verificabile (o falsificabile) nel 2040. Opzione uno: ri-firma periodicamente con l'algoritmo migliore del momento. Opzione due: firma con SLH-DSA oggi e fidati della longevità di SHA-256. Opzione tre: timestampa la firma su una blockchain (OpenTimestamps ancora su Bitcoin) così almeno l'esistenza e la data sono preservate crittograficamente anche se l'algoritmo di firma cade. La firma di qualità archivistica è dove il pensiero post-quantistico conta di più.
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