Cifrario a flusso
In crittografia un cifrario a flusso (detto anche cifrario a caratteri) è un cifrario simmetrico nel quale i simboli (i bit) che codificano il testo in chiaro sono cifrati indipendentemente l'uno dall'altro e nel quale la trasformazione dei simboli successivi varia con il procedere della cifratura. Un altro termine usato per tale cifrario è cifrario a stati, termine che ricorda che la cifratura di ogni simbolo dipende da uno stato corrente. Tipicamente nella pratica, i simboli sono singoli bit o byte.
Indice
1 Caratteristiche
2 Vaga ispirazione dal one-time pad
3 Tipologie di cifrario a flusso
3.1 Cifrari a flusso sincroni
3.2 Cifrari a flusso auto-sincronizzanti
4 Implementazioni
5 Sicurezza
6 Adozione
7 Bibliografia
8 Voci correlate
Caratteristiche |
I cifrari a flusso costituiscono un approccio alla cifratura simmetrica differente da quello dei cifrari a blocchi: questi prevedono che si effettui su successivi estesi blocchi di simboli una determinata trasformazione che non cambia da blocco a blocco. Questa distinzione in realtà non è sempre netta: alcune modalità operative dei cifrari a blocchi effettuano una cifratura a blocchi primitiva in un modo tale che il suo effetto corrisponde a quello di un cifrario a flusso. Tipicamente i cifrari a flusso sono eseguiti a velocità superiori a quelle dei cifrari a blocchi e si servono di hardware meno complesso. Per contro i cifrari a flusso possono essere suscettibili a seri problemi di sicurezza, se non sono utilizzati correttamente: ad esempio si veda l'articolo Attacchi ai cifrari a flusso; in particolare non deve mai essere usato due volte lo stesso stato di partenza.
I documenti della National Security Agency talora usano il termine combiner-type algorithms (algoritmi di tipo combinatore) per denotare algoritmi che si servono di qualche opportuna funzione per combinare un flusso di testo in chiaro con un generatore di numeri pseudo-casuali (pseudo-random number generator o PRNG).
Vaga ispirazione dal one-time pad |
I cifrari a flusso possono essere visti come approssimazioni di un cifrario teoricamente non compromissibile, l'one-time pad (OTP), di cui un noto esempio è il cifrario di Vernam. L'OTP usa una sequenza chiave di simboli completamente casuali. La sequenza chiave è combinata con il testo in chiaro un simbolo alla volta per formare il testo cifrato. Claude E. Shannon ha dimostrato nel 1949 che questo sistema è teoricamente sicuro. Comunque, la sequenza chiave deve avere (almeno) la stessa lunghezza del testo in chiaro, e deve essere generata in maniera casuale. Questo rende il sistema molto oneroso da implementare in pratica, e di conseguenza l'OTP non è largamente usato, tranne per applicazioni di importanza critica.
Un cifrario a flusso usa una chiave molto più piccola e molto più comoda, 128 bit ad esempio. Sulla base di questa chiave, genera una sequenza chiave pseudo-casuale che può essere combinata con i simboli del testo in chiaro allo stesso modo dell'OTP. Però, questo ha un costo: poiché la sequenza chiave è solo pseudo-casuale, e non veramente casuale, la prova di sicurezza associata all'OTP non ha più valore: è anzi possibile che un cifrario a flusso sia completamente insicuro.
Tipologie di cifrario a flusso |
Un cifrario a flusso genera elementi successivi della sequenza chiave in base allo stato interno. Questo stato è aggiornato essenzialmente in due modi: se lo stato cambia indipendentemente dal messaggio in chiaro o cifrato, il cifrario è classificato come sincrono. In contrasto, un cifrario a flusso auto-sincronizzante aggiorna lo stato in base ai precedenti simboli di testo cifrato.
Cifrari a flusso sincroni |
In un cifrario a flusso sincrono una sequenza di simboli pseudo-casuale viene generata indipendentemente dai messaggi in chiaro e cifrato, e poi combinata con il testo in chiaro (per cifrare) o quello cifrato (per decifrare). Nella forma più comune, si usano simboli binari (bit), e la sequenza chiave è combinata con il testo in chiaro usando l'operazione di or esclusivo (XOR) applicata bit a bit, che è un'operazione nota essere simmetrica e reversibile. Questo è definito cifrario a flusso sincrono additivo.
In un cifrario a flusso sincrono, il mittente e il ricevitore devono stare perfettamente al passo perché la decifratura sia corretta. Se i simboli sono aggiunti o rimossi dal messaggio durante la trasmissione, si perde la sincronizzazione. Per recuperare la sincronizzazione, si può tentare varie posizioni nel testo fino ad ottenere la decifratura corretta. Un altro approccio è di marchiare il testo cifrato con dei marcatori in posizioni prefissate nel testo.
Se, infine, un simbolo è corrotto durante la trasmissione, invece che aggiunto o perduto, un solo simbolo nel testo in chiaro ne è affetto e l'errore non si propaga ad altre parti del messaggio. Questa proprietà è utile quando la frequenza di errori nella comunicazione è alta; però, ciò rende più difficile rilevare l'errore senza ulteriori meccanismi. Inoltre, a causa di questa proprietà i cifrari a flusso sincroni sono particolarmente sensibili agli attacchi attivi — se un attaccante può riuscire a cambiare un simbolo nel testo cifrato, potrebbe essere in grado di indurre cambiamenti prevedibili al corrispondente simbolo di testo in chiaro; infatti, a causa delle caratteristiche dell'operatore XOR, l'inversione di un bit nel testo cifrato provoca automaticamente l'inversione dello stesso bit nel testo in chiaro.
Cifrari a flusso auto-sincronizzanti |
Un altro approccio usa alcuni dei precedenti N simboli di testo cifrato per calcolare la sequenza chiave. Tali schemi sono noti come cifrari a flusso auto-sincronizzanti, cifrari a flusso asincroni o ciphertext autokey (CTAK). L'idea dell'auto-sincronizzazione fu brevettata nel 1946 ((EN) United States Patent 2,405,400, United States Patent and Trademark Office.), ed ha il vantaggio che il ricevitore si sincronizzerà automaticamente con il generatore della sequenza chiave dopo aver ricevuto N simboli di testo cifrato, rendendo più semplice il recupero in caso di simboli persi o aggiunti al messaggio. Errori su un solo simbolo hanno un effetto limitato, poiché riguardano al più N simboli di testo in chiaro. È anche più difficile lanciare attacchi attivi sui cifrari a flusso auto-sincronizzanti che sulle loro controparti sincrone.
Un esempio di cifrario a flusso auto-sincronizzante è il cifrario a blocchi in modalità cipher-feedback (CFB).
Implementazioni |
.mw-parser-output .vedi-anche{border:1px solid #CCC;font-size:95%;margin-bottom:.5em}.mw-parser-output .vedi-anche td:first-child{padding:0 .5em}.mw-parser-output .vedi-anche td:last-child{width:100%}
L'approccio più seguito è usare come generatore di numeri pseudo-casuali un LFSR, opportunamente modificato in modo da ridurre il più possibile le sue intrinseche linearità: il notevole vantaggio di questa implementazione è la sua notevole economicità.
Invece di un dispositivo a guida lineare, un altro modo è usare una funzione di aggiornamento non-lineare. Ad esempio, Klimov e Shamir hanno proposto una funzione triangolare (Funzioni-T) con un singolo ciclo su blocchi di n bit.
Sicurezza |
Per essere sicuro, il periodo della sequenza chiave, cioè il numero di simboli in uscita prima che la sequenza si ripeta, deve essere sufficientemente grande. Se la sequenza si ripete, allora i testi cifrati che si sovrappongono possono essere allineati uno contro l'altro "in profondità", e ci sono tecniche con cui in queste condizioni si può estrarre il testo in chiaro. Questo è un pericolo reale: ad esempio, il cifrario a blocchi Data Encryption Standard (DES) poteva inizialmente operare in una modalità (OFB) con parametri variabili. Però, per molte scelte di tali parametri, la sequenza risultante aveva un periodo di solo 232 — per molte applicazioni, questo periodo è troppo piccolo. Ad esempio, se la cifratura è eseguita alla frequenza di 1 megabyte al secondo, una sequenza di periodo 232 si ripeterà dopo circa 8,5 minuti.
Adozione |
I cifrari a flusso sono spesso utilizzati in applicazioni in cui il testo in chiaro ha una lunghezza sconosciuta a priori - ad esempio, in una rete wireless. Se un cifrario a blocchi venisse usato in questo tipo di applicazioni, il progettista dovrebbe scegliere tra l'efficienza della trasmissione e la complessità dell'implementazione, poiché i cifrari a blocchi non possono lavorare naturalmente su blocchi più piccoli della dimensione prefissata di un blocco. Per esempio, se un cifrario a blocchi a 128-bits ricevesse delle raffiche separate di testo in chiaro a 32-bit, tre quarti dei dati trasmessi sarebbe aggiunta per espandere il testo alla lunghezza necessaria (padding). I cifrari a blocchi devono essere utilizzati nelle modalità ciphertext stealing o residual block termination per evitare il padding, mentre i cifrari a flusso eliminano il problema operando naturalmente sull'unità più piccola trasmissibile (generalmente bytes).
Un altro vantaggio dei cifrari a flusso nella crittografia militare sta nel fatto che il flusso delle cifre può essere generato in una unità fisica separata che può essere sottoposta a misure di sicurezza stringenti ed essere fornito ad altri dispositivi, ad es. ad un apparecchio radio, che, tra le sue altre funzioni, si fa carico dell'esecuzione della operazione XOR. Un tale dispositivo a valle può essere progettato e tenuto in esercizio secondo modalità di sicurezza meno stringenti.
Tra i cifrari a flusso implementati in software RC4 è il più estesamente usato; alcuni altri sono:
A5/1,
A5/2,
Chameleon,
FISH,
Helix,
ISAAC,
MUGI,
Panama,
Phelix,
Pike,
SEAL,
SOBER,
SOBER-128 e
WAKE.
Bibliografia |
- Matt J. B. Robshaw (1995): Stream Ciphers Technical Report TR-701, version 2.0, RSA Laboratories, in PDF
- Thomas Beth, Fred Piper: The Stop-and-Go Generator in EUROCRYPT 1984 pp. 88-92
Voci correlate |
- eSTREAM - ECRYPT Stream Cipher project
.mw-parser-output .navbox{border:1px solid #aaa;clear:both;margin:auto;padding:2px;width:100%}.mw-parser-output .navbox th{padding-left:1em;padding-right:1em;text-align:center}.mw-parser-output .navbox>tbody>tr:first-child>th{background:#ccf;font-size:90%;width:100%}.mw-parser-output .navbox_navbar{float:left;margin:0;padding:0 10px 0 0;text-align:left;width:6em}.mw-parser-output .navbox_title{font-size:110%}.mw-parser-output .navbox_abovebelow{background:#ddf;font-size:90%;font-weight:normal}.mw-parser-output .navbox_group{background:#ddf;font-size:90%;padding:0 10px;white-space:nowrap}.mw-parser-output .navbox_list{font-size:90%;width:100%}.mw-parser-output .navbox_odd{background:#fdfdfd}.mw-parser-output .navbox_even{background:#f7f7f7}.mw-parser-output .navbox_center{text-align:center}.mw-parser-output .navbox .navbox_image{padding-left:7px;vertical-align:middle;width:0}.mw-parser-output .navbox+.navbox{margin-top:-1px}.mw-parser-output .navbox .mw-collapsible-toggle{font-weight:normal;text-align:right;width:7em}.mw-parser-output .subnavbox{margin:-3px;width:100%}.mw-parser-output .subnavbox_group{background:#ddf;padding:0 10px}