0:00:00.000,0:00:04.010
In questa sezione, voglio dare alcuni esempi di stream cipher che vengono effettivamente utilizzati

0:00:04.010,0:00:07.072
Inizierò con due vecchi esempi che in realtà non

0:00:07.072,0:00:11.017
si suppone vengano utilizzati in nuovi sistemi. Comunque, essi sono ancora piuttosto largamente utilizzati

0:00:11.017,0:00:14.164
e quindi voglio citarne semplicemente i nomi, in modo che voi possiate famigliarizzare con

0:00:14.164,0:00:19.087
questi concetti. Il primo stream cipher di cui voglio parlarvi è chiamato RC4, progettato

0:00:19.087,0:00:23.429
nel lontano 1987. Ve ne darò una descrizione ad alto livello e quindi

0:00:23.429,0:00:27.818
parleremo di alcune debolezze di RC4 e ci fermeremo lì. RC4 utilizza

0:00:27.818,0:00:32.702
un seme di lunghezza variabile; qui ho presentato un esempio dove sono stati utilizzati 128

0:00:32.702,0:00:36.980
bit come lunghezza del seme, che verrà utilizzato come chiave per lo stream cipher.

0:00:36.980,0:00:41.738
La prima cosa che fa, è espandere la chiave segreta di 128 but in un 2.048 bit, che

0:00:41.738,0:00:46.382
verranno utilizzati come stato interno per il generatore. Quindi, una volta che questa espansione è stata terminata,

0:00:46.382,0:00:51.197
esso esegue in pratica un loop molto semplice, dove ogni iterazione produce come

0:00:51.197,0:00:55.898
output un byte. Quindi, essenzialmente, voi potete far eseguire il generatore per

0:00:55.898,0:01:00.653
quanto tempo vogliate e generare un byte alla volta. Ora, RC4 è in pratica, come ho detto,

0:01:00.653,0:01:05.205
largamente popolare. Viene utilizzato in realtà piuttosto comunemente nel protocollo HTTPS.

0:01:05.205,0:01:11.888
In questi giorni, ad esempio, Google usa RC4 nel suo HTTPS. Viene utilizzato anche nel WEP, come abbiamo

0:01:11.888,0:01:15.686
discusso nell'ultima sezione, ma ovviamente in WEP esso è usato in maniera sbagliata e

0:01:15.686,0:01:18.861
il modo in cui viene utilizzato in WEP è assolutamente insicuro. Così, nel corso degli anni,

0:01:18.861,0:01:23.886
sono state trovate alcune debolezze in RC4 a, di conseguenza, si raccomanda che i nuovi progetti

0:01:23.886,0:01:28.793
non usino in effetti RC4, ma piuttosto un generatore pseudo-random più moderno, come

0:01:28.793,0:01:34.059
discuteremo verso la fine della sezione. QUindi, lasciatemi citare due delle debolezze.

0:01:34.059,0:01:39.561
La prima si trova (è qualcosa di bizzarro, fondamentalmente): se guardate al secondo byte

0:01:39.561,0:01:44.630
dell'output di RC4. Risulta che il secondo byte è leggermente polarizzato. Se RC4 fosse

0:01:44.630,0:01:49.780
completamente random, la probabilità che il secondo byte sia zero

0:01:49.780,0:01:54.744
sarebbe esattamente l'inverso di 256. Ci sono 256 possibili byte, la probabilità che

0:01:54.744,0:01:59.646
sia zero dovrebbe essere uno su 256. Succede invece che per RC4 la probabilità sia

0:01:59.646,0:02:04.486
in effetti due su 256, che significa che se usate l'output di RC4 per criptare un

0:02:04.486,0:02:09.574
messaggio, il secondo byte sia possibilmente non criptato del tutto. In altre parole, esso

0:02:09.574,0:02:14.575
sarà in XOR con zero due volte la probabilità che si suppone debba succedere.

0:02:14.575,0:02:19.436
Quindi, due su 256 invece che uno su 256. E, tra l'altro, dovrei dire che non c'è

0:02:19.436,0:02:22.849
nulla di speciale circa il secondo byte. Risulta però che anche il primo e il terzo byte

0:02:22.849,0:02:27.818
sono anche polarizzati. E' infatti ora raccomandato che se intendete usare RC4

0:02:27.818,0:02:32.800
ciò che dovreste fare è in pratica ignorare i primi 256 byte dell'output e giusto

0:02:32.800,0:02:37.246
iniziare usando l'output del generatore iniziando dal byt 257. La prima coppia

0:02:37.246,0:02:41.241
di byte risultano essere polarizzati, quindi semplicemente ignorateli. Il secondo attacco che

0:02:41.241,0:02:48.482
venne scoperto è che in effetti, se guardate a un output molto lungo di RC4, capita che

0:02:48.482,0:02:53.863
sia più facile ottenere la sequenza 00. In altre parole, è più facile

0:02:53.863,0:02:58.970
che otteniate sedici bit (due byte) di zero di quanto dobbiate. Di nuovo, se RC4

0:02:58.970,0:03:03.948
fosse completamente random, la probabilità di vedere zero, zero sarebbe esattamebte il quadrato di 1/256.

0:03:03.948,0:03:08.556
Risulta che RC4 è leggermente polarizzato e la polarizzazione sia il cubo di 1/256.

0:03:08.556,0:03:13.718
Risulta che questa polarizzazione in effetti inizi dopo che diversi GByte di dati siano stati prodotti

0:03:13.718,0:03:18.634
da RC4. Ma ciononostante, questo è qualcosa che può essere usato per predirre il generatore e

0:03:18.634,0:03:23.120
in definitiva può essere usato per distinguere l'output del generatore

0:03:23.120,0:03:28.097
da una vera sequenza casuale. Fondamentalmente, il fatto che zero, zero appaia più spesso

0:03:28.097,0:03:32.414
di quanto dovrebbe è il discriminante. E quindi nell'ultima sezione abbiamo parlato degli

0:03:32.414,0:03:36.313
attacchi basati su chiavi connesse che sono stati usati per attaccare WEP, che in pratica dicono che se

0:03:36.313,0:03:41.078
qualcuno usa chiavi che sono strettamente connesse l'una con l'altra, allora è in effetti possibile

0:03:41.078,0:03:45.732
recuperare la chiave principale. Quindi queste sono debolezze che sono conosciute per RC4 e quindi

0:03:45.732,0:03:50.217
si raccomanda che nuovi sistemi in effetti non usino RC4 e invece usino

0:03:50.217,0:03:54.421
generatori pseudo-casuali moderni. OK, il secondo esempio che voglio darvi è uno

0:03:54.421,0:03:59.131
stream cipher usato per criptare film DVD malamente scardinato. Quando comprate un DVD

0:03:59.131,0:04:03.504
in negozio, il film è criptato usando uno stream cipher chiamato

0:04:03.504,0:04:07.933
sistema di scrambling del contenuto (CSS, Content Scrambling System). CSS risulta essere uno stream cipher malamente scardinato,

0:04:07.933,0:04:12.523
e possiamo scardinarlo molto semplicemente. Ora voglio mostrarvi come funziona l'algoritmo di attacco.

0:04:12.523,0:04:16.894
Faro' in modo di mostrarvi un esempio di algoritmo di attacco, ma,

0:04:16.894,0:04:21.435
in effetti, ci sono molti system che fondamentalmente usano questo attacco per decrittare

0:04:21.435,0:04:25.749
DVD criptati. Lo stream cipher CSS è basato su qualcosa che piace

0:04:25.749,0:04:30.291
ai progettisti hardware. E' progettato per essere uno stream cipher che si suppone

0:04:30.291,0:04:34.491
sia facilmente implementabile in hardware ed è basato su un meccanismo chiamato registro di scorrimento a retroazione

0:04:34.491,0:04:38.749
lineare. Un registro a scorrimento con retroazione lineare è fondamentalmente un registro

0:04:38.749,0:04:43.801
che consiste in celle, dove ogni cella contiene un bit.

0:04:43.801,0:04:49.046
Ciò che succede è che ci sono rubinetti in alcune celle (non tutte), cioè certe

0:04:49.046,0:04:54.134
possizioni vengono chiamate "rubinetti". Questi rubinetti alimentano uno XOR e quindi

0:04:54.134,0:04:59.053
ad ogni colpo di clock, il registro scorre di un bit a sinistra. L'ultimo bit di sinistra viene scartato

0:04:59.053,0:05:04.345
e quindi il primo bit diventa il risultato di questo XOR. Potete quindi vedere che

0:05:04.345,0:05:08.703
questo è un meccanismo molto semplice da implementare e in hardware impiega veramente

0:05:08.703,0:05:13.622
pochi transistors. Giusto lo scorrimento, lo scarto dell'ultimo bit e l'aggiunta di un but

0:05:13.622,0:05:18.541
che diventa lo XOR di alcuni bits precedenti. Ciò che serve a questo registro è

0:05:18.541,0:05:23.460
fondamentalmente lo stato iniziale.

0:05:23.650,0:05:28.538
E questo è la base di un certo numero di stream ciphers. Qui vengono presentati alcuni esempi.

0:05:28.538,0:05:33.362
Come ho detto, la crittografia dei DVD usa due registri di questo tipo. Vi mostrerò come funziona tra un secondo.

0:05:33.362,0:05:38.060
Per quanto riguarda la crittografia GSM, ci sono algoritmi chiamati A51 e A52. E questi

0:05:38.060,0:05:43.456
usano tre registri di questo tipo. La crittografia Bluetooth è un algoritmo chiamato E zero. Questi sono tutti

0:05:43.456,0:05:48.534
stream ciphers, ed usano tutti quattro registri di questo tipo. Risulta che tutti questi cifratori sono stati scardinati malamente ed

0:05:48.534,0:05:53.245
in realtà non dovrebbero assolutamente essere considerati attendibili per traffico cifrato, ma sono tutti

0:05:53.245,0:05:56.705
implementati in hardware, quindi è alquanto difficile oggi cambiare ciò che viene fatto in hardware.

0:05:56.705,0:06:01.047
Ma il più semplice di tutti, CSS, in realtà ha un attacco carino che funziona su di esso, quindi lasciatemi

0:06:01.047,0:06:05.459
descrivere come funziona questo attacco. Prima di tutto vediamo come effettivamente funziona CSS.

0:06:05.459,0:06:11.073
la chiave di CSS è di cinque bytes, cioè 40 bits (5 volte 8 bit è 40 bit).

0:06:11.073,0:06:15.587
La ragione per cui hanno dovuto limitarsi a solo 40 bitsè che la cifratura dei DVD è stata progettata

0:06:15.587,0:06:19.941
in tempi in cui la legislazione per l'esportazione negli US permetteva solo di esportare algoritmi

0:06:19.941,0:06:25.086
di cifratura dove la chiave fosse solo di 40 bits. Quindi i progettisti di CSS

0:06:25.086,0:06:30.206
erano già limitati a chiavi molto, motlo corte. Solo 40 bits. Quindi il loro progetto funziona

0:06:30.206,0:06:35.398
in questo modo. Fondamentalmente, CSS usa due registri a scorrimento. Uno è a 17 bit. In altre parole

0:06:35.398,0:06:40.806
il registro contiene 17 bit. E l'altro è di 25 bit.

0:06:40.806,0:06:46.647
un pò più lungo, 25 bit. E il modo in cui questi registri vengono alimentati

0:06:46.647,0:06:51.870
è il seguente. Quindi la chiave per la cifratura, fondamentalmente è come segue.

0:06:51.870,0:06:57.669
Si inizia con un uno, che viene concatenato con i primi due byte

0:06:57.669,0:07:02.947
della chiave. E questo è lo stato iniziale del registro.

0:07:02.947,0:07:08.256
Il secondo registro fondamentalmente viene inizializzato nello stesso modo.

0:07:08.256,0:07:14.012
uno concatenato con gli ultimi tre byte della chiave. E questo

0:07:14.012,0:07:19.889
viene caricato nello stato iniziale del registro. Potete vedere che i primi due byte

0:07:19.889,0:07:25.411
sono 16 bit, più il primo 1, che sono 17 bit in tutto, mentre il secondo

0:07:25.411,0:07:31.217
registro è di 24 bit più un 1 che fa 25 bit. Notate che abbiamo usato tutti i cinque bit

0:07:31.217,0:07:36.881
della chiave. Quindi questi registri vengono fatti scorrere per otto cicli, generando

0:07:36.881,0:07:42.333
8 bit di output. Quindi questi bit vanno un un sommatore che fa in pratica una

0:07:42.333,0:07:48.197
somma modulo 256. Corretto, questa è un blocco di addizione modulo 256. C'è inoltre un'altra cosa

0:07:48.197,0:07:54.325
che succede. Infatti Infatti... viene aggiunto anche una parte derivante

0:07:54.325,0:07:59.723
dal blocco precedente. Ma questo non è importante. Questo è un dettaglio che non è rilevante.

0:07:59.723,0:08:04.761
OK, qundi in ogni blocco notate che facciamo un'addizione modulo 256

0:08:04.761,0:08:09.982
e stiamo ignorando la parte derivante dal blocco precedente, che però è semplicemente l'addizione di uno 0 o un 1

0:08:09.982,0:08:15.147
all'addizione del blocco successivo. OK? Quindi in pratica questo produce un byte per ciclo.

0:08:15.147,0:08:20.411
OK, quindi questo byte viene ovviamente usato, messo in XOR con il relativo

0:08:20.411,0:08:25.167
byte del film che è stato criptato. OK, quindi questo è uno stream cipher molto semplice e

0:08:25.167,0:08:29.986
impiega molto poco hardware per essere implementato. Viene eseguito velocemente, persino su

0:08:29.986,0:08:35.830
hardware molto economico e può criptare film. Risulta che questo sia facilmente scardinabile in un tempo

0:08:35.830,0:08:41.222
proporzionale a 2 alla 17. Lasciatemi mostrare come.

0:08:41.222,0:08:45.734
Supponiamo che voi intercettiate il film. Quindi abbiamo un

0:08:45.734,0:08:50.647
film criptato e voi volete decrittarlo. Quindi, diciamo che questo e completamente criptato in modo

0:08:50.647,0:08:55.279
che non abbiate alcuna idea di cosa ci sia dentro. Comunque, si da il caso che, poichè

0:08:55.279,0:08:59.970
la cifratura DVD usa file MPEG, succede che voi sappiate il prefisso del

0:08:59.970,0:09:04.250
file in chiaro, diciamo una ventina di byte. Bene, sappiamo che se fate lo XOR

0:09:04.250,0:09:08.589
di queste due cose insieme, cioè in altre parole, fate lo XOR qui,

0:09:08.589,0:09:13.523
Ciò che ottenete è il segmento iniziale del PRG. Quindi voi ottenete

0:09:13.523,0:09:18.472
i primi 20 byte dell'output del CSS, l'output di questo PRG. OK, quindi

0:09:18.472,0:09:23.986
ora questo è ciò che faremo. Abbiamo i primi 20 bytes dell'output. Ora

0:09:23.986,0:09:31.405
faremo ciò che segue. Tentiamo tutti i 2^17 possibili valori del primo

0:09:31.405,0:09:37.088
registro. OK? Quindi tutti i 2^17 valori. Per ogni tentativo, cioè

0:09:37.088,0:09:42.622
per ognuno di questi 2^17 valori iniziali del registro, faremo scorrere

0:09:42.622,0:09:47.953
i registri per venti byte, ok? Quindi genereremo 20 byte di output da questo

0:09:47.953,0:09:53.284
primo registro, assumendo... per ognuno dei 2^17 possibili settaggi.

0:09:53.284,0:09:58.615
Ora, considerate che conosciamo l'output completo del sistema CSS, Quindi ciò cjhe possiamo fare è

0:09:58.615,0:10:03.814
prendere questo output che conosciamo e sottrarlo dai venti byte che

0:10:03.814,0:10:08.928
abbiamo ottenuto dal primo registro. Se in effetti il nostro tentativo per lo stato iniziale del primo registro

0:10:08.928,0:10:14.042
è corretto, ciò che dovremmo ottenere sono i primi 20 byte del

0:10:14.042,0:10:19.222
secondo registro. Giusto? Perchè questo è per definizione l'output del sistema CSS.

0:10:19.222,0:10:24.501
Ora, risulta che guardando la sequenza di 20 byte, è molto semplice

0:10:24.501,0:10:29.763
dire se questa sequenza di 20 byte è uscita dal secondo registro oppure no. Se non lo è

0:10:29.763,0:10:33.561
sappiamo che il nostro tentativo per il primo registro a 17 bit era

0:10:33.561,0:10:37.416
incorretto e quindi andiamo avanti con il prossimo tentativo per il registro a 17 bit e

0:10:37.416,0:10:41.904
quindi quello successivo e così via. Finchè alla fine indoviniamo lo stato iniziale corretto

0:10:41.904,0:10:46.937
pòer il registro a 17 bit e quindi siamo arrivati, vedremo che

0:10:46.937,0:10:51.969
i 20 byte che otteniamo come output candidato dal registro a 25 bit è

0:10:51.969,0:10:56.936
in effetti un possibile output per il registro a 25 bit. E ora, non solo abbiamo

0:10:56.936,0:11:02.164
imparato il corretto stato iniziale per il registro a 17 bit, noi avremo anche

0:11:02.164,0:11:07.523
imparato il corretto stato iniziale del registro a 25 bit. E quindi possiamo predirre l'output

0:11:07.523,0:11:12.796
rimanente del CSS e, ovviamnte, usando questo, possiamo decrittare il resto del

0:11:12.796,0:11:17.565
film. Possiamo recuperare la rimanente parte in chiaro. Ok. Questo è ciò

0:11:17.565,0:11:22.335
di cui abbiamo parlato prima. L'ho spiegato un pò velocemente, ma, spero, chiaramente.

0:11:22.335,0:11:27.331
Stiamo per fare un esercizio come compito a casa su questo tipo di stream ciphers

0:11:27.331,0:11:31.444
e voi potrete capire come questi algoritmi di attacco

0:11:31.444,0:11:36.018
funzionano. Dovrei dire che ci sono diversi sistemi open-source oggi che in realtà

0:11:36.018,0:11:41.453
usano questo metodo per decrittare dati criptati con CSS. OK, quindi ora che abbiamo visto due

0:11:41.453,0:11:45.888
esempi deboli, spostiamoci verso esempi migliori, e in particolare

0:11:45.888,0:11:49.370
i generatori pseudo-random che vengono da quello che viene chiamato il Progetto eStream. Questo è un

0:11:49.370,0:11:55.556
progetto che si è concluso nel 2008 e che ha qualificato cinque diversi stream

0:11:55.556,0:12:00.207
cipher, ma qui voglio presentarne solo uno. Prima di tutto, i parametri per

0:12:00.207,0:12:04.029
questi stream cipher sono un pò diversi da quelli a cui siamo abituati. Questi

0:12:04.029,0:12:08.340
stream cipher di norma hanno un seme. Ma inoltre hanno anche ciò

0:12:08.340,0:12:12.821
che viene chiamato un nonce e vedremo come viene usato un nonce tra giusto un minuto. Quindi,

0:12:12.821,0:12:17.487
si prendono due input, un seme e un nonce. Vedremo come viene usato un nonce tra

0:12:17.487,0:12:21.274
giusto un secondo. Si produce ovviamente un output molto grande, quindi n è ora

0:12:21.274,0:12:26.603
molto, ma molto più grande di s. Ora, quando dico nonce, cosa intendo è un valore che non si ripeterà

0:12:26.603,0:12:31.218
mai finchè rimane fissata la chiave. Spiegherò tutto questo tin maggiori

0:12:31.218,0:12:35.400
dettagli tra giusto un secondo. Ma per ora, pensate solo ad esso come ad un valore unico che mai

0:12:35.400,0:12:40.527
si ripeta finchè la chiave è la stessa. E quindi, ovviamente, una volta che avete questo PRG (generatore pseudo-causale)

0:12:40.527,0:12:45.357
potrete cifrare e otenere uno stream cipher come prima, eccetto che ora, come vedete, il

0:12:45.357,0:12:49.955
PRG prende come input sia la chiave che il nonce. E la proprietà del nonce è

0:12:49.955,0:12:56.350
che la coppia (k,r), cioè (chiave,nonce) non si ripete mai. Non viene

0:12:56.350,0:13:03.096
mai usata più di una volta. Quindi la conclusione è che potete riusare la chiave,

0:13:03.096,0:13:09.710
riusare la chiave, perchè il nonce rende la coppia unica, perchè k ed r sono usati

0:13:09.710,0:13:16.135
solo una volta. Cioè sono unici. Ok, quindi questo nonce è qualcosa come uno stratagemma simpatico che

0:13:16.135,0:13:21.541
ci risparmia la necessità di utilizzare una nuova chiave ogni volta. ok, l'esempio particolare

0:13:21.541,0:13:26.000
che proviene da eStream che voglio mostrarvi è chiamato Salsa20. E' uno

0:13:26.000,0:13:30.292
stream cipher che è stato progettato per implementazioni sia hardware che software.

0:13:30.292,0:13:33.385
E' piuttosto interessante. Capite che alcni stream ciphers sono

0:13:33.385,0:13:38.763
progettati per implementazioni software, come RC4. Tutto ciò che fa è progettato per rendere

0:13:38.763,0:13:42.689
l'implementazione software molto veloce, mentre altri stream ciphers sono progettati

0:13:42.689,0:13:48.143
per l'hardware, come il CSS, usando un registro di scorrimento che è particolarmente progettato per rendere

0:13:48.143,0:13:50.963
l'implementazione hardware molto economica. La cosa interessante in questo senso è che

0:13:50.963,0:13:55.008
esso è progettato in modo che sia semplice da implementare in hardware e che la sua

0:13:55.008,0:13:59.747
implementazione software sia anche molto veloce. Quindi lasciatemi spiegare come funziona Salsa. Bene, Salsa

0:13:59.747,0:14:05.130
prende chiavi a 128 o a 256 bit. Spiegherò solo la versione di Salsa a 128 bit.

0:14:05.130,0:14:11.244
Quindi, questo è il seme. E prende anche un nonce, come prima, che

0:14:11.244,0:14:15.425
risulta essere di 64 bit. Quindi genera un output lungo. Ora, come funziona

0:14:15.425,0:14:21.060
realmente? Bene, la funzione stessa è definita nel modo seguente. Fondamentalmente, data

0:14:21.060,0:14:26.378
la chiave e il nonce, esso genererà una sequenza pseudorandom molto lunga.

0:14:26.378,0:14:31.222
cioè lunga quanto necessario. E lo farà usando questa funzione che chiamerò

0:14:31.222,0:14:35.653
H. Questa funzione H prende tre input. Fondamentalmente la chiave, il seme,

0:14:35.653,0:14:40.498
il nonce r e un contatore che incrementa passo passo. Cioè va

0:14:40.498,0:14:45.263
da zero a uno, due, tre, quattro finchè serve. Ok? Quindi, fondamentalmente,

0:14:45.263,0:14:49.956
calcolando questo H su questi k ed r, ma usando questo contatore incrementale, possiamo ottenere

0:14:49.956,0:14:54.882
una sequenza che è lunga quanto ci serve. Quindi, tutto ciò che devo fare è descrivere come funziona questa funzione

0:14:54.882,0:14:59.460
H. Ora, lasciatemi fare questo per voi. Il modo in cui funziona è il seguente. Bene, partiamo

0:14:59.460,0:15:04.693
espandendo gli stati in qualcosa di piuttosto largo che è lungo 64 byte

0:15:04.693,0:15:10.156
e lo facciamo nel modo seguente. Fondamentalmente prendiamo una costante all'inizio, quindi

0:15:10.156,0:15:15.552
c'è una tao di zero, fatta di quattro bytes, cioè è una costante di quattro byte. Le specifiche di Salsa vi

0:15:15.552,0:15:20.611
danno il valore per questa tao di zero. Quindi mettiamo k in 16

0:15:20.611,0:15:25.467
bytes. Quindi mettiamo un'altra costante. Di nuovo di quattro byte. E, come ho detto,

0:15:25.467,0:15:30.795
la specifica specifica anche questa costante fissa. Quindi mettiamo

0:15:30.795,0:15:37.435
il nonce, che è di otto byte. Quindi mettiamo l'indice. Questo è il contatore zero,

0:15:37.435,0:15:43.063
uno, due, tre, quattro che è di nuovo fatto da otto byte. Quindi mettiamo un'altra costante

0:15:43.063,0:15:49.056
tau due, che sono altri quattro byte. Quindi mettiamo la chiave di nuovo, che fanno

0:15:49.056,0:15:54.714
altri sedici byte. E quindi infine mettiamo la terza costante, tau tre, che sono

0:15:54.714,0:15:59.948
altri quattro byte. Ok, quindi, come ho detto, se sommato tutto questo, vedete che ottenete 64 byte.

0:15:59.948,0:16:05.249
Quindi, fondamentalmente, abbiamo sepanso la chiave e il nonce e il contatore fino a 64

0:16:05.249,0:16:10.886
byte. Fondamentalmente la chiave viene ripetuta due volte. E quindi quello che facciamo è applicare

0:16:10.886,0:16:16.321
la funzione. Chiamerò questa funzione h piccolo. Ok, qindi applichiamo questa funzione h piccolo.

0:16:16.321,0:16:21.659
E questa è una funzione che è uno a uno, quindi mappa 64 byte in 64 byte. E'

0:16:21.659,0:16:26.005
una funzione completamente invertibile, ok? Quindi, questa funzione h è, come ho detto, una

0:16:26.005,0:16:30.260
funzione invertibile. Quindi, dato l'iinput voi ottenete l'output e dato

0:16:30.260,0:16:34.906
l'output voi potete ritornare all'input. Ed è progettata specificatamente in questo modo, quindi è a - facilmente

0:16:34.906,0:16:39.553
implementabile in hardware e b- su un x86 è estremamente facile da implementare, perchè

0:16:39.553,0:16:44.199
x86 ha questo insieme di istruzioni SSE2 che supporta tutte le operazioni di cui avete bisogno per fare

0:16:44.199,0:16:48.622
questa funzione. Ed è molto, molto veloce. Di conseguenza, Salsa è uno stream cipher molto veloce.

0:16:48.622,0:16:52.764
E queste operazioni vengono fatte ancora e ancora. Quindi si applica la funzione

0:16:52.764,0:16:57.744
h ancora e si ottiengono altri 64 bytes. E via di seguito, fondamentalmente

0:16:57.744,0:17:05.318
lo si fa dieci volte. ok, l'intera operazione è quindi ripetere 10 volte, cioè applicare

0:17:05.318,0:17:17.961
10 volte la funzione h. Quindi, di per se stessa, non è in effetti molto random.

0:17:17.961,0:17:22.144
Non sembra random perchè, come abbiamo detto, H è completamente invertibile. Quindi dato

0:17:22.144,0:17:25.521
l'output finale, è mlto semplice invertire h e quindi tornare indietro agli input originali

0:17:25.521,0:17:31.831
e quindi verificare che l'input ha la struttura corretta. Quindi si fa un'altra

0:17:31.831,0:17:36.979
cosa, che è fondamentalmente un XOR tra gli input e gli output finali. In realtà,

0:17:36.979,0:17:42.405
scusate, non è uno XOR. è in effetti un'addizione. Quindi fate un'addizione parola per parola.

0:17:42.405,0:17:47.762
Quindi se ci sono 64 byte, fate un'addizione parola per parola a passi di 4 byte

0:17:47.762,0:17:52.980
e alla fine ottenete l'output di 64 byte e questo è tutto. Questo è l'intero generatore

0:17:52.980,0:17:57.175
pseudo-random. Quindi questa è l'intera funzione h piccolo. E, come ho

0:17:57.175,0:18:01.758
spiegato, questa intera costruzione è la funzione H grande. E quindi calcolate

0:18:01.758,0:18:06.009
H grande incrementando il contatore I da zero, uno, due, tre in avanti. E questo

0:18:06.009,0:18:10.408
vi fornirà una sequenza pseudo-casuale che è lunga quanto vi serve. E

0:18:10.408,0:18:15.325
fondamentalmente, non ci sono attacchi significativi su questo algoritmo. Questo ha una sicurezza che è

0:18:15.325,0:18:20.371
molto vicina a 2 alla 128. edremo cosa significa questo più tardi.

0:18:20.371,0:18:25.417
E' uno stream cipher molto veloce, sia in hardware che in software. E, per quanto possiamo dirne,

0:18:25.417,0:18:30.431
esso sembra impredicibile quanto richiesto per uno stream cipher. Quindi

0:18:30.431,0:18:34.797
dovrei dire che il progetto eStream effettivamente ha cinque stream cipher come

0:18:34.797,0:18:39.395
questo. Ho scelto Salsa20 perchè pernso sia il più elegante. Ma posso darvi

0:18:39.395,0:18:44.053
alcuni parametri di performance. Potete vedere che questi sonoparametri di performance su

0:18:44.053,0:18:48.768
una macchina x86 a 2.2 GHz. E potete vedere che RC4 è effettivmente

0:18:48.768,0:18:53.017
il più lento. Perchè essenzialmente, beh esso non sfrutta

0:18:53.017,0:18:57.475
l'hardware. Esso fa solo operazioni su byte. E quindi ci sono molti cicli sprecati

0:18:57.475,0:19:01.182
che non vengono utilizzati. Ma i candidati eStream, sia Salsa che l'altro dandidato

0:19:01.182,0:19:05.202
chiamato Sosemanuk, questi sono i finalisti eStream. Questi sono

0:19:05.202,0:19:09.588
in effetti gli stream ciphers che sono stati approvati dal progetto eStream. Potete vedere che

0:19:09.588,0:19:13.712
hanno raggiunto una velocità significativa. Questo è 643 MB/s su questa

0:19:13.712,0:19:18.150
architettura, più del necessario per un video e questi sono in effetti velocità piuttosto impressionanti

0:19:18.150,0:19:22.432
E quindi, ora avete visto esempi di due vecchi stream ciphers che non dovrebbero più essere usati,

0:19:22.432,0:19:26.661
compresi gli attacchi su questi stream ciphers. Avete anche visto come sono fatti i moderni stream ciphers

0:19:26.661,0:19:30.480
con questo nonce. E vedete i numeri di performance per questi

0:19:30.480,0:19:34.546
moderni stream ciphers. Quindi se vi capita di avere bisogno di uno stream cipher potreste usare uno dei

0:19:34.546,0:19:37.991
finalisti del progetto eStream. In particolare potreste usare qualcosa come Salsa.