WEBVTT

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

00:00:04.010 --> 00:00:07.072
Inizierò con due vecchi esempi che in realtà non

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

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

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

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

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

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

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

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

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

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

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

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

00:01:00.653 --> 00:01:05.205
largamente popolare. Viene utilizzato in realtà piuttosto comunemente nel protocollo HTTPS.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00:02:22.849 --> 00:02:27.818
sono anche polarizzati. E' infatti ora raccomandato che se intendete usare RC4

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

00:02:32.800 --> 00:02:37.246
iniziare usando l'output del generatore iniziando dal byt 257. La prima coppia

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

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

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

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

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

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

00:03:08.556 --> 00:03:13.718
Risulta che questa polarizzazione in effetti inizi dopo che diversi GByte di dati siano stati prodotti

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

00:03:18.634 --> 00:03:23.120
in definitiva può essere usato per distinguere l'output del generatore

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

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

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

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

00:03:41.078 --> 00:03:45.732
recuperare la chiave principale. Quindi queste sono debolezze che sono conosciute per RC4 e quindi

00:03:45.732 --> 00:03:50.217
si raccomanda che nuovi sistemi in effetti non usino RC4 e invece usino

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

00:03:54.421 --> 00:03:59.131
stream cipher usato per criptare film DVD malamente scardinato. Quando comprate un DVD

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

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

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

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

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

00:04:21.435 --> 00:04:25.749
DVD criptati. Lo stream cipher CSS è basato su qualcosa che piace

00:04:25.749 --> 00:04:30.291
ai progettisti hardware. E' progettato per essere uno stream cipher che si suppone

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

00:04:34.491 --> 00:04:38.749
lineare. Un registro a scorrimento con retroazione lineare è fondamentalmente un registro

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

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

00:04:49.046 --> 00:04:54.134
possizioni vengono chiamate "rubinetti". Questi rubinetti alimentano uno XOR e quindi

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

00:04:59.053 --> 00:05:04.345
e quindi il primo bit diventa il risultato di questo XOR. Potete quindi vedere che

00:05:04.345 --> 00:05:08.703
questo è un meccanismo molto semplice da implementare e in hardware impiega veramente

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

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

00:05:18.541 --> 00:05:23.460
fondamentalmente lo stato iniziale.

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

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

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

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

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

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

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

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

00:06:01.047 --> 00:06:05.459
descrivere come funziona questo attacco. Prima di tutto vediamo come effettivamente funziona CSS.

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

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

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

00:06:19.941 --> 00:06:25.086
di cifratura dove la chiave fosse solo di 40 bits. Quindi i progettisti di CSS

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

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

00:06:35.398 --> 00:06:40.806
il registro contiene 17 bit. E l'altro è di 25 bit.

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

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

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

00:06:57.669 --> 00:07:02.947
della chiave. E questo è lo stato iniziale del registro.

00:07:02.947 --> 00:07:08.256
Il secondo registro fondamentalmente viene inizializzato nello stesso modo.

00:07:08.256 --> 00:07:14.012
uno concatenato con gli ultimi tre byte della chiave. E questo

00:07:14.012 --> 00:07:19.889
viene caricato nello stato iniziale del registro. Potete vedere che i primi due byte

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

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

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

00:07:36.881 --> 00:07:42.333
8 bit di output. Quindi questi bit vanno un un sommatore che fa in pratica una

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

00:07:48.197 --> 00:07:54.325
che succede. Infatti Infatti... viene aggiunto anche una parte derivante

00:07:54.325 --> 00:07:59.723
dal blocco precedente. Ma questo non è importante. Questo è un dettaglio che non è rilevante.

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

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

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

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

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

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

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

00:08:35.830 --> 00:08:41.222
proporzionale a 2 alla 17. Lasciatemi mostrare come.

00:08:41.222 --> 00:08:45.734
Supponiamo che voi intercettiate il film. Quindi abbiamo un

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

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

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

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

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

00:09:08.589 --> 00:09:13.523
Ciò che ottenete è il segmento iniziale del PRG. Quindi voi ottenete

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

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

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

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

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

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

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

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

00:09:58.615 --> 00:10:03.814
prendere questo output che conosciamo e sottrarlo dai venti byte che

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

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

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

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

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

00:10:29.763 --> 00:10:33.561
sappiamo che il nostro tentativo per il primo registro a 17 bit era

00:10:33.561 --> 00:10:37.416
incorretto e quindi andiamo avanti con il prossimo tentativo per il registro a 17 bit e

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

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

00:10:46.937 --> 00:10:51.969
i 20 byte che otteniamo come output candidato dal registro a 25 bit è

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

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

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

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

00:11:12.796 --> 00:11:17.565
film. Possiamo recuperare la rimanente parte in chiaro. Ok. Questo è ciò

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

00:11:22.335 --> 00:11:27.331
Stiamo per fare un esercizio come compito a casa su questo tipo di stream ciphers

00:11:27.331 --> 00:11:31.444
e voi potrete capire come questi algoritmi di attacco

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

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

00:11:41.453 --> 00:11:45.888
esempi deboli, spostiamoci verso esempi migliori, e in particolare

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

00:11:49.370 --> 00:11:55.556
progetto che si è concluso nel 2008 e che ha qualificato cinque diversi stream

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

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

00:12:04.029 --> 00:12:08.340
stream cipher di norma hanno un seme. Ma inoltre hanno anche ciò

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

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

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

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

00:12:26.603 --> 00:12:31.218
mai finchè rimane fissata la chiave. Spiegherò tutto questo tin maggiori

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

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

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

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

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

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

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

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

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

00:13:21.541 --> 00:13:26.000
che proviene da eStream che voglio mostrarvi è chiamato Salsa20. E' uno

00:13:26.000 --> 00:13:30.292
stream cipher che è stato progettato per implementazioni sia hardware che software.

00:13:30.292 --> 00:13:33.385
E' piuttosto interessante. Capite che alcni stream ciphers sono

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

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

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

00:13:48.143 --> 00:13:50.963
l'implementazione hardware molto economica. La cosa interessante in questo senso è che

00:13:50.963 --> 00:13:55.008
esso è progettato in modo che sia semplice da implementare in hardware e che la sua

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

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

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

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

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

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

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

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

00:14:35.653 --> 00:14:40.498
il nonce r e un contatore che incrementa passo passo. Cioè va

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

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

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

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

00:14:59.460 --> 00:15:04.693
espandendo gli stati in qualcosa di piuttosto largo che è lungo 64 byte

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

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

00:15:15.552 --> 00:15:20.611
danno il valore per questa tao di zero. Quindi mettiamo k in 16

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

00:15:25.467 --> 00:15:30.795
la specifica specifica anche questa costante fissa. Quindi mettiamo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00:16:48.622 --> 00:16:52.764
E queste operazioni vengono fatte ancora e ancora. Quindi si applica la funzione

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

00:18:15.325 --> 00:18:20.371
molto vicina a 2 alla 128. edremo cosa significa questo più tardi.

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

00:18:25.417 --> 00:18:30.431
esso sembra impredicibile quanto richiesto per uno stream cipher. Quindi

00:18:30.431 --> 00:18:34.797
dovrei dire che il progetto eStream effettivamente ha cinque stream cipher come

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

00:18:39.395 --> 00:18:44.053
alcuni parametri di performance. Potete vedere che questi sonoparametri di performance su

00:18:44.053 --> 00:18:48.768
una macchina x86 a 2.2 GHz. E potete vedere che RC4 è effettivmente

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

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

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

00:19:01.182 --> 00:19:05.202
chiamato Sosemanuk, questi sono i finalisti eStream. Questi sono

00:19:05.202 --> 00:19:09.588
in effetti gli stream ciphers che sono stati approvati dal progetto eStream. Potete vedere che

00:19:09.588 --> 00:19:13.712
hanno raggiunto una velocità significativa. Questo è 643 MB/s su questa

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

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

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

00:19:26.661 --> 00:19:30.480
con questo nonce. E vedete i numeri di performance per questi

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

00:19:34.546 --> 00:19:37.991
finalisti del progetto eStream. In particolare potreste usare qualcosa come Salsa.