DES, 3DES, RC4 e Blowfish spiegati da zero
In una frase: questi quattro cifrari sono stati i cavalli di battaglia degli anni Novanta — DES e il suo rimedio a tripla cifratura 3DES, il cifrario a flusso RC4 e Blowfish — e oggi sono tutti ritirati o deprecati, mantenuti in vita solo da vecchi file, vecchio hardware e vecchi protocolli che devono ancora essere letti.
DES: lo standard del 1977 che ha dato il via a tutto
Che cos'è. Il Data Encryption Standard (FIPS 46, 1977) è un cifrario di Feistel a 16 round su blocchi da 64 bit con una chiave da 56 bit (memorizzata in 8 byte, perché un bit di ogni byte è un controllo di parità). È stato progettato da IBM con il contributo della NSA, è diventato lo standard statunitense per due decenni e nel 1998 è stato di fatto violato quando la macchina Deep Crack dell'EFF ha forzato una chiave in 56 ore con hardware del costo di 250000 dollari. Il NIST lo ha ritirato per la cifratura nel 2005.
Perché il bit di parità confonde le lunghezze delle chiavi. Ogni ottavo bit di una chiave DES è calcolato dagli altri sette, quindi una chiave di 8 byte contiene solo 56 bit indipendenti — ecco perché per lo stesso cifrario si leggono sia «chiave a 64 bit» sia «chiave a 56 bit». 3DES eredita questo aspetto: 24 byte grezzi = 168 bit grezzi = 112 effettivi (il meet-in-the-middle elimina il resto).
Dove lo si incontra ancora. Nei blocchi PIN bancari (ISO 9564), in alcuni realm Kerberos v4, nei vecchi archivi di backup e nelle smart card. Se un sistema oggi richiede DES, sta interagendo con hardware degli anni Novanta oppure è semplicemente insicuro.
3DES: cifra, decifra, cifra
Il trucco. Il Triple-DES esegue DES tre volte su ogni blocco: EDE3 usa tre chiavi diverse (C = Ek3(Dk2(Ek1(P)))); il passo di decifratura al centro esiste perché un'implementazione 3DES possa emulare il DES singolo impostando k1=k2. EDE2 usa solo due chiavi (k1=k3), dando 112 bit effettivi. La costruzione era una soluzione rapida che ha triplicato la sicurezza di un cifrario già attaccato, senza inventarne uno nuovo.
Perché è morto comunque. Due problemi: è lento (tre passaggi DES completi per blocco, circa 1/20 della velocità di AES) e mantiene il blocco a 64 bit. Con 32 GiB di dati sotto una stessa chiave (il limite del compleanno di 232 blocchi), le collisioni tra blocchi diventano abbastanza probabili da far trapelare la struttura del testo in chiaro — l'attacco Sweet32 (2016) lo ha dimostrato contro le sessioni TLS con 3DES. Il NIST ha vietato la cifratura 3DES dopo il 2023 (SP 800-131A r2); il PCI DSS ne richiede il ritiro nei sistemi di pagamento.
RC4 / ARCFOUR: il cifrario a flusso del web delle origini
Come funziona. RC4 (Ron's Code 4, progettato nel 1987, divulgato nel 1994) è un cifrario a flusso: la chiave genera una permutazione di 256 byte (KSA), poi la permutazione emette un flusso pseudocasuale di byte (PRGA) che viene combinato in XOR con il messaggio. Nessun padding, nessuna dimensione di blocco, qualsiasi lunghezza del messaggio, velocissimo nel software — ed è per questo che ha dominato SSL/TLS e WEP negli anni Novanta. «ARCFOUR» è il nome privo di marchio che la maggior parte dei progetti open source usa.
Come si è rotto. Fluhrer-Mantin-Shamir (2001) hanno mostrato che i primi byte del flusso di chiavi sono sbilanciati — fatale in WEP, dove la costruzione della chiave per ogni pacchetto esponeva proprio quei byte agli attaccanti. Attacchi successivi di bias (2013, AlFardan et al.) hanno recuperato il testo in chiaro da sessioni TLS protette da RC4 con milioni di connessioni. La RFC 7465 (2015) vieta del tutto RC4 in TLS.
Il vettore classico. Chiave «Key» (3 byte), messaggio «Plaintext» dà il testo cifrato bbf316e8d940af0ad3 — provi l'Esempio RC4 e confronti. L'autotest di questa pagina verifica anche il flusso di chiavi RFC 6229 per la chiave a 40 bit 01 02 03 04 05: b2396305f03dc027ccc3524a0a1118a8.
Blowfish: non violato, ma limitato dal blocco
Che cos'è. Il cifrario di Feistel di Bruce Schneier del 1993: blocchi da 64 bit, chiavi da 32 a 448 bit (da 4 a 56 byte), 16 round e un celebre key schedule che esegue lo stesso Blowfish 521 volte per costruire le sottochiavi — il che rende lenta l'inizializzazione della chiave, ma costosi anche i tentativi di forza bruta. Nessuna crittanalisi pratica rompe il Blowfish a tutti i round.
Perché compare comunque in questa pagina. Il problema è il blocco a 64 bit, non l'algoritmo: oltre ~32 GiB sotto una stessa chiave, le collisioni del compleanno fanno trapelare i dati (lo stesso limite di 3DES, in stile Sweet32). Lo stesso Schneier raccomanda il suo successore Twofish (finalista del concorso AES) o AES per qualsiasi cosa nuova. Blowfish vive ancora dentro bcrypt — il key schedule dell'hash della password è Blowfish — ed è accettabile, perché l'hashing usa input minuscoli, non gigabyte.
I vettori classici. Chiave tutta zero e testo in chiaro tutto zero cifrano in 4ef997456198dd78 (primo blocco dell'output dell'Esempio); la chiave «abcdefghijklmnopqrstuvwxyz» su «BLOWFISH» dà 324ed0fef413a203. Entrambi provengono dal file di vettori pubblicato da Schneier e sono verificati dall'autotest.
Errori comuni
- Usare questi cifrari per dati nuovi. Ogni cifrario di questa pagina è deprecato, tranne Blowfish (che è limitato dalla dimensione del blocco). La scelta moderna corretta è AES-GCM — vedi Cifratura / decifratura AES.
- Chiave DES derivata da una password. Una password di 8 caratteri non è un insieme di 56 bit casuali; è una manciata di bit di entropia per carattere. I vecchi sistemi lo facevano esattamente così, ed è la causa più comune per cui gli archivi «cifrati con DES» cadono in pochi minuti sotto attacchi a dizionario.
- Riutilizzare un IV in CBC. Il primo blocco rivela allora l'uguaglianza del testo in chiaro tra messaggi diversi sotto la stessa chiave. Il pulsante IV casuale esiste per questo motivo.
- Riutilizzare un flusso di chiavi RC4. RC4 applica lo stesso flusso in XOR per la stessa chiave: cifrare due messaggi con una chiave è un two-time pad — combinando in XOR i testi cifrati emergono entrambi i testi in chiaro. La falla fatale di WEP era proprio una costruzione con riutilizzo del flusso di chiavi.
- Presumere che «se decifra, allora è giusto». ECB/CBC qui validano solo il padding in decifratura — una chiave sbagliata di solito produce un risultato spazzatura che può comunque superare il controllo del padding. Nessuna modalità legacy ha un controllo di integrità; se ne serve uno, serve AES-GCM, non questi.
- Considerare 3DES come «a 168 bit». La chiave grezza è di 168 bit, ma la robustezza effettiva è di 112 — il meet-in-the-middle riduce la tripla cifratura a una doppia più un po', esattamente come per le costruzioni antecedenti a 3DES.
Domande frequenti
Perché mantenere uno strumento per cifrari rotti? Per compatibilità. I backup cifrati, i file esportati in vecchi formati, le tracce di protocollo catturate, le sfide CTF e l'hardware che non può essere aggiornato parlano ancora questi cifrari. Leggere i vecchi dati è legittimo; scrivere dati nuovi con questi cifrari no.
La mia chiave DES ha parità dispari / byte non ASCII. DES ignora il bit di parità di ogni byte della chiave, quindi la chiave effettiva sono comunque gli altri 56 bit. Questa pagina accetta qualsiasi 8 byte e non impone la parità pari.
Perché il testo decifrato a volte sembra spazzatura? Chiave sbagliata, modalità sbagliata, IV sbagliato, oppure i dati non sono stati cifrati come si presume. Senza un tag di autenticazione non esiste un errore pulito di «chiave sbagliata» — il controllo del padding è l'unico indizio, e può superarlo per caso (1 volta su 256).
Blowfish è sicuro per i miei file? Per i file piccoli, crittograficamente sì (nessuna violazione pratica). Per qualsiasi cosa di scala gigabyte sotto una singola chiave, no — il limite del compleanno del blocco a 64 bit riguarda il volume dei dati, non la robustezza della chiave. Twofish o AES evitano il problema.
E le chiavi Blowfish da 72 byte che ho visto da qualche parte? Alcune implementazioni accettano fino a 72 byte, ma l'implementazione di riferimento di Schneier usa 56 e i byte oltre quel limite non danno alcuna diffusione aggiuntiva nel key schedule standard. Questa pagina segue il riferimento: da 4 a 56 byte.