1
00:00:00,000 --> 00:00:04,010
In questa sezione, voglio dare alcuni esempi di stream cipher che vengono effettivamente utilizzati

2
00:00:04,010 --> 00:00:07,072
Inizierò con due vecchi esempi che in realtà non

3
00:00:07,072 --> 00:00:11,017
si suppone vengano utilizzati in nuovi sistemi. Comunque, essi sono ancora piuttosto largamente utilizzati

4
00:00:11,017 --> 00:00:14,164
e quindi voglio citarne semplicemente i nomi, in modo che voi possiate famigliarizzare con

5
00:00:14,164 --> 00:00:19,087
questi concetti. Il primo stream cipher di cui voglio parlarvi è chiamato RC4, progettato

6
00:00:19,087 --> 00:00:23,429
nel lontano 1987. Ve ne darò una descrizione ad alto livello e quindi

7
00:00:23,429 --> 00:00:27,818
parleremo di alcune debolezze di RC4 e ci fermeremo lì. RC4 utilizza

8
00:00:27,818 --> 00:00:32,702
un seme di lunghezza variabile; qui ho presentato un esempio dove sono stati utilizzati 128

9
00:00:32,702 --> 00:00:36,980
bit come lunghezza del seme, che verrà utilizzato come chiave per lo stream cipher.

10
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

11
00:00:41,738 --> 00:00:46,382
verranno utilizzati come stato interno per il generatore. Quindi, una volta che questa espansione è stata terminata,

12
00:00:46,382 --> 00:00:51,197
esso esegue in pratica un loop molto semplice, dove ogni iterazione produce come

13
00:00:51,197 --> 00:00:55,898
output un byte. Quindi, essenzialmente, voi potete far eseguire il generatore per

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

15
00:01:00,653 --> 00:01:05,205
largamente popolare. Viene utilizzato in realtà piuttosto comunemente nel protocollo HTTPS.

16
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

17
00:01:11,888 --> 00:01:15,686
discusso nell'ultima sezione, ma ovviamente in WEP esso è usato in maniera sbagliata e

18
00:01:15,686 --> 00:01:18,861
il modo in cui viene utilizzato in WEP è assolutamente insicuro. Così, nel corso degli anni,

19
00:01:18,861 --> 00:01:23,886
sono state trovate alcune debolezze in RC4 a, di conseguenza, si raccomanda che i nuovi progetti

20
00:01:23,886 --> 00:01:28,793
non usino in effetti RC4, ma piuttosto un generatore pseudo-random più moderno, come

21
00:01:28,793 --> 00:01:34,059
discuteremo verso la fine della sezione. QUindi, lasciatemi citare due delle debolezze.

22
00:01:34,059 --> 00:01:39,561
La prima si trova (è qualcosa di bizzarro, fondamentalmente): se guardate al secondo byte

23
00:01:39,561 --> 00:01:44,630
dell'output di RC4. Risulta che il secondo byte è leggermente polarizzato. Se RC4 fosse

24
00:01:44,630 --> 00:01:49,780
completamente random, la probabilità che il secondo byte sia zero

25
00:01:49,780 --> 00:01:54,744
sarebbe esattamente l'inverso di 256. Ci sono 256 possibili byte, la probabilità che

26
00:01:54,744 --> 00:01:59,646
sia zero dovrebbe essere uno su 256. Succede invece che per RC4 la probabilità sia

27
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

28
00:02:04,486 --> 00:02:09,574
messaggio, il secondo byte sia possibilmente non criptato del tutto. In altre parole, esso

29
00:02:09,574 --> 00:02:14,575
sarà in XOR con zero due volte la probabilità che si suppone debba succedere.

30
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'è

31
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

32
00:02:22,849 --> 00:02:27,818
sono anche polarizzati. E' infatti ora raccomandato che se intendete usare RC4

33
00:02:27,818 --> 00:02:32,800
ciò che dovreste fare è in pratica ignorare i primi 256 byte dell'output e giusto

34
00:02:32,800 --> 00:02:37,246
iniziare usando l'output del generatore iniziando dal byt 257. La prima coppia

35
00:02:37,246 --> 00:02:41,241
di byte risultano essere polarizzati, quindi semplicemente ignorateli. Il secondo attacco che

36
00:02:41,241 --> 00:02:48,482
venne scoperto è che in effetti, se guardate a un output molto lungo di RC4, capita che

37
00:02:48,482 --> 00:02:53,863
sia più facile ottenere la sequenza 00. In altre parole, è più facile

38
00:02:53,863 --> 00:02:58,970
che otteniate sedici bit (due byte) di zero di quanto dobbiate. Di nuovo, se RC4

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

40
00:03:03,948 --> 00:03:08,556
Risulta che RC4 è leggermente polarizzato e la polarizzazione sia il cubo di 1/256.

41
00:03:08,556 --> 00:03:13,718
Risulta che questa polarizzazione in effetti inizi dopo che diversi GByte di dati siano stati prodotti

42
00:03:13,718 --> 00:03:18,634
da RC4. Ma ciononostante, questo è qualcosa che può essere usato per predirre il generatore e

43
00:03:18,634 --> 00:03:23,120
in definitiva può essere usato per distinguere l'output del generatore

44
00:03:23,120 --> 00:03:28,097
da una vera sequenza casuale. Fondamentalmente, il fatto che zero, zero appaia più spesso

45
00:03:28,097 --> 00:03:32,414
di quanto dovrebbe è il discriminante. E quindi nell'ultima sezione abbiamo parlato degli

46
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

47
00:03:36,313 --> 00:03:41,078
qualcuno usa chiavi che sono strettamente connesse l'una con l'altra, allora è in effetti possibile

48
00:03:41,078 --> 00:03:45,732
recuperare la chiave principale. Quindi queste sono debolezze che sono conosciute per RC4 e quindi

49
00:03:45,732 --> 00:03:50,217
si raccomanda che nuovi sistemi in effetti non usino RC4 e invece usino

50
00:03:50,217 --> 00:03:54,421
generatori pseudo-casuali moderni. OK, il secondo esempio che voglio darvi è uno

51
00:03:54,421 --> 00:03:59,131
stream cipher usato per criptare film DVD malamente scardinato. Quando comprate un DVD

52
00:03:59,131 --> 00:04:03,504
in negozio, il film è criptato usando uno stream cipher chiamato

53
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,

54
00:04:07,933 --> 00:04:12,523
e possiamo scardinarlo molto semplicemente. Ora voglio mostrarvi come funziona l'algoritmo di attacco.

55
00:04:12,523 --> 00:04:16,894
Faro' in modo di mostrarvi un esempio di algoritmo di attacco, ma,

56
00:04:16,894 --> 00:04:21,435
in effetti, ci sono molti system che fondamentalmente usano questo attacco per decrittare

57
00:04:21,435 --> 00:04:25,749
DVD criptati. Lo stream cipher CSS è basato su qualcosa che piace

58
00:04:25,749 --> 00:04:30,291
ai progettisti hardware. E' progettato per essere uno stream cipher che si suppone

59
00:04:30,291 --> 00:04:34,491
sia facilmente implementabile in hardware ed è basato su un meccanismo chiamato registro di scorrimento a retroazione

60
00:04:34,491 --> 00:04:38,749
lineare. Un registro a scorrimento con retroazione lineare è fondamentalmente un registro

61
00:04:38,749 --> 00:04:43,801
che consiste in celle, dove ogni cella contiene un bit.

62
00:04:43,801 --> 00:04:49,046
Ciò che succede è che ci sono rubinetti in alcune celle (non tutte), cioè certe

63
00:04:49,046 --> 00:04:54,134
possizioni vengono chiamate "rubinetti". Questi rubinetti alimentano uno XOR e quindi

64
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

65
00:04:59,053 --> 00:05:04,345
e quindi il primo bit diventa il risultato di questo XOR. Potete quindi vedere che

66
00:05:04,345 --> 00:05:08,703
questo è un meccanismo molto semplice da implementare e in hardware impiega veramente

67
00:05:08,703 --> 00:05:13,622
pochi transistors. Giusto lo scorrimento, lo scarto dell'ultimo bit e l'aggiunta di un but

68
00:05:13,622 --> 00:05:18,541
che diventa lo XOR di alcuni bits precedenti. Ciò che serve a questo registro è

69
00:05:18,541 --> 00:05:23,460
fondamentalmente lo stato iniziale.

70
00:05:23,650 --> 00:05:28,538
E questo è la base di un certo numero di stream ciphers. Qui vengono presentati alcuni esempi.

71
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.

72
00:05:33,362 --> 00:05:38,060
Per quanto riguarda la crittografia GSM, ci sono algoritmi chiamati A51 e A52. E questi

73
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

74
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

75
00:05:48,534 --> 00:05:53,245
in realtà non dovrebbero assolutamente essere considerati attendibili per traffico cifrato, ma sono tutti

76
00:05:53,245 --> 00:05:56,705
implementati in hardware, quindi è alquanto difficile oggi cambiare ciò che viene fatto in hardware.

77
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

78
00:06:01,047 --> 00:06:05,459
descrivere come funziona questo attacco. Prima di tutto vediamo come effettivamente funziona CSS.

79
00:06:05,459 --> 00:06:11,073
la chiave di CSS è di cinque bytes, cioè 40 bits (5 volte 8 bit è 40 bit).

80
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

81
00:06:15,587 --> 00:06:19,941
in tempi in cui la legislazione per l'esportazione negli US permetteva solo di esportare algoritmi

82
00:06:19,941 --> 00:06:25,086
di cifratura dove la chiave fosse solo di 40 bits. Quindi i progettisti di CSS

83
00:06:25,086 --> 00:06:30,206
erano già limitati a chiavi molto, motlo corte. Solo 40 bits. Quindi il loro progetto funziona

84
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

85
00:06:35,398 --> 00:06:40,806
il registro contiene 17 bit. E l'altro è di 25 bit.

86
00:06:40,806 --> 00:06:46,647
un pò più lungo, 25 bit. E il modo in cui questi registri vengono alimentati

87
00:06:46,647 --> 00:06:51,870
è il seguente. Quindi la chiave per la cifratura, fondamentalmente è come segue.

88
00:06:51,870 --> 00:06:57,669
Si inizia con un uno, che viene concatenato con i primi due byte

89
00:06:57,669 --> 00:07:02,947
della chiave. E questo è lo stato iniziale del registro.

90
00:07:02,947 --> 00:07:08,256
Il secondo registro fondamentalmente viene inizializzato nello stesso modo.

91
00:07:08,256 --> 00:07:14,012
uno concatenato con gli ultimi tre byte della chiave. E questo

92
00:07:14,012 --> 00:07:19,889
viene caricato nello stato iniziale del registro. Potete vedere che i primi due byte

93
00:07:19,889 --> 00:07:25,411
sono 16 bit, più il primo 1, che sono 17 bit in tutto, mentre il secondo

94
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

95
00:07:31,217 --> 00:07:36,881
della chiave. Quindi questi registri vengono fatti scorrere per otto cicli, generando

96
00:07:36,881 --> 00:07:42,333
8 bit di output. Quindi questi bit vanno un un sommatore che fa in pratica una

97
00:07:42,333 --> 00:07:48,197
somma modulo 256. Corretto, questa è un blocco di addizione modulo 256. C'è inoltre un'altra cosa

98
00:07:48,197 --> 00:07:54,325
che succede. Infatti Infatti... viene aggiunto anche una parte derivante

99
00:07:54,325 --> 00:07:59,723
dal blocco precedente. Ma questo non è importante. Questo è un dettaglio che non è rilevante.

100
00:07:59,723 --> 00:08:04,761
OK, qundi in ogni blocco notate che facciamo un'addizione modulo 256

101
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

102
00:08:09,982 --> 00:08:15,147
all'addizione del blocco successivo. OK? Quindi in pratica questo produce un byte per ciclo.

103
00:08:15,147 --> 00:08:20,411
OK, quindi questo byte viene ovviamente usato, messo in XOR con il relativo

104
00:08:20,411 --> 00:08:25,167
byte del film che è stato criptato. OK, quindi questo è uno stream cipher molto semplice e

105
00:08:25,167 --> 00:08:29,986
impiega molto poco hardware per essere implementato. Viene eseguito velocemente, persino su

106
00:08:29,986 --> 00:08:35,830
hardware molto economico e può criptare film. Risulta che questo sia facilmente scardinabile in un tempo

107
00:08:35,830 --> 00:08:41,222
proporzionale a 2 alla 17. Lasciatemi mostrare come.

108
00:08:41,222 --> 00:08:45,734
Supponiamo che voi intercettiate il film. Quindi abbiamo un

109
00:08:45,734 --> 00:08:50,647
film criptato e voi volete decrittarlo. Quindi, diciamo che questo e completamente criptato in modo

110
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è

111
00:08:55,279 --> 00:08:59,970
la cifratura DVD usa file MPEG, succede che voi sappiate il prefisso del

112
00:08:59,970 --> 00:09:04,250
file in chiaro, diciamo una ventina di byte. Bene, sappiamo che se fate lo XOR

113
00:09:04,250 --> 00:09:08,589
di queste due cose insieme, cioè in altre parole, fate lo XOR qui,

114
00:09:08,589 --> 00:09:13,523
Ciò che ottenete è il segmento iniziale del PRG. Quindi voi ottenete

115
00:09:13,523 --> 00:09:18,472
i primi 20 byte dell'output del CSS, l'output di questo PRG. OK, quindi

116
00:09:18,472 --> 00:09:23,986
ora questo è ciò che faremo. Abbiamo i primi 20 bytes dell'output. Ora

117
00:09:23,986 --> 00:09:31,405
faremo ciò che segue. Tentiamo tutti i 2^17 possibili valori del primo

118
00:09:31,405 --> 00:09:37,088
registro. OK? Quindi tutti i 2^17 valori. Per ogni tentativo, cioè

119
00:09:37,088 --> 00:09:42,622
per ognuno di questi 2^17 valori iniziali del registro, faremo scorrere

120
00:09:42,622 --> 00:09:47,953
i registri per venti byte, ok? Quindi genereremo 20 byte di output da questo

121
00:09:47,953 --> 00:09:53,284
primo registro, assumendo... per ognuno dei 2^17 possibili settaggi.

122
00:09:53,284 --> 00:09:58,615
Ora, considerate che conosciamo l'output completo del sistema CSS, Quindi ciò cjhe possiamo fare è

123
00:09:58,615 --> 00:10:03,814
prendere questo output che conosciamo e sottrarlo dai venti byte che

124
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

125
00:10:08,928 --> 00:10:14,042
è corretto, ciò che dovremmo ottenere sono i primi 20 byte del

126
00:10:14,042 --> 00:10:19,222
secondo registro. Giusto? Perchè questo è per definizione l'output del sistema CSS.

127
00:10:19,222 --> 00:10:24,501
Ora, risulta che guardando la sequenza di 20 byte, è molto semplice

128
00:10:24,501 --> 00:10:29,763
dire se questa sequenza di 20 byte è uscita dal secondo registro oppure no. Se non lo è

129
00:10:29,763 --> 00:10:33,561
sappiamo che il nostro tentativo per il primo registro a 17 bit era

130
00:10:33,561 --> 00:10:37,416
incorretto e quindi andiamo avanti con il prossimo tentativo per il registro a 17 bit e

131
00:10:37,416 --> 00:10:41,904
quindi quello successivo e così via. Finchè alla fine indoviniamo lo stato iniziale corretto

132
00:10:41,904 --> 00:10:46,937
pòer il registro a 17 bit e quindi siamo arrivati, vedremo che

133
00:10:46,937 --> 00:10:51,969
i 20 byte che otteniamo come output candidato dal registro a 25 bit è

134
00:10:51,969 --> 00:10:56,936
in effetti un possibile output per il registro a 25 bit. E ora, non solo abbiamo

135
00:10:56,936 --> 00:11:02,164
imparato il corretto stato iniziale per il registro a 17 bit, noi avremo anche

136
00:11:02,164 --> 00:11:07,523
imparato il corretto stato iniziale del registro a 25 bit. E quindi possiamo predirre l'output

137
00:11:07,523 --> 00:11:12,796
rimanente del CSS e, ovviamnte, usando questo, possiamo decrittare il resto del

138
00:11:12,796 --> 00:11:17,565
film. Possiamo recuperare la rimanente parte in chiaro. Ok. Questo è ciò

139
00:11:17,565 --> 00:11:22,335
di cui abbiamo parlato prima. L'ho spiegato un pò velocemente, ma, spero, chiaramente.

140
00:11:22,335 --> 00:11:27,331
Stiamo per fare un esercizio come compito a casa su questo tipo di stream ciphers

141
00:11:27,331 --> 00:11:31,444
e voi potrete capire come questi algoritmi di attacco

142
00:11:31,444 --> 00:11:36,018
funzionano. Dovrei dire che ci sono diversi sistemi open-source oggi che in realtà

143
00:11:36,018 --> 00:11:41,453
usano questo metodo per decrittare dati criptati con CSS. OK, quindi ora che abbiamo visto due

144
00:11:41,453 --> 00:11:45,888
esempi deboli, spostiamoci verso esempi migliori, e in particolare

145
00:11:45,888 --> 00:11:49,370
i generatori pseudo-random che vengono da quello che viene chiamato il Progetto eStream. Questo è un

146
00:11:49,370 --> 00:11:55,556
progetto che si è concluso nel 2008 e che ha qualificato cinque diversi stream

147
00:11:55,556 --> 00:12:00,207
cipher, ma qui voglio presentarne solo uno. Prima di tutto, i parametri per

148
00:12:00,207 --> 00:12:04,029
questi stream cipher sono un pò diversi da quelli a cui siamo abituati. Questi

149
00:12:04,029 --> 00:12:08,340
stream cipher di norma hanno un seme. Ma inoltre hanno anche ciò

150
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,

151
00:12:12,821 --> 00:12:17,487
si prendono due input, un seme e un nonce. Vedremo come viene usato un nonce tra

152
00:12:17,487 --> 00:12:21,274
giusto un secondo. Si produce ovviamente un output molto grande, quindi n è ora

153
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à

154
00:12:26,603 --> 00:12:31,218
mai finchè rimane fissata la chiave. Spiegherò tutto questo tin maggiori

155
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

156
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)

157
00:12:40,527 --> 00:12:45,357
potrete cifrare e otenere uno stream cipher come prima, eccetto che ora, come vedete, il

158
00:12:45,357 --> 00:12:49,955
PRG prende come input sia la chiave che il nonce. E la proprietà del nonce è

159
00:12:49,955 --> 00:12:56,350
che la coppia (k,r), cioè (chiave,nonce) non si ripete mai. Non viene

160
00:12:56,350 --> 00:13:03,096
mai usata più di una volta. Quindi la conclusione è che potete riusare la chiave,

161
00:13:03,096 --> 00:13:09,710
riusare la chiave, perchè il nonce rende la coppia unica, perchè k ed r sono usati

162
00:13:09,710 --> 00:13:16,135
solo una volta. Cioè sono unici. Ok, quindi questo nonce è qualcosa come uno stratagemma simpatico che

163
00:13:16,135 --> 00:13:21,541
ci risparmia la necessità di utilizzare una nuova chiave ogni volta. ok, l'esempio particolare

164
00:13:21,541 --> 00:13:26,000
che proviene da eStream che voglio mostrarvi è chiamato Salsa20. E' uno

165
00:13:26,000 --> 00:13:30,292
stream cipher che è stato progettato per implementazioni sia hardware che software.

166
00:13:30,292 --> 00:13:33,385
E' piuttosto interessante. Capite che alcni stream ciphers sono

167
00:13:33,385 --> 00:13:38,763
progettati per implementazioni software, come RC4. Tutto ciò che fa è progettato per rendere

168
00:13:38,763 --> 00:13:42,689
l'implementazione software molto veloce, mentre altri stream ciphers sono progettati

169
00:13:42,689 --> 00:13:48,143
per l'hardware, come il CSS, usando un registro di scorrimento che è particolarmente progettato per rendere

170
00:13:48,143 --> 00:13:50,963
l'implementazione hardware molto economica. La cosa interessante in questo senso è che

171
00:13:50,963 --> 00:13:55,008
esso è progettato in modo che sia semplice da implementare in hardware e che la sua

172
00:13:55,008 --> 00:13:59,747
implementazione software sia anche molto veloce. Quindi lasciatemi spiegare come funziona Salsa. Bene, Salsa

173
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.

174
00:14:05,130 --> 00:14:11,244
Quindi, questo è il seme. E prende anche un nonce, come prima, che

175
00:14:11,244 --> 00:14:15,425
risulta essere di 64 bit. Quindi genera un output lungo. Ora, come funziona

176
00:14:15,425 --> 00:14:21,060
realmente? Bene, la funzione stessa è definita nel modo seguente. Fondamentalmente, data

177
00:14:21,060 --> 00:14:26,378
la chiave e il nonce, esso genererà una sequenza pseudorandom molto lunga.

178
00:14:26,378 --> 00:14:31,222
cioè lunga quanto necessario. E lo farà usando questa funzione che chiamerò

179
00:14:31,222 --> 00:14:35,653
H. Questa funzione H prende tre input. Fondamentalmente la chiave, il seme,

180
00:14:35,653 --> 00:14:40,498
il nonce r e un contatore che incrementa passo passo. Cioè va

181
00:14:40,498 --> 00:14:45,263
da zero a uno, due, tre, quattro finchè serve. Ok? Quindi, fondamentalmente,

182
00:14:45,263 --> 00:14:49,956
calcolando questo H su questi k ed r, ma usando questo contatore incrementale, possiamo ottenere

183
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

184
00:14:54,882 --> 00:14:59,460
H. Ora, lasciatemi fare questo per voi. Il modo in cui funziona è il seguente. Bene, partiamo

185
00:14:59,460 --> 00:15:04,693
espandendo gli stati in qualcosa di piuttosto largo che è lungo 64 byte

186
00:15:04,693 --> 00:15:10,156
e lo facciamo nel modo seguente. Fondamentalmente prendiamo una costante all'inizio, quindi

187
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

188
00:15:15,552 --> 00:15:20,611
danno il valore per questa tao di zero. Quindi mettiamo k in 16

189
00:15:20,611 --> 00:15:25,467
bytes. Quindi mettiamo un'altra costante. Di nuovo di quattro byte. E, come ho detto,

190
00:15:25,467 --> 00:15:30,795
la specifica specifica anche questa costante fissa. Quindi mettiamo

191
00:15:30,795 --> 00:15:37,435
il nonce, che è di otto byte. Quindi mettiamo l'indice. Questo è il contatore zero,

192
00:15:37,435 --> 00:15:43,063
uno, due, tre, quattro che è di nuovo fatto da otto byte. Quindi mettiamo un'altra costante

193
00:15:43,063 --> 00:15:49,056
tau due, che sono altri quattro byte. Quindi mettiamo la chiave di nuovo, che fanno

194
00:15:49,056 --> 00:15:54,714
altri sedici byte. E quindi infine mettiamo la terza costante, tau tre, che sono

195
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.

196
00:15:59,948 --> 00:16:05,249
Quindi, fondamentalmente, abbiamo sepanso la chiave e il nonce e il contatore fino a 64

197
00:16:05,249 --> 00:16:10,886
byte. Fondamentalmente la chiave viene ripetuta due volte. E quindi quello che facciamo è applicare

198
00:16:10,886 --> 00:16:16,321
la funzione. Chiamerò questa funzione h piccolo. Ok, qindi applichiamo questa funzione h piccolo.

199
00:16:16,321 --> 00:16:21,659
E questa è una funzione che è uno a uno, quindi mappa 64 byte in 64 byte. E'

200
00:16:21,659 --> 00:16:26,005
una funzione completamente invertibile, ok? Quindi, questa funzione h è, come ho detto, una

201
00:16:26,005 --> 00:16:30,260
funzione invertibile. Quindi, dato l'iinput voi ottenete l'output e dato

202
00:16:30,260 --> 00:16:34,906
l'output voi potete ritornare all'input. Ed è progettata specificatamente in questo modo, quindi è a - facilmente

203
00:16:34,906 --> 00:16:39,553
implementabile in hardware e b- su un x86 è estremamente facile da implementare, perchè

204
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

205
00:16:44,199 --> 00:16:48,622
questa funzione. Ed è molto, molto veloce. Di conseguenza, Salsa è uno stream cipher molto veloce.

206
00:16:48,622 --> 00:16:52,764
E queste operazioni vengono fatte ancora e ancora. Quindi si applica la funzione

207
00:16:52,764 --> 00:16:57,744
h ancora e si ottiengono altri 64 bytes. E via di seguito, fondamentalmente

208
00:16:57,744 --> 00:17:05,318
lo si fa dieci volte. ok, l'intera operazione è quindi ripetere 10 volte, cioè applicare

209
00:17:05,318 --> 00:17:17,961
10 volte la funzione h. Quindi, di per se stessa, non è in effetti molto random.

210
00:17:17,961 --> 00:17:22,144
Non sembra random perchè, come abbiamo detto, H è completamente invertibile. Quindi dato

211
00:17:22,144 --> 00:17:25,521
l'output finale, è mlto semplice invertire h e quindi tornare indietro agli input originali

212
00:17:25,521 --> 00:17:31,831
e quindi verificare che l'input ha la struttura corretta. Quindi si fa un'altra

213
00:17:31,831 --> 00:17:36,979
cosa, che è fondamentalmente un XOR tra gli input e gli output finali. In realtà,

214
00:17:36,979 --> 00:17:42,405
scusate, non è uno XOR. è in effetti un'addizione. Quindi fate un'addizione parola per parola.

215
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

216
00:17:47,762 --> 00:17:52,980
e alla fine ottenete l'output di 64 byte e questo è tutto. Questo è l'intero generatore

217
00:17:52,980 --> 00:17:57,175
pseudo-random. Quindi questa è l'intera funzione h piccolo. E, come ho

218
00:17:57,175 --> 00:18:01,758
spiegato, questa intera costruzione è la funzione H grande. E quindi calcolate

219
00:18:01,758 --> 00:18:06,009
H grande incrementando il contatore I da zero, uno, due, tre in avanti. E questo

220
00:18:06,009 --> 00:18:10,408
vi fornirà una sequenza pseudo-casuale che è lunga quanto vi serve. E

221
00:18:10,408 --> 00:18:15,325
fondamentalmente, non ci sono attacchi significativi su questo algoritmo. Questo ha una sicurezza che è

222
00:18:15,325 --> 00:18:20,371
molto vicina a 2 alla 128. edremo cosa significa questo più tardi.

223
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,

224
00:18:25,417 --> 00:18:30,431
esso sembra impredicibile quanto richiesto per uno stream cipher. Quindi

225
00:18:30,431 --> 00:18:34,797
dovrei dire che il progetto eStream effettivamente ha cinque stream cipher come

226
00:18:34,797 --> 00:18:39,395
questo. Ho scelto Salsa20 perchè pernso sia il più elegante. Ma posso darvi

227
00:18:39,395 --> 00:18:44,053
alcuni parametri di performance. Potete vedere che questi sonoparametri di performance su

228
00:18:44,053 --> 00:18:48,768
una macchina x86 a 2.2 GHz. E potete vedere che RC4 è effettivmente

229
00:18:48,768 --> 00:18:53,017
il più lento. Perchè essenzialmente, beh esso non sfrutta

230
00:18:53,017 --> 00:18:57,475
l'hardware. Esso fa solo operazioni su byte. E quindi ci sono molti cicli sprecati

231
00:18:57,475 --> 00:19:01,182
che non vengono utilizzati. Ma i candidati eStream, sia Salsa che l'altro dandidato

232
00:19:01,182 --> 00:19:05,202
chiamato Sosemanuk, questi sono i finalisti eStream. Questi sono

233
00:19:05,202 --> 00:19:09,588
in effetti gli stream ciphers che sono stati approvati dal progetto eStream. Potete vedere che

234
00:19:09,588 --> 00:19:13,712
hanno raggiunto una velocità significativa. Questo è 643 MB/s su questa

235
00:19:13,712 --> 00:19:18,150
architettura, più del necessario per un video e questi sono in effetti velocità piuttosto impressionanti

236
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,

237
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

238
00:19:26,661 --> 00:19:30,480
con questo nonce. E vedete i numeri di performance per questi

239
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

240
00:19:34,546 --> 00:19:37,991
finalisti del progetto eStream. In particolare potreste usare qualcosa come Salsa.