1
00:00:00,000 --> 00:00:04,010
Neste segmento, eu quero dar alguns exemplos de fluxo cifras que são usados na prática.

2
00:00:04,010 --> 00:00:07,072
Vou começar com dois exemplos antigos que na verdade não são

3
00:00:07,072 --> 00:00:11,017
suposto ser usado em sistemas novos. Mas, no entanto, eles ainda são bastante

4
00:00:11,017 --> 00:00:14,164
amplamente utilizada, e assim que eu apenas quero mencionar os nomes para que você esteja familiarizado com

5
00:00:14,164 --> 00:00:19,087
esses conceitos. A cifra de fluxo primeiro eu quero falar é chamado RC4, projetado

6
00:00:19,087 --> 00:00:23,429
em 1987. E eu só vou te dar a descrição de alto nível e, em seguida

7
00:00:23,429 --> 00:00:27,818
nós vamos falar sobre alguns pontos fracos do RC4 e deixar por isso mesmo. Assim RC4 leva um

8
00:00:27,818 --> 00:00:32,702
sementes de tamanho variável, aqui eu só dei como um exemplo onde levaria 128

9
00:00:32,702 --> 00:00:36,980
bits como o tamanho das sementes, que passaria então a ser utilizados como chave para a cifra de fluxo.

10
00:00:36,980 --> 00:00:41,738
A primeira coisa que faz, é que se expande a chave de 128-bit segredo em 2.048 bits, que

11
00:00:41,738 --> 00:00:46,382
vão ser usados como o estado interno para o gerador. E então, quando ele é feito

12
00:00:46,382 --> 00:00:51,197
esta expansão, que basicamente executa um laço muito simples, onde cada iteração do

13
00:00:51,197 --> 00:00:55,898
laço Isso gera um byte de saída. Então, basicamente, você pode executar o gerador de

14
00:00:55,898 --> 00:01:00,653
, enquanto você quer, e gerar um byte de cada vez. Agora RC4 é, na verdade, como eu disse,

15
00:01:00,653 --> 00:01:05,205
bastante popular. É usado no protocolo HTTPS é bastante comum, na verdade.

16
00:01:05,205 --> 00:01:11,888
Estes dias, por exemplo, o Google usa RC4 em suas HTTPS. Também é usado no WEP como nós

17
00:01:11,888 --> 00:01:15,686
discutido no último segmento, mas é claro que no WEP, ele é usado incorretamente e

18
00:01:15,686 --> 00:01:18,861
é completamente inseguro da forma como ele é usado dentro do WEP. Assim, ao longo dos anos,

19
00:01:18,861 --> 00:01:23,886
algumas deficiências foram encontradas no RC4, e como resultado, é recomendado que os novos projetos

20
00:01:23,886 --> 00:01:28,793
na verdade não usar RC4, mas sim usar um mais moderno gerador pseudo-aleatório como veremos

21
00:01:28,793 --> 00:01:34,059
discutir para a extremidade do segmento. Então deixe-me mencionar apenas dois dos pontos fracos.

22
00:01:34,059 --> 00:01:39,561
Então a primeira é que é tipo de bizarra, basicamente, se você olhar para o segundo byte

23
00:01:39,561 --> 00:01:44,630
da produção de RC4. Acontece que o segundo byte é um pouco tendencioso. Se RC4 foi

24
00:01:44,630 --> 00:01:49,780
completamente aleatória, a probabilidade de que o segundo byte acontece ser igual a zero

25
00:01:49,780 --> 00:01:54,744
seria exatamente um sobre 256. Existem 256 bytes possíveis, a probabilidade que

26
00:01:54,744 --> 00:01:59,646
zero, deveria ser um sobre 256. Acontece que para RC4 a probabilidade é

27
00:01:59,646 --> 00:02:04,486
realmente dois por 256, o que significa que se você usar a saída RC4 para criptografar uma

28
00:02:04,486 --> 00:02:09,574
mensagem do segundo byte é provável que não seja encriptada de todo. Em outras palavras, ele vai

29
00:02:09,574 --> 00:02:14,575
ser XOR-ed com zero com o dobro da probabilidade de que é suposto.

30
00:02:14,575 --> 00:02:19,436
Assim, dois sobre 256, em vez de um sobre 256. E pelo jeito que eu deveria dizer que há

31
00:02:19,436 --> 00:02:22,849
nada de especial sobre o segundo byte. Acontece que a primeira e os bytes terceiros

32
00:02:22,849 --> 00:02:27,818
também são tendenciosos. E de fato ele é agora recomendado que se você vai usar RC4,

33
00:02:27,818 --> 00:02:32,800
que você deve fazer é ignorar, basicamente, os primeiros 256 bytes da saída e apenas

34
00:02:32,800 --> 00:02:37,246
começar a utilizar a saída do gerador a partir de byte 257. O primeiro casal

35
00:02:37,246 --> 00:02:41,241
de bytes acabou por ser tendencioso, então você simplesmente ignorá-los. O segundo ataque que

36
00:02:41,241 --> 00:02:48,482
foi descoberto é que de fato se você olhar para uma saída muito longo de RC4 que acontece

37
00:02:48,482 --> 00:02:53,863
que você é mais provável conseguir o 00 de seqüência. Em outras palavras, você é mais

38
00:02:53,863 --> 00:02:58,970
probabilidade de obter dezesseis bits, dois bytes de zero, zero, do que deveria. Novamente, se RC4

39
00:02:58,970 --> 00:03:03,948
foi completamente aleatória a probabilidade de ver zero, zero seria exatamente 1/256

40
00:03:03,948 --> 00:03:08,556
quadrado. Acontece RC4 é um pouco tendencioso eo viés é 1/256 cubos. Ele

41
00:03:08,556 --> 00:03:13,718
Acontece que este viés realmente começa depois de vários gigabytes de dados são produzidos por

42
00:03:13,718 --> 00:03:18,634
RC4. Mas, no entanto, este é algo que pode ser utilizado para prever o gerador

43
00:03:18,634 --> 00:03:23,120
e, definitivamente, ele pode ser usado para distinguir a saída do gerador

44
00:03:23,120 --> 00:03:28,097
partir de uma seqüência verdadeiramente aleatória. Basicamente o fato de que zero, zero aparece com mais freqüência

45
00:03:28,097 --> 00:03:32,414
do que deveria é o Distinguisher. E então, no último segmento que falamos

46
00:03:32,414 --> 00:03:36,313
relacionado-chave ataques que foram usados para atacar WEP, que basicamente dizem que

47
00:03:36,313 --> 00:03:41,078
se teclas de um utilizações que estão intimamente relacionadas entre si, então é realmente possível

48
00:03:41,078 --> 00:03:45,732
para recuperar a chave raiz. Assim, estes são os pontos fracos que são conhecidos de RC4 e, como um

49
00:03:45,732 --> 00:03:50,217
resultado, é recomendado que os novos sistemas não realmente usar RC4 e utilizar um

50
00:03:50,217 --> 00:03:54,421
gerador pseudo-aleatório moderna. Ok, segundo exemplo que quero dar-lhe é um

51
00:03:54,421 --> 00:03:59,131
cifra de fluxo gravemente quebrado que é usada para criptografar filmes em DVD. Quando você compra um DVD

52
00:03:59,131 --> 00:04:03,504
na loja, o próprio filme é criptografada usando uma cifra de fluxo chamado de

53
00:04:03,504 --> 00:04:07,933
Content Scrambling System, CSS. CSS acaba por ser uma cifra de fluxo gravemente quebrado

54
00:04:07,933 --> 00:04:12,523
e podemos muito facilmente quebrá-lo, e eu quero mostrar-lhe como o algoritmo de ataque

55
00:04:12,523 --> 00:04:16,894
obras. Estamos fazendo isso para que você possa ver um exemplo de um algoritmo de ataque, mas em

56
00:04:16,894 --> 00:04:21,435
verdade, existem muitos sistemas por aí que, basicamente, usar este ataque para descriptografar

57
00:04:21,435 --> 00:04:25,749
DVDs criptografados. Assim, a cifra de fluxo CSS é baseada em algo que o hardware

58
00:04:25,749 --> 00:04:30,291
projetistas gosta. Ele foi projetado para ser uma cifra de fluxo de hardware que é suposto

59
00:04:30,291 --> 00:04:34,491
ser fácil de implementar em hardware, e baseia-se um mecanismo chamado linear

60
00:04:34,491 --> 00:04:38,749
mudança comentários registar. Assim, um registrador de deslocamento linear feedback é basicamente um registo

61
00:04:38,749 --> 00:04:43,801
que consiste em células em que cada célula contém um bit. Então, basicamente,

62
00:04:43,801 --> 00:04:49,046
que acontece é que existem estas torneiras em certas células, não todas as células, certos

63
00:04:49,046 --> 00:04:54,134
posições são chamados torneiras. E então essas torneiras alimentar em um XOR e, em seguida, em

64
00:04:54,134 --> 00:04:59,053
cada ciclo de clock, o registrador de deslocamento desloca para a esquerda. O último pedaço cair

65
00:04:59,053 --> 00:05:04,345
e, em seguida, o primeiro bit torna-se o resultado deste XOR. Assim você pode ver que

66
00:05:04,345 --> 00:05:08,703
este é um mecanismo muito simples de implementar, e em hardware tem muito poucos

67
00:05:08,703 --> 00:05:13,622
transistores. Apenas o deslocamento para a direita, o último bit cai e apenas o primeiro bit

68
00:05:13,622 --> 00:05:18,541
torna-se o XOR dos bits anteriores. Assim, a semente para este LFSR

69
00:05:18,541 --> 00:05:23,460
, basicamente, é o estado inicial do LFSR.

70
00:05:23,650 --> 00:05:28,538
E é a base de uma série de codificações de fluxo. Então, aqui estão alguns exemplos. Assim, como

71
00:05:28,538 --> 00:05:33,362
eu disse, a criptografia utiliza duas LFSRs DVD. Eu vou te mostrar como isso funciona em apenas um

72
00:05:33,362 --> 00:05:38,060
segundo. Criptografia GSM, estes são chamados algoritmos A51 e A52. E isso

73
00:05:38,060 --> 00:05:43,456
utiliza três LFSRs. Criptografia Bluetooth é um algoritmo chamado, E zero. Estes são todos

74
00:05:43,456 --> 00:05:48,534
cifras de fluxo, e que utiliza quatro LFSRs. Acontece que todos eles são gravemente quebrado

75
00:05:48,534 --> 00:05:53,245
e na verdade realmente não deve ser confiável para criptografar o tráfego, mas todos eles são

76
00:05:53,245 --> 00:05:56,705
implementado em hardware, por isso é um pouco difícil agora para mudar o que o hardware

77
00:05:56,705 --> 00:06:01,047
faz. Mas o mais simples deles, CSS, na verdade, tem um ataque bonito nele, então vamos

78
00:06:01,047 --> 00:06:05,459
me mostrar-lhe como o ataque funciona. Então, vamos descrever como o CSS realmente funciona. Assim,

79
00:06:05,459 --> 00:06:11,073
chave para o CSS é de cinco bytes, ou seja, 40 bits, cinco vezes oito é de 40 bits. O

80
00:06:11,073 --> 00:06:15,587
razão eles tinham que se limitar a apenas 40 bits é que a criptografia do DVD foi

81
00:06:15,587 --> 00:06:19,941
concebidos numa altura em que os regulamentos de exportação dos Estados Unidos só é permitido para a exportação de

82
00:06:19,941 --> 00:06:25,086
algoritmos crpyto onde estava a chave apenas 40 bits. Assim, os designers de CSS foram

83
00:06:25,086 --> 00:06:30,206
já limitados a chaves muito, muito curtos. Apenas 40 teclas bit. Assim, seu projeto trabalha

84
00:06:30,206 --> 00:06:35,398
como se segue. Basicamente, o CSS usa duas LFSR do. Um é um LFSR de 17-bit. Em outras palavras,

85
00:06:35,398 --> 00:06:40,806
registo a contém 17 bits. Eo outro é um LFSR 25-bit,

86
00:06:40,806 --> 00:06:46,647
é um pouco mais, 25 bits LFSR. E a forma como estas são semeadas LFSRs

87
00:06:46,647 --> 00:06:51,870
é como se segue. Portanto, a chave para a criptografia, basicamente, tem a seguinte aparência.

88
00:06:51,870 --> 00:06:57,669
Você começa com um, e você concatenar a ele os dois primeiros bytes de

89
00:06:57,669 --> 00:07:02,947
chave. E esse é o estado inicial do LFSR.

90
00:07:02,947 --> 00:07:08,256
E então o segundo LFSR basicamente é intitialized da mesma maneira.

91
00:07:08,256 --> 00:07:14,012
Uma concatenado os últimos três bytes da chave. E isso é

92
00:07:14,012 --> 00:07:19,889
carregado para o estado inicial do LFSR. Você pode ver que os dois primeiros bytes são

93
00:07:19,889 --> 00:07:25,411
16 bits, mais um líder, que tem dezessete pedaços geral, enquanto o segundo

94
00:07:25,411 --> 00:07:31,217
LFSR é de 24 bits, mais um que é de 25 bits. E você percebe usamos todos os cinco pedaços de

95
00:07:31,217 --> 00:07:36,881
chave. Então essas são basicamente LFSRs correr para oito ciclos, de modo que elas geram

96
00:07:36,881 --> 00:07:42,333
oito bits de saída. E então eles passam por este componente que faz basicamente

97
00:07:42,333 --> 00:07:48,197
adição módulo 256. É assim que esta é uma caixa disso, módulo 256. Há mais uma

98
00:07:48,197 --> 00:07:54,325
coisa técnica que acontece. Na verdade vamos realmente, também adicionada é o transporte do

99
00:07:54,325 --> 00:07:59,723
bloco anterior. Mas isso não é tão importante. Isso é um detalhe que não é tão

100
00:07:59,723 --> 00:08:04,761
relevante. OK, então todos os blocos, você percebe que estamos fazendo além modulo 256 e

101
00:08:04,761 --> 00:08:09,982
estamos ignorando o transporte, mas o transporte é basicamente adicionado como um zero ou um um ao

102
00:08:09,982 --> 00:08:15,147
além do bloco seguinte. Ok? E então, basicamente, esta saída um byte por round.

103
00:08:15,147 --> 00:08:20,411
Ok, e então este byte é usado, então é claro, XOR-ed com o adequado

104
00:08:20,411 --> 00:08:25,167
byte do filme que está sendo criptografado. Ok, então é um fluxo muito simples

105
00:08:25,167 --> 00:08:29,986
cifra, é preciso hardware muito pouco para implementar. Ele irá correr rápido, mesmo em muito

106
00:08:29,986 --> 00:08:35,830
hardware barato e vai criptografar filmes. Então, acontece que este é fácil de quebrar

107
00:08:35,830 --> 00:08:41,222
no tempo cerca de dois a 17. Agora deixe-me mostrar-lhe como.

108
00:08:41,222 --> 00:08:45,734
Então, suponha que você interceptar os filmes, então aqui nós temos um

109
00:08:45,734 --> 00:08:50,647
filme criptografado que você deseja descriptografar. Então, digamos que tudo isso é criptografado para

110
00:08:50,647 --> 00:08:55,279
você não tem idéia do que está dentro de aqui. No entanto, acontece que só porque

111
00:08:55,279 --> 00:08:59,970
criptografia DVD está usando arquivos MPEG, acontece se você souber de um prefixo da

112
00:08:59,970 --> 00:09:04,250
texto simples, vamos apenas dizer que talvez esta é de vinte bytes. Bem, sabemos que se você

113
00:09:04,250 --> 00:09:08,589
XOR essas duas coisas juntas, então, em outras palavras, você faz o XOR aqui,

114
00:09:08,589 --> 00:09:13,523
que você vai conseguir é o segmento inicial do PRG. Assim, você terá a

115
00:09:13,523 --> 00:09:18,472
primeiros vinte bytes de a saída do CSS, a saída do presente PRG. Ok, então agora

116
00:09:18,472 --> 00:09:23,986
aqui é o que nós vamos fazer. Assim, temos os primeiros vinte bytes de saída. Agora

117
00:09:23,986 --> 00:09:31,405
nós fazemos o seguinte. Nós experimentar todos dois para os valores possíveis de 17 a primeira

118
00:09:31,405 --> 00:09:37,088
LFSR. Ok? Assim, duas aos dezassete valores possíveis. Assim, para cada valor, portanto, para

119
00:09:37,088 --> 00:09:42,622
cada um destes dois aos dezassete valores iniciais do LFSR, vamos executar o

120
00:09:42,622 --> 00:09:47,953
LFSR por vinte bytes, ok? Então, vamos gerar de vinte bytes de saídas a partir deste

121
00:09:47,953 --> 00:09:53,284
LFSR primeiro, assumindo-para cada um dos dois para os dezassete configurações possíveis.

122
00:09:53,284 --> 00:09:58,615
Agora, lembre-se que temos o resultado completo do sistema de CSS. Então o que podemos fazer é nos

123
00:09:58,615 --> 00:10:03,814
pode tomar esta saída que temos. E subtrair os vinte mordidas que nós

124
00:10:03,814 --> 00:10:08,928
obtido a partir do LFSR primeiro, e se de fato o nosso palpite para o estado inicial do primeiro

125
00:10:08,928 --> 00:10:14,042
LFSR está correta, o que devemos começar é a saída 20-primeiro byte do

126
00:10:14,042 --> 00:10:19,222
LFSR segundo. Certo? Porque isso é, por definição, o que a saída do CSS

127
00:10:19,222 --> 00:10:24,501
sistema é. Agora, descobre-se que olhar para uma seqüência de 20 bytes, é muito fácil

128
00:10:24,501 --> 00:10:29,763
dizer se essa seqüência de 20-byte veio de um LFSR 25-bit ou não. Se

129
00:10:29,763 --> 00:10:33,561
não, então sabemos que o nosso palpite para o LFSR 17-bit foi

130
00:10:33,561 --> 00:10:37,416
incorreto e, em seguida, passamos para o próximo palpite para o LFSR 17-bit e

131
00:10:37,416 --> 00:10:41,904
suposição o seguinte e assim por diante e assim por diante. Até que finalmente chegamos ao direito inicial

132
00:10:41,904 --> 00:10:46,937
estado para o LFSR 17-bit, e depois vamos realmente começar, vamos ver que

133
00:10:46,937 --> 00:10:51,969
os 20 bytes que obtemos como a saída candidato para o LFSR 25-bit é

134
00:10:51,969 --> 00:10:56,936
, de facto, uma saída possível para um LFSR 25-bit. E então, não só teremos

135
00:10:56,936 --> 00:11:02,164
aprendeu o estado inicial correto para o LFSR 17-bit, nós também teremos

136
00:11:02,164 --> 00:11:07,523
aprendeu o estado inicial correto do LFSR 25-bit. E então podemos prever o

137
00:11:07,523 --> 00:11:12,796
saídas restantes do CSS, e é claro, usar isso, podemos, então, decifrar o resto

138
00:11:12,796 --> 00:11:17,565
o filme. Na verdade, podemos recuperar o texto restante. Okay. Isto é

139
00:11:17,565 --> 00:11:22,335
coisas que falamos antes. Então, eu disse isso um pouco rápido, mas espero que,

140
00:11:22,335 --> 00:11:27,331
ficou claro. Nós também vamos estar fazendo um exercício de dever de casa neste tipo de fluxo

141
00:11:27,331 --> 00:11:31,444
cifras e você vai espécie de chegar ao ponto de como esses algoritmos de ataque

142
00:11:31,444 --> 00:11:36,018
trabalho. E devo mencionar que existem muitos sistemas open-source, agora que realmente

143
00:11:36,018 --> 00:11:41,453
usar esse método para descriptografar CSS dados criptografados. Ok, então agora que já vimos dois

144
00:11:41,453 --> 00:11:45,888
fracos exemplos, vamos passar para exemplos melhores, e em particular o melhor

145
00:11:45,888 --> 00:11:49,370
pseudo-aleatórios geradores vêm do que é chamado de Projeto eSTREAM. Esta é uma

146
00:11:49,370 --> 00:11:55,556
projeto que concluiu em 2008, e que se qualifiquem, basicamente, cinco fluxo diferente

147
00:11:55,556 --> 00:12:00,207
cifras, mas aqui quero apresentar apenas um. Então, primeiro de todos os parâmetros para

148
00:12:00,207 --> 00:12:04,029
essas cifras de fluxo é um pouco diferente do que estamos acostumados. Então, essas

149
00:12:04,029 --> 00:12:08,340
fluxo cifras normalmente eles têm uma semente. Mas, além disso eles também têm, o que é

150
00:12:08,340 --> 00:12:12,821
chamado nonce e vamos ver o que é um nonce é usada em apenas um minuto. Assim

151
00:12:12,821 --> 00:12:17,487
tomam duas entradas de uma semente e um nonce. Vamos ver o que o nonce é usada no

152
00:12:17,487 --> 00:12:21,274
apenas um segundo. E claro que o de produzir uma saída muito grande, então n é aqui

153
00:12:21,274 --> 00:12:26,603
muito, muito, muito maior do que s. Agora, quando eu digo nonce, o que quero dizer é um valor que é

154
00:12:26,603 --> 00:12:31,218
nunca indo para repetir enquanto a chave é fixo. E eu vou explicar isso em mais

155
00:12:31,218 --> 00:12:35,400
detalhe em apenas um segundo. Mas, por agora, basta pensar nisso como um valor único que nunca

156
00:12:35,400 --> 00:12:40,527
repete, desde que a chave é a mesma. E então é claro que quando você tem este PRG,

157
00:12:40,527 --> 00:12:45,357
você criptografar, você obtém uma cifra de fluxo tal como antes, só que agora como você vê, o

158
00:12:45,357 --> 00:12:49,955
PRG toma como entrada tanto a chave eo nonce. E a propriedade do nonce é

159
00:12:49,955 --> 00:12:56,350
que o par, k vírgula r, de modo a vírgula chave nonce, é nunca, nunca se repete. É

160
00:12:56,350 --> 00:13:03,096
nunca usou mais de uma vez. Assim a linha inferior é que você pode reutilizar a chave, reutilizar

161
00:13:03,096 --> 00:13:09,710
a chave, porque o uso único faz com que o par único, porque K e R são apenas

162
00:13:09,710 --> 00:13:16,135
usado uma vez. Eu vou dizer que é único. Ok então este nonce é uma espécie de truque bonito que

163
00:13:16,135 --> 00:13:21,541
nos salva a dificuldade de se mudar para uma nova chave de cada vez. Ok, então o particular

164
00:13:21,541 --> 00:13:26,000
exemplo do eSTREAM que eu quero lhe mostrar é chamado Salsa 20. É uma

165
00:13:26,000 --> 00:13:30,292
cifra de fluxo que é projetado para implementações de software e hardware

166
00:13:30,292 --> 00:13:33,385
implementações. É uma espécie de interessante. Você percebe que algumas cifras de fluxo são

167
00:13:33,385 --> 00:13:38,763
projetado para software, como RC4. Tudo que ele faz é projetado para fazer

168
00:13:38,763 --> 00:13:42,689
implementação de software de correr rápido, enquanto o fluxo cifras outros são projetados para

169
00:13:42,689 --> 00:13:48,143
hardware, como CSS, utilizando um LFSR que está particularmente desenhado para fazer hardware

170
00:13:48,143 --> 00:13:50,963
implementações muito baratos. É também, a única coisa boa disso é que é

171
00:13:50,963 --> 00:13:55,008
projetado de modo que seja fácil de implementar em hardware e seu software

172
00:13:55,008 --> 00:13:59,747
implementação também é muito rápido. Então deixe-me explicar como Salsa obras. Bem, Salsa

173
00:13:59,747 --> 00:14:05,130
leva ou 128 ou 256-bit chaves. Eu só vou explicar a versão de 128 bits do Salsa.

174
00:14:05,130 --> 00:14:11,244
Então esta é a semente. E então ele também leva um nonce, tal como antes, que

175
00:14:11,244 --> 00:14:15,425
passa a ser de 64 bits. E então ele vai gerar uma grande saída. Agora, como faz

176
00:14:15,425 --> 00:14:21,060
realmente funciona? Bem, a própria função é definida como se segue. Basicamente, dado

177
00:14:21,060 --> 00:14:26,378
chave eo nonce, ele irá gerar um tempo muito longo, bem, pseudorandom uma longa

178
00:14:26,378 --> 00:14:31,222
sequência, enquanto for necessário. E vai fazê-lo usando essa função que eu vou denotar por

179
00:14:31,222 --> 00:14:35,653
H. Este H função recebe três entradas. Basicamente a chave. Bem, a semente k,

180
00:14:35,653 --> 00:14:40,498
o r nonce, e, em seguida, um contador que incrementa a partir do passo a passo. Assim vai

181
00:14:40,498 --> 00:14:45,263
de zero a um, dois, três, quatro, contanto que inaudível] [ser. Ok? Então, basicamente,

182
00:14:45,263 --> 00:14:49,956
avaliando este H nesta kr, mas usando este contador incrementar, podemos obter uma

183
00:14:49,956 --> 00:14:54,882
seqüência que é tão longo como nós queremos. Então, tudo o que tenho a fazer é descrever como esta função

184
00:14:54,882 --> 00:14:59,460
H funciona. Agora, deixe-me fazer isso aqui para você. O modo como funciona é o seguinte. Bem, nós

185
00:14:59,460 --> 00:15:04,693
começar pela expansão dos estados em algo muito grande que é de 64 bytes

186
00:15:04,693 --> 00:15:10,156
longo, e fazemos isso da seguinte forma. Basicamente, manter uma constante no início, de modo

187
00:15:10,156 --> 00:15:15,552
há tao zero, estes são quatro bytes, é uma de quatro bytes constante, de modo a especificação para

188
00:15:15,552 --> 00:15:20,611
Salsa, basicamente dá-lhe o valor tao zero. Então nós colocamos k em que é

189
00:15:20,611 --> 00:15:25,467
bytes dezesseis. Então nós colocamos uma outra constante. Novamente, isto é quatro bytes. E

190
00:15:25,467 --> 00:15:30,795
como eu disse, a especificação basicamente especifica o que esta constante é fixo. Então nós colocamos

191
00:15:30,795 --> 00:15:37,435
nonce o que é de oito bytes. Então vamos colocar o índice. Este é o zero do contador,

192
00:15:37,435 --> 00:15:43,063
um, dois, três, quatro, que é mais oito bytes. Então nós colocamos uma outra constante

193
00:15:43,063 --> 00:15:49,056
tau dois, que é mais quatro bytes. Então nós colocamos novamente a tecla, este é outro

194
00:15:49,056 --> 00:15:54,714
bytes dezesseis. E então, finalmente, colocar a terceira constante, tau três, que é

195
00:15:54,714 --> 00:15:59,948
mais quatro bytes. Ok então, como eu disse, se você somar estes acima, você vê que você tem 64

196
00:15:59,948 --> 00:16:05,249
bytes. Então, basicamente, nós expandimos a chave eo nonce eo contador em 64

197
00:16:05,249 --> 00:16:10,886
bytes. Basicamente a chave é repetido duas vezes, eu acho. E então o que fazemos é aplicar uma

198
00:16:10,886 --> 00:16:16,321
função, eu vou chamar isso de h pouco funcional. Ok, então nós aplicamos essa função, h pouco.

199
00:16:16,321 --> 00:16:21,659
E esta é uma função que é 12:59 assim que mapeia 64 bytes para 64 bytes. É uma

200
00:16:21,659 --> 00:16:26,005
função completamente invertida, ok? Portanto, esta função é h, o que eu digo, é uma

201
00:16:26,005 --> 00:16:30,260
função invertable. Assim, dada a entrada que você pode obter o resultado e dada a

202
00:16:30,260 --> 00:16:34,906
saída você pode voltar para a entrada. E ele é projetado especificamente por isso é um fácil

203
00:16:34,906 --> 00:16:39,553
de implementar em hardware e b-on um x86, é extremamente fácil de implementar, porque

204
00:16:39,553 --> 00:16:44,199
x86 tem este conjunto de instruções SSE2 que suporta todas as operações que você precisa fazer

205
00:16:44,199 --> 00:16:48,622
para esta função. É muito, muito rápido. Como resultado, salsa tem um fluxo muito rápido

206
00:16:48,622 --> 00:16:52,764
cifra. E então ele faz isso, basicamente, uma e outra vez. Por isso, aplica-se este

207
00:16:52,764 --> 00:16:57,744
função h de novo e fica outros 64 bytes. E assim por diante e assim por diante, basicamente

208
00:16:57,744 --> 00:17:05,318
ele faz isso dez vezes. Ok então a coisa toda aqui, dizer repete dez vezes, de forma

209
00:17:05,318 --> 00:17:17,961
basicamente aplicar h dez vezes. E, em seguida, por si só, isto não é na verdade muito aleatória.

210
00:17:17,961 --> 00:17:22,144
Não vai parecer aleatória, pois como dissemos, H é completamente invertable. Portanto, dado

211
00:17:22,144 --> 00:17:25,521
este resultado final, é muito fácil basta inverter h e depois voltar para o original

212
00:17:25,521 --> 00:17:31,831
insumos e faça o teste que a de entrada tem a estrutura correta. Então você faz mais um

213
00:17:31,831 --> 00:17:36,979
coisa, que é basicamente XOR as entradas e as saídas finais. Na verdade,

214
00:17:36,979 --> 00:17:42,405
pena. Não é um XOR. É realmente uma adição. Então você faz uma palavra além de

215
00:17:42,405 --> 00:17:47,762
palavra. Então, se existem 64 bytes, você faz uma adição palavra por palavra e quatro bytes de cada

216
00:17:47,762 --> 00:17:52,980
tempo e, finalmente, chegar a saída 64-byte, e é isso. Esse é o todo

217
00:17:52,980 --> 00:17:57,175
gerador pseudo-aleatório. Então, isso, isso é toda a função, h pouco. E como eu

218
00:17:57,175 --> 00:18:01,758
explicou, esta construção inteira aqui é a grande função H. E então você avaliar

219
00:18:01,758 --> 00:18:06,009
H grande, incrementando o I contador de zero, um, dois, três em diante. E isso

220
00:18:06,009 --> 00:18:10,408
lhe dará uma seqüência pseudo-aleatório que é o tempo que você precisa que ele seja. E

221
00:18:10,408 --> 00:18:15,325
basicamente, não há ataques signifigant sobre isso. Isto tem a segurança que é

222
00:18:15,325 --> 00:18:20,371
muito perto de duas para o 128. Vamos ver o que isso significa mais precisamente mais tarde.

223
00:18:20,371 --> 00:18:25,417
É uma cifra de fluxo muito rápido, tanto em hardware e em software. E, na medida do

224
00:18:25,417 --> 00:18:30,431
podemos dizer, parece ser imprevisível como necessário para uma cifra de fluxo. Então, eu

225
00:18:30,431 --> 00:18:34,797
deve dizer que o projeto eSTREAM realmente tem cinco cifras de fluxo como

226
00:18:34,797 --> 00:18:39,395
presente. Eu só escolhi Salsa porque eu acho que é o mais elegante. Mas posso dar-lhe

227
00:18:39,395 --> 00:18:44,053
alguns números desempenho aqui. Assim você pode ver, estes são os números de desempenho em um

228
00:18:44,053 --> 00:18:48,768
gigahertz 2.2, você sabe, tipo de máquina x86. E você pode ver que na verdade é o RC4

229
00:18:48,768 --> 00:18:53,017
mais lento. Porque, essencialmente, bem, realmente não tirar proveito da

230
00:18:53,017 --> 00:18:57,475
hardware. Ele só faz operações de byte. E por isso há uma grande quantidade de ciclos de desperdício que

231
00:18:57,475 --> 00:19:01,182
não estão sendo utilizados. Mas os candidatos E-Stream, tanto Salsa e outros

232
00:19:01,182 --> 00:19:05,202
candidato chamado Sosemanuk. Devo dizer que estes são finalistas eSTREAM. Estes são

233
00:19:05,202 --> 00:19:09,588
realmente fluxo cifras que são aprovados pelo projeto eSTREAM. Você pode ver que

234
00:19:09,588 --> 00:19:13,712
de terem atingido uma taxa significativa. Esta é a 643 megabytes por segundo nesta

235
00:19:13,712 --> 00:19:18,150
arquitetura, mais do que suficiente para um filme e estas são realmente muito impressionante

236
00:19:18,150 --> 00:19:22,432
taxas. E agora que você já viu exemplos de duas cifras de fluxo antigos que não devem ser

237
00:19:22,432 --> 00:19:26,661
utilizado, incluindo ataques a essas cifras de fluxo. Você viu o que as cifras de fluxo modernos

238
00:19:26,661 --> 00:19:30,480
parecido com este nonce. E você vê os números de desempenho para estes

239
00:19:30,480 --> 00:19:34,546
fluxo cifras modernas por isso, se acontecer de você precisar de uma cifra de fluxo, você poderia usar um dos

240
00:19:34,546 --> 00:19:37,991
os finalistas eSTREAM. Em particular, você poderia usar algo como Salsa.