1
00:00:00,000 --> 00:00:04,010
En este segmento, quiero dar unos cuantos ejemplos de secuencias de cifrado que se utilizan en la practica.

2
00:00:04,010 --> 00:00:07,072
Voy a empezar con dos ejemplos antiguos, supongo

3
00:00:07,072 --> 00:00:11,017
que no son usados en nuevos sistemas. Pero si embargo, todavia son

4
00:00:11,017 --> 00:00:14,164
ampliamente usados, y solo quiero mencionar los nombres de modo que se familiarice con

5
00:00:14,164 --> 00:00:19,087
estos conceptos. La primera secuencia de cifrado de la quiero hablar es llamado RC4, diseñado

6
00:00:19,087 --> 00:00:23,429
en 1987. Solo quiero dar una breve descripcion de el, y entonces

7
00:00:23,429 --> 00:00:27,818
hablaremos acerca de algunas debilidades de RC4 y dejarlo en eso. RC4 toma una

8
00:00:27,818 --> 00:00:32,702
semilla de tamaño variable, aquí yo sólo puso como ejemplo donde tomaría 128

9
00:00:32,702 --> 00:00:36,980
bits como el tamaño de la semilla, que luego se utilizaría como la clave para el cifrado de flujo.

10
00:00:36,980 --> 00:00:41,738
Lo primero hace, es que expande la clave secreta de 128-bit a 2.048 bits, que

11
00:00:41,738 --> 00:00:46,382
se va a utilizar como del estado interno para el generador. Y luego, una vez que se hace

12
00:00:46,382 --> 00:00:51,197
Esta expansión, básicamente ejecuta un bucle muy simple, donde cada iteración del

13
00:00:51,197 --> 00:00:55,898
Este bucle de salidas de un byte de salida. Así que, esencialmente, puede ejecutar el generador para

14
00:00:55,898 --> 00:01:00,653
mientras que desee y genera un byte a la vez. Ahora RC4 es realmente, como he dicho,

15
00:01:00,653 --> 00:01:05,205
bastante popular. Se utiliza en el protocolo HTTPS comúnmente realmente.

16
00:01:05,205 --> 00:01:11,888
Estos días, por ejemplo, Google utiliza RC4 en su HTTPS. También se utiliza en WEP como nosotros

17
00:01:11,888 --> 00:01:15,686
discutido en el último segmento, pero por supuesto en WEP, se utiliza incorrectamente y

18
00:01:15,686 --> 00:01:18,861
es completamente inseguro la forma en que se utiliza dentro de WEP. Lo largo de los años,

19
00:01:18,861 --> 00:01:23,886
se han encontrado algunas deficiencias en RC4, y como resultado, se recomienda que nuevos proyectos

20
00:01:23,886 --> 00:01:28,793
en realidad no utilizar RC4 pero prefiere usar un generador pseudoaleatorio más moderno como veremos

21
00:01:28,793 --> 00:01:34,059
discutir hacia el final del segmento. Así que permítanme mencionar sólo dos de los puntos débiles.

22
00:01:34,059 --> 00:01:39,561
Por lo que es la primera de ellas, es tipo de extraño básicamente, si nos fijamos en el segundo byte

23
00:01:39,561 --> 00:01:44,630
de la salida de RC4. Resulta que el segundo byte está ligeramente sesgada. Si fue de RC4

24
00:01:44,630 --> 00:01:49,780
completamente al azar, la probabilidad de que el segundo byte pasa a ser igual a cero

25
00:01:49,780 --> 00:01:54,744
exactamente uno sería más de 256. Hay 256 bytes posibles, la probabilidad de que

26
00:01:54,744 --> 00:01:59,646
es la cero debería ser uno más de 256. Resulta que para RC4 la probabilidad es

27
00:01:59,646 --> 00:02:04,486
realmente dos sobre 256, lo que significa que si usas la salida RC4 para cifrar una

28
00:02:04,486 --> 00:02:09,574
mensaje el segundo byte es probable que no sean encriptados. En otras palabras le

29
00:02:09,574 --> 00:02:14,575
ser XOR-ed con cero con dos veces la probabilidad de que se supone que.

30
00:02:14,575 --> 00:02:19,436
Dos sobre 256, en lugar de uno sobre 256.
Y por cierto debo decir que hay

31
00:02:19,436 --> 00:02:22,849
nada especial en el segundo byte. Resulta que la primera y los terceros bytes

32
00:02:22,849 --> 00:02:27,818
también están sesgadas. Y de hecho se ahora recomienda si vas a usar RC4,

33
00:02:27,818 --> 00:02:32,800
lo que debe hacer es ignorar básicamente los primeros 256 bytes de la salida y sólo

34
00:02:32,800 --> 00:02:37,246
empezar a utilizar la salida del generador a partir de byte 257. La primera pareja

35
00:02:37,246 --> 00:02:41,241
de bytes resultados ser sesgada, así que usted sólo ignorarlos. El segundo ataque

36
00:02:41,241 --> 00:02:48,482
se descubrió que de hecho si observas una muy larga salida de RC4 resulta

37
00:02:48,482 --> 00:02:53,863
que es más probable conseguir la secuencia 00. En otras palabras, eres más

38
00:02:53,863 --> 00:02:58,970
probabilidades de tener dieciséis bits, dos bytes de cero, cero, lo que debería. Nuevamente, si RC4

39
00:02:58,970 --> 00:03:03,948
fue completamente al azar la probabilidad de ver cero, cero sería exactamente 1/256

40
00:03:03,948 --> 00:03:08,556
cuadrado. Resulta que es un poco tendencioso RC4 y el sesgo en cubos de 1/256. Se

41
00:03:08,556 --> 00:03:13,718
resulta de este sesgo comienza realmente después de varios gigabytes de datos son producidos por

42
00:03:13,718 --> 00:03:18,634
RC4. Pero sin embargo, esto es algo que puede utilizarse para predecir el generador

43
00:03:18,634 --> 00:03:23,120
y definitivamente puede utilizarse para distinguir la salida del generador

44
00:03:23,120 --> 00:03:28,097
desde una secuencia aleatoria. Básicamente el hecho de que cero, cero aparece más a menudo

45
00:03:28,097 --> 00:03:32,414
lo que debería es el distinguisher. Y, a continuación, en el último segmento hablamos sobre

46
00:03:32,414 --> 00:03:36,313
ataques de clave relacionada que se utilizaron para atacar WEP, que básicamente dicen

47
00:03:36,313 --> 00:03:41,078
Si uno usa las claves que están estrechamente relacionadas entre sí es posible

48
00:03:41,078 --> 00:03:45,732
para recuperar la clave raíz. Así que estos son los puntos débiles que se conocen de RC4 y, como un

49
00:03:45,732 --> 00:03:50,217
resultado, se recomienda que nuevos sistemas realmente no utilizan RC4 y en su lugar utilizan un

50
00:03:50,217 --> 00:03:54,421
moderno generador pseudoaleatorio. Vale, la segunda es el ejemplo que quiero darle un

51
00:03:54,421 --> 00:03:59,131
cifrado de flujo mal roto que se utiliza para cifrar las películas en DVD. Cuando compres un DVD

52
00:03:59,131 --> 00:04:03,504
en la tienda, la película real se cifra mediante un cifrado de flujo que se llama el

53
00:04:03,504 --> 00:04:07,933
sistema de codificación, CSS de contenido. CSS resulta para ser un cifrado de flujo mal roto,

54
00:04:07,933 --> 00:04:12,523
muy fácilmente podemos romperlo y quiero mostrarle cómo el algoritmo de ataque

55
00:04:12,523 --> 00:04:16,894
obras. Que estamos haciendo para que pueda ver un ejemplo de un algoritmo de ataque, pero en

56
00:04:16,894 --> 00:04:21,435
hecho, hay muchos sistemas que hay que utilizar básicamente este ataque para descifrar

57
00:04:21,435 --> 00:04:25,749
DVDs cifrados. Así que la CSS stream cipher es basado en algo que el hardware

58
00:04:25,749 --> 00:04:30,291
como diseñadores. Ha diseñado para ser un cifrado de flujo de hardware que se supone que

59
00:04:30,291 --> 00:04:34,491
ser fácil de implementar en hardware y se basa en un mecanismo llamado lineal

60
00:04:34,491 --> 00:04:38,749
Feedback shift register. Por lo tanto un registro de desplazamiento lineal de retroalimentación es básicamente un registro

61
00:04:38,749 --> 00:04:43,801
consiste en células donde cada celda contiene un bit. A continuación, básicamente

62
00:04:43,801 --> 00:04:49,046
lo que pasa es que hay Estos grifos en ciertas células, no todas las células, ciertos

63
00:04:49,046 --> 00:04:54,134
posiciones son llamados grifos. Y luego estos grifos de alimentación en un XOR y, a continuación, en

64
00:04:54,134 --> 00:04:59,053
cada ciclo de reloj, el cambio de registrar cambios hacia la izquierda. Cae el último bit

65
00:04:59,053 --> 00:05:04,345
y entonces el primer bit se convierte en el resultado de este XOR. Por lo que se puede ver que

66
00:05:04,345 --> 00:05:08,703
Este es un mecanismo muy simple de implementar y en hardware tiene muy pocos

67
00:05:08,703 --> 00:05:13,622
transistores. Sólo el cambio justo, cae el bit último y el primer bit sólo

68
00:05:13,622 --> 00:05:18,541
se convierte en el XOR de los bits anteriores. Por eso la semilla para este LFSR

69
00:05:18,541 --> 00:05:23,460
Básicamente, es el estado inicial de la LFSR.

70
00:05:23,650 --> 00:05:28,538
Y es la base de un número de cifrados en flujo. Aquí hay algunos ejemplos. Así, como

71
00:05:28,538 --> 00:05:33,362
Es decir, DVD cifrado utiliza dos LFSR.
Te voy a mostrar cómo funciona sólo un

72
00:05:33,362 --> 00:05:38,060
en segundo lugar. Cifrado GSM, estos son algoritmos llamados A51 y A52. Y

73
00:05:38,060 --> 00:05:43,456
utiliza tres LFSR Bluetooth cifrado es un algoritmo llamado, cero E. Estos son todos los

74
00:05:43,456 --> 00:05:48,534
cifrados en flujo, y que utiliza cuatro LFSR. resulta que todos estos son mal roto,

75
00:05:48,534 --> 00:05:53,245
y realmente, realmente no debe confiar para cifrar el tráfico, pero son todos

76
00:05:53,245 --> 00:05:56,705
implementado en el hardware, por lo que ahora es un poco difícil para cambiar el hardware

77
00:05:56,705 --> 00:06:01,047
hace. Pero el más simple de estos, CSS, realmente tiene un lindo ataque sobre él, así que

78
00:06:01,047 --> 00:06:05,459
me muestran cómo funciona el ataque. Por lo tanto, vamos a describir cómo funciona CSS. Por lo tanto,

79
00:06:05,459 --> 00:06:11,073
la clave para CSS es cinco bytes, es decir, 40 bits, cinco veces ocho es de 40 bits. El

80
00:06:11,073 --> 00:06:15,587
razón tuvieron que limitarse a sólo 40 bits es que fue cifrado de DVD

81
00:06:15,587 --> 00:06:19,941
diseñado en un momento donde sólo permitieron regulaciones de exportación de Estados Unidos para la exportación de

82
00:06:19,941 --> 00:06:25,086
algoritmos de crpyto donde la clave fue sólo de 40 bits. Así fueron los diseñadores de CSS

83
00:06:25,086 --> 00:06:30,206
ya limitado a claves muy, muy cortas.
Sólo las claves de 40 bits. Por lo tanto, su diseño funciona

84
00:06:30,206 --> 00:06:35,398
como sigue. Básicamente, CSS utiliza de dos LFSR. Uno es un LFSR de 17 bits. En otras palabras,

85
00:06:35,398 --> 00:06:40,806
el registro contiene 17 bits. Y el otro es un LFSR 25 bits,

86
00:06:40,806 --> 00:06:46,647
es un poco más, 25 bits LFSR. Y la forma en que se siembran estos LFSR

87
00:06:46,647 --> 00:06:51,870
es como sigue. Así que la clave para el cifrado, básicamente se ve como sigue.

88
00:06:51,870 --> 00:06:57,669
Comienzas con un uno, y se concatenar para los dos primeros bytes de

89
00:06:57,669 --> 00:07:02,947
la clave. Y es el estado inicial de la LFSR.

90
00:07:02,947 --> 00:07:08,256
Y luego la segunda LFSR básicamente es intitialized la misma manera.

91
00:07:08,256 --> 00:07:14,012
Uno concatenados los tres últimos bytes de la clave. Y esa es la

92
00:07:14,012 --> 00:07:19,889
cargado en el estado inicial de la LFSR.
Puede ver que los dos primeros bytes son

93
00:07:19,889 --> 00:07:25,411
dieciséis bits, además de un líder, que diecisiete bits en general, mientras que el segundo

94
00:07:25,411 --> 00:07:31,217
LFSR es 24 bits más uno que es de 25 bits.
Y observa que usamos todos los cinco bits de

95
00:07:31,217 --> 00:07:36,881
la clave. Entonces que estos LFSR es básicamente durará ocho ciclos, por lo que generan

96
00:07:36,881 --> 00:07:42,333
ocho bits de salida. Y luego se van a través de esta víbora que hace básicamente

97
00:07:42,333 --> 00:07:48,197
suma módulo 256. Sí, por lo que se trata de un cuadro de adición, módulo 256. Hay uno más

98
00:07:48,197 --> 00:07:54,325
técnica lo que sucede. De hecho vamos a realmente — también agregó es el acarreo de la

99
00:07:54,325 --> 00:07:59,723
bloque anterior. Pero eso no es tan importante. Eso es un detalle que no es así

100
00:07:59,723 --> 00:08:04,761
pertinentes. OK, así que cada bloque, notará que estamos haciendo suma módulo 256 y

101
00:08:04,761 --> 00:08:09,982
nosotros estamos ignorando el acarreo, pero el transporte básicamente se agrega como un cero o un uno a la

102
00:08:09,982 --> 00:08:15,147
adición del siguiente bloque. ¿Vale? Y, a continuación, básicamente esta salida un byte por ronda.

103
00:08:15,147 --> 00:08:20,411
Vale, y entonces este byte es entonces por supuesto utilizado, XOR-ed con la adecuada

104
00:08:20,411 --> 00:08:25,167
byte de la película que está siendo encriptada.
Bueno, por lo que es una secuencia muy simple

105
00:08:25,167 --> 00:08:29,986
cifrado, tarda muy poco hardware a implementar. Se ejecutará rápido, incluso muy

106
00:08:29,986 --> 00:08:35,830
hardware barato y se cifrará películas.
Por lo que resulta de esto es fácil de romper

107
00:08:35,830 --> 00:08:41,222
en tiempo aproximadamente dos a los diecisiete años. Ahora Permítanme mostrarles cómo.

108
00:08:41,222 --> 00:08:45,734
Así que supongamos que interceptar las películas, así que aquí tenemos un

109
00:08:45,734 --> 00:08:50,647
película cifrado que desea descifrar.
Así que vamos a decir que esto es todo cifrado lo

110
00:08:50,647 --> 00:08:55,279
no tienes idea lo que está dentro de aquí.
Sin embargo, resulta sólo porque

111
00:08:55,279 --> 00:08:59,970
Codificación de DVD está utilizando archivos MPEG, sucede si usted sabe de un prefijo de la

112
00:08:59,970 --> 00:09:04,250
texto plano, digamos tal vez esto es veinte bytes. Ahora bien, sabemos que si usted

113
00:09:04,250 --> 00:09:08,589
XOR estas dos cosas juntas, en otras palabras, que hacer el XOR aquí,

114
00:09:08,589 --> 00:09:13,523
lo que usted obtendrá es el segmento inicial de la PRG. Así, obtendrá el

115
00:09:13,523 --> 00:09:18,472
primeros veinte bytes de la salida de CSS, la salida de este PRG. Bueno, ahora

116
00:09:18,472 --> 00:09:23,986
aquí es lo que vamos a hacer. Así tenemos los veinte primeros bytes de la salida. Ahora

117
00:09:23,986 --> 00:09:31,405
hacemos lo siguiente. Tratamos todos los dos a los diecisiete valores posibles de la primera

118
00:09:31,405 --> 00:09:37,088
LFSR. ¿Vale? Dos a los diecisiete valores posibles. Para cada valor, para

119
00:09:37,088 --> 00:09:42,622
cada de estos dos, a los diecisiete valores iniciales de la LFSR, vamos a ejecutar la

120
00:09:42,622 --> 00:09:47,953
LFSR para veinte bytes, ¿vale? Por eso te generar 20 bytes de salidas de este

121
00:09:47,953 --> 00:09:53,284
primera LFSR, asumiendo — para cada uno de los dos a las diecisiete configuraciones posibles.

122
00:09:53,284 --> 00:09:58,615
Ahora, recuerde que tenemos la salida completa del sistema de la CSS. Así lo que podemos hacer es

123
00:09:58,615 --> 00:10:03,814
puede tomar esta salida que tenemos. Y Réstelo de las mordeduras de veinte que nosotros

124
00:10:03,814 --> 00:10:08,928
obtuvo de la primera LFSR y si de hecho nuestra estimación para el estado inicial de la primera

125
00:10:08,928 --> 00:10:14,042
LFSR es correcta, lo que lleguemos es la primera salida de veinte bytes de la

126
00:10:14,042 --> 00:10:19,222
segunda LFSR. ¿Verdad? Debido a es, por definición, lo que la salida de la CSS

127
00:10:19,222 --> 00:10:24,501
es el sistema. Ahora, resulta que mirando una secuencia de 20 bytes, es muy fácil

128
00:10:24,501 --> 00:10:29,763
para saber si esta secuencia de 20 bytes procede de un LFSR 25 bits o no. Si se

129
00:10:29,763 --> 00:10:33,561
no, entonces sabemos que nuestra estimación de la LFSR de 17 bits

130
00:10:33,561 --> 00:10:37,416
incorrecto y, a continuación, pasamos a la siguiente supongo que para el LFSR de 17 bits y

131
00:10:37,416 --> 00:10:41,904
la próxima adivinar y así sucesivamente y así sucesivamente.
Hasta que finalmente nos alcanzaron el derecho inicial

132
00:10:41,904 --> 00:10:46,937
Estado para el LFSR de 17 bits y luego nos pondremos realmente, veremos que

133
00:10:46,937 --> 00:10:51,969
los 20 bytes que obtenemos como candidato es de salida para el LFSR 25 bits

134
00:10:51,969 --> 00:10:56,936
de hecho de una posible salida para un LFSR 25 bits. Y entonces, no sólo tendremos

135
00:10:56,936 --> 00:11:02,164
aprendió el correcto estado inicial para el LFSR de 17 bits, tendremos también

136
00:11:02,164 --> 00:11:07,523
aprendió el correcto estado inicial de la LFSR 25 bits. Y, a continuación, podemos predecir el

137
00:11:07,523 --> 00:11:12,796
restantes salidas de CSS y por supuesto, con que nos podemos descifrar el resto de

138
00:11:12,796 --> 00:11:17,565
la película. Realmente podemos recuperar el texto restante. Esta bien. Esto es

139
00:11:17,565 --> 00:11:22,335
cosas que hemos hablado antes. Por lo tanto, lo dicho un poco rápido, pero ojalá,

140
00:11:22,335 --> 00:11:27,331
estaba claro. También vamos a estar haciendo un ejercicio de la tarea en este tipo de secuencia

141
00:11:27,331 --> 00:11:31,444
tipo de cifrados y usted obtendrá el punto de cómo estos algoritmos de ataque

142
00:11:31,444 --> 00:11:36,018
trabajo. Y debo mencionar que existen muchos sistemas de código abierto ahora que realmente

143
00:11:36,018 --> 00:11:41,453
Utilice este método para descifrar los datos cifrados de CSS. Vale, ahora que hemos visto dos

144
00:11:41,453 --> 00:11:45,888
ejemplos débiles, pasemos a ejemplos mejores y en particular el mejor

145
00:11:45,888 --> 00:11:49,370
generadores pseudoaleatorios provienen de lo que ha llamado el eStream proyecto. Este es un

146
00:11:49,370 --> 00:11:55,556
proyecto que concluyó en 2008, y califican básicamente cinco diferentes stream

147
00:11:55,556 --> 00:12:00,207
cifrados, pero aquí quiero presentar sólo uno. Lo primero de todos los parámetros para

148
00:12:00,207 --> 00:12:04,029
son un poco diferentes de lo que estamos acostumbrados a estos cifrados en flujo. Por lo que estas

149
00:12:04,029 --> 00:12:08,340
secuencia de cifra normalmente tienen una semilla.
Pero además también tienen, lo que de

150
00:12:08,340 --> 00:12:12,821
llamado un nonce y nos veremos qué se utiliza un nonce en sólo un minuto. Por lo tanto

151
00:12:12,821 --> 00:12:17,487
llevan dos entradas una semilla y un nonce.
Vamos a ver qué se usa el nonce en

152
00:12:17,487 --> 00:12:21,274
sólo un segundo. Y el supuesto producen una salida muy grande, así que n es aquí

153
00:12:21,274 --> 00:12:26,603
mucho, mucho, mucho mayor que s. Ahora, cuando digo nonce, lo que quiero decir es un valor que

154
00:12:26,603 --> 00:12:31,218
Nunca se va a repetir como la clave es fijo. Y explicaré en más

155
00:12:31,218 --> 00:12:35,400
detalle en sólo un segundo. Pero por ahora, sólo piense en ello como un único no valor que nunca

156
00:12:35,400 --> 00:12:40,527
repite como la clave es la misma.
Y tan naturalmente una vez que tenga este PRG,

157
00:12:40,527 --> 00:12:45,357
se podría cifrar, usted obtiene un cifrado de flujo igual que antes, excepto ahora como ves, la

158
00:12:45,357 --> 00:12:49,955
PRG toma como entrada el clave y el nonce. Y la propiedad de la nonce

159
00:12:49,955 --> 00:12:56,350
que el par, k coma r, para que la coma clave la nonce, nunca, nunca se repite. Tiene

160
00:12:56,350 --> 00:13:03,096
Nunca utilizar más de una vez. Así que la línea de fondo es que se puede reutilizar la clave, reutilización

161
00:13:03,096 --> 00:13:09,710
la clave, porque la nonce hace la pareja única, porque el k y r son sólo

162
00:13:09,710 --> 00:13:16,135
usar una vez. Yo diría que son únicos. Bien por lo que es este nonce truco tipo de un lindo

163
00:13:16,135 --> 00:13:21,541
nos ahorra la molestia de mover a una nueva clave cada vez. Está bien, así que el particular

164
00:13:21,541 --> 00:13:26,000
ejemplo de la eStream que quiero mostrarle se llama Salsa veinte. Es un

165
00:13:26,000 --> 00:13:30,292
cifrado de flujo que está diseñado para implementaciones de software y hardware

166
00:13:30,292 --> 00:13:33,385
implementaciones. Es interesante.
Te das cuenta de que son algunos cifrados en flujo

167
00:13:33,385 --> 00:13:38,763
diseñada para el software, como RC4.
Todo lo que hace está diseñada para hacer

168
00:13:38,763 --> 00:13:42,689
implementación de software correr rápido, mientras que otros cifrados en flujo están diseñados para

169
00:13:42,689 --> 00:13:48,143
hardware, como CSS, usando un LFSR que ha diseñado especialmente para hardware

170
00:13:48,143 --> 00:13:50,963
implementaciones muy baratas. Es también, lo bueno de eso es que es

171
00:13:50,963 --> 00:13:55,008
diseñado de manera que es tanto fácil de implementarlo en el hardware y su software

172
00:13:55,008 --> 00:13:59,747
aplicación también es muy rápido. Así que permítanme explicar cómo funciona la Salsa. Bueno, Salsa

173
00:13:59,747 --> 00:14:05,130
toma las llaves de 128 ó 256 bits. Sólo voy a explicar la versión de 128 bits de la Salsa.

174
00:14:05,130 --> 00:14:11,244
Esto es la semilla. Y, a continuación, también tiene un nonce, justo como antes, que

175
00:14:11,244 --> 00:14:15,425
pasa a ser de 64 bits. Y luego te genera una gran salida. Ahora, cómo se

176
00:14:15,425 --> 00:14:21,060
¿realmente funciona? Así, la propia función se define como sigue. Básicamente, dado

177
00:14:21,060 --> 00:14:26,378
la clave y el nonce, generará una muy larga, bueno, una larga pseudoaleatorio

178
00:14:26,378 --> 00:14:31,222
secuencia, tanto tiempo como sea necesario. Y lo haremos utilizando esta función que voy denotar por

179
00:14:31,222 --> 00:14:35,653
H. esta función h toma tres entradas.
Básicamente la clave. Bien, la semilla k,

180
00:14:35,653 --> 00:14:40,498
la Nuna r y luego un contador que aumenta desde el paso a paso. So it goes

181
00:14:40,498 --> 00:14:45,263
de cero a uno, dos, tres, cuatro como mucho como nosotros [inaudible] ser. ¿Vale? Así que, básicamente,

182
00:14:45,263 --> 00:14:49,956
por evaluar este h en esta r k, pero este incremento contador, podemos obtener un

183
00:14:49,956 --> 00:14:54,882
secuencia que es tan larga como queramos. Así lo único que tengo que hacer es describir cómo esta función

184
00:14:54,882 --> 00:14:59,460
H obras. Ahora, permítanme hacer eso aquí para usted.
El funcionamiento es como sigue. Bueno, nos

185
00:14:59,460 --> 00:15:04,693
empezar por la expansión de los Estados en algo bastante grande que es de 64 bytes

186
00:15:04,693 --> 00:15:10,156
larga ya haga lo siguiente. Básicamente nos atenemos una constante desde el principio, así que

187
00:15:10,156 --> 00:15:15,552
Hay tao cero, estas son cuatro bytes, es una constante de cuatro bytes, por lo tanto las especificaciones para

188
00:15:15,552 --> 00:15:20,611
Salsa básicamente le da el valor para tao cero. Luego ponemos k en la que es

189
00:15:20,611 --> 00:15:25,467
16 bytes. Luego ponemos otra constante. Nuevamente, esto es cuatro bytes. Y

190
00:15:25,467 --> 00:15:30,795
como dije, la especificación especifica básicamente lo que es esta constante fija. A continuación, ponemos

191
00:15:30,795 --> 00:15:37,435
el nonce, que es ocho bytes. A continuación ponemos el índice. Este es el contador a cero,

192
00:15:37,435 --> 00:15:43,063
uno, dos, tres, cuatro, que es otro ocho bytes. Luego ponemos otra constante

193
00:15:43,063 --> 00:15:49,056
Tau dos, que es otro cuatro bytes.
A continuación, ponemos la clave de nuevo, este es otro

194
00:15:49,056 --> 00:15:54,714
16 bytes. Y entonces finalmente ponemos el tercer tau constante, tres, que es

195
00:15:54,714 --> 00:15:59,948
otro cuatro bytes. Está bien tal como dije, si estas resumir, ves que te 64

196
00:15:59,948 --> 00:16:05,249
bytes. Así que básicamente hemos ampliado la clave y el nonce y el contador en 64

197
00:16:05,249 --> 00:16:10,886
bytes. Básicamente se repite la tecla dos veces supongo. Y entonces lo que hacemos es aplicar un

198
00:16:10,886 --> 00:16:16,321
función, que llamaré esta h. poco funcional bien, por lo que aplicar esta función, poco h.

199
00:16:16,321 --> 00:16:21,659
Y esta es una función que es uno a uno, por lo que asigna 64 bytes a 64 bytes. Es un

200
00:16:21,659 --> 00:16:26,005
¿función completamente invertible, okay? Para esta función h es, como digo, es un

201
00:16:26,005 --> 00:16:30,260
función invertable. Así que dada la entrada puede obtener la salida y la

202
00:16:30,260 --> 00:16:34,906
Puedes volver a la entrada de la salida. Y está diseñado específicamente para que tiene un - fácil

203
00:16:34,906 --> 00:16:39,553
para implementar en hardware y b-en un x 86, es extremadamente fácil de implementar porque

204
00:16:39,553 --> 00:16:44,199
x 86 tiene este SSE2 conjunto de instrucciones que soporta todas las operaciones que debe hacer

205
00:16:44,199 --> 00:16:48,622
para esta función. Es muy, muy rápido.
Como resultado, la Salsa tiene un flujo muy rápido

206
00:16:48,622 --> 00:16:52,764
cifrado. Y luego lo hace básicamente una y otra vez. Por lo que se aplica esta

207
00:16:52,764 --> 00:16:57,744
función h nuevamente y se obtiene otro de 64 bytes. Y así sucesivamente y así sucesivamente, básicamente

208
00:16:57,744 --> 00:17:05,318
hace esto diez veces. Esta bien todo esto aquí, decir repite diez veces, así que

209
00:17:05,318 --> 00:17:17,961
básicamente se aplican h diez veces. Y luego por sí mismo, esto es realmente no muy aleatorio.

210
00:17:17,961 --> 00:17:22,144
No va a mirar al azar porque como hemos dicho, H es completamente invertable. Tan dado

211
00:17:22,144 --> 00:17:25,521
Este resultado final, es muy fácil invertir sólo h y luego volver al original

212
00:17:25,521 --> 00:17:31,831
entradas y luego prueba que la entrada tiene la estructura correcta. Entonces hacer uno más

213
00:17:31,831 --> 00:17:36,979
cosa, que es básicamente XOR las entradas y las salidas finales. En realidad,

214
00:17:36,979 --> 00:17:42,405
lo siento. No es un XOR. Es realmente una adición. Entonces hacer una palabra además

215
00:17:42,405 --> 00:17:47,762
palabra. Así que si hay 64 bytes, no una adición de la palabra por palabra cuatro bytes en un

216
00:17:47,762 --> 00:17:52,980
tiempo y finalmente obtener la salida de 64 bytes, y eso es todo. Eso es todo

217
00:17:52,980 --> 00:17:57,175
generador pseudoaleatorio. Así que, es la función entera, poco h. Y como yo

218
00:17:57,175 --> 00:18:01,758
explicó, esta construcción es la función de gran H. Y luego evaluar

219
00:18:01,758 --> 00:18:06,009
Big h incrementando el contador desde cero, uno, dos, tres adelante. Y

220
00:18:06,009 --> 00:18:10,408
le dará una secuencia pseudoaleatoria, siempre y cuando usted lo necesita para ser. Y

221
00:18:10,408 --> 00:18:15,325
Básicamente, no hay ninguna signifigant ataques a este. Esto tiene la seguridad que

222
00:18:15,325 --> 00:18:20,371
muy cerca de dos a los 128. Vamos a ver lo que significa más precisamente más tarde por.

223
00:18:20,371 --> 00:18:25,417
Es un cifrado de flujo muy rápido, tanto en hardware como en software. Y, en cuanto

224
00:18:25,417 --> 00:18:30,431
podemos decir, que parece ser impredecible como necesaria para un cifrado de flujo. Así que me

225
00:18:30,431 --> 00:18:34,797
debería decir que el proyecto de eStream realmente tiene cinco cifrados en flujo como

226
00:18:34,797 --> 00:18:39,395
esto. Elegí sólo Salsa porque creo que es la más elegante. Pero le puedo dar

227
00:18:39,395 --> 00:18:44,053
aquí algunos números de rendimiento. Para que puedas ver, estos son números de rendimiento en un

228
00:18:44,053 --> 00:18:48,768
2.2 gigahercios, sabes, tipo máquina x 86.
Y se puede ver que en realidad es RC4 el

229
00:18:48,768 --> 00:18:53,017
más lento. Porque básicamente, bien no realmente toma ventaja de la

230
00:18:53,017 --> 00:18:57,475
hardware. No sólo las operaciones de byte.
Así que hay un montón de desperdiciadas ciclos que

231
00:18:57,475 --> 00:19:01,182
no están siendo utilizados. Pero los candidatos E-Stream, tanto Salsa y otros

232
00:19:01,182 --> 00:19:05,202
candidato llamado Sosemanuk. Yo diría que estos son los finalistas eStream. Estos son

233
00:19:05,202 --> 00:19:09,588
realmente cifrados en flujo que estén aprobados por el proyecto eStream. Se puede ver que

234
00:19:09,588 --> 00:19:13,712
que han alcanzado una tasa significativa.
Se trata de 643 megabytes por segundo en este

235
00:19:13,712 --> 00:19:18,150
arquitectura, más que suficiente para una película y estas son realmente impresionantes

236
00:19:18,150 --> 00:19:22,432
tasas. Y ahora que has visto ejemplos de dos viejos cifrados en flujo no deberían ser

237
00:19:22,432 --> 00:19:26,661
usa, incluidos ataques contra los cifrados en flujo.
Has visto lo que la corriente moderna de cifra

238
00:19:26,661 --> 00:19:30,480
aspecto con este nonce. Y ver los números de rendimiento para estos

239
00:19:30,480 --> 00:19:34,546
stream moderno de cifra por lo que si usted necesita un cifrado de flujo puede utilizar uno de

240
00:19:34,546 --> 00:19:37,991
los finalistas eStream. En particular, se podría utilizar algo como Salsa.