0:00:00.000,0:00:04.010
En este segmento, quiero dar unos cuantos ejemplos de secuencias de cifrado que se utilizan en la practica.

0:00:04.010,0:00:07.072
Voy a empezar con dos ejemplos antiguos, supongo

0:00:07.072,0:00:11.017
que no son usados en nuevos sistemas. Pero si embargo, todavia son

0:00:11.017,0:00:14.164
ampliamente usados, y solo quiero mencionar los nombres de modo que se familiarice con

0:00:14.164,0:00:19.087
estos conceptos. La primera secuencia de cifrado de la quiero hablar es llamado RC4, diseñado

0:00:19.087,0:00:23.429
en 1987. Solo quiero dar una breve descripcion de el, y entonces

0:00:23.429,0:00:27.818
hablaremos acerca de algunas debilidades de RC4 y dejarlo en eso. RC4 toma una

0:00:27.818,0:00:32.702
semilla de tamaño variable, aquí yo sólo puso como ejemplo donde tomaría 128

0:00:32.702,0:00:36.980
bits como el tamaño de la semilla, que luego se utilizaría como la clave para el cifrado de flujo.

0:00:36.980,0:00:41.738
Lo primero hace, es que expande la clave secreta de 128-bit a 2.048 bits, que

0:00:41.738,0:00:46.382
se va a utilizar como del estado interno para el generador. Y luego, una vez que se hace

0:00:46.382,0:00:51.197
Esta expansión, básicamente ejecuta un bucle muy simple, donde cada iteración del

0:00:51.197,0:00:55.898
Este bucle de salidas de un byte de salida. Así que, esencialmente, puede ejecutar el generador para

0:00:55.898,0:01:00.653
mientras que desee y genera un byte a la vez. Ahora RC4 es realmente, como he dicho,

0:01:00.653,0:01:05.205
bastante popular. Se utiliza en el protocolo HTTPS comúnmente realmente.

0:01:05.205,0:01:11.888
Estos días, por ejemplo, Google utiliza RC4 en su HTTPS. También se utiliza en WEP como nosotros

0:01:11.888,0:01:15.686
discutido en el último segmento, pero por supuesto en WEP, se utiliza incorrectamente y

0:01:15.686,0:01:18.861
es completamente inseguro la forma en que se utiliza dentro de WEP. Lo largo de los años,

0:01:18.861,0:01:23.886
se han encontrado algunas deficiencias en RC4, y como resultado, se recomienda que nuevos proyectos

0:01:23.886,0:01:28.793
en realidad no utilizar RC4 pero prefiere usar un generador pseudoaleatorio más moderno como veremos

0:01:28.793,0:01:34.059
discutir hacia el final del segmento. Así que permítanme mencionar sólo dos de los puntos débiles.

0:01:34.059,0: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

0:01:39.561,0:01:44.630
de la salida de RC4. Resulta que el segundo byte está ligeramente sesgada. Si fue de RC4

0:01:44.630,0:01:49.780
completamente al azar, la probabilidad de que el segundo byte pasa a ser igual a cero

0:01:49.780,0:01:54.744
exactamente uno sería más de 256. Hay 256 bytes posibles, la probabilidad de que

0:01:54.744,0:01:59.646
es la cero debería ser uno más de 256. Resulta que para RC4 la probabilidad es

0:01:59.646,0:02:04.486
realmente dos sobre 256, lo que significa que si usas la salida RC4 para cifrar una

0:02:04.486,0:02:09.574
mensaje el segundo byte es probable que no sean encriptados. En otras palabras le

0:02:09.574,0:02:14.575
ser XOR-ed con cero con dos veces la probabilidad de que se supone que.

0:02:14.575,0:02:19.436
Dos sobre 256, en lugar de uno sobre 256.[br]Y por cierto debo decir que hay

0:02:19.436,0:02:22.849
nada especial en el segundo byte. Resulta que la primera y los terceros bytes

0:02:22.849,0:02:27.818
también están sesgadas. Y de hecho se ahora recomienda si vas a usar RC4,

0:02:27.818,0:02:32.800
lo que debe hacer es ignorar básicamente los primeros 256 bytes de la salida y sólo

0:02:32.800,0:02:37.246
empezar a utilizar la salida del generador a partir de byte 257. La primera pareja

0:02:37.246,0:02:41.241
de bytes resultados ser sesgada, así que usted sólo ignorarlos. El segundo ataque

0:02:41.241,0:02:48.482
se descubrió que de hecho si observas una muy larga salida de RC4 resulta

0:02:48.482,0:02:53.863
que es más probable conseguir la secuencia 00. En otras palabras, eres más

0:02:53.863,0:02:58.970
probabilidades de tener dieciséis bits, dos bytes de cero, cero, lo que debería. Nuevamente, si RC4

0:02:58.970,0:03:03.948
fue completamente al azar la probabilidad de ver cero, cero sería exactamente 1/256

0:03:03.948,0:03:08.556
cuadrado. Resulta que es un poco tendencioso RC4 y el sesgo en cubos de 1/256. Se

0:03:08.556,0:03:13.718
resulta de este sesgo comienza realmente después de varios gigabytes de datos son producidos por

0:03:13.718,0:03:18.634
RC4. Pero sin embargo, esto es algo que puede utilizarse para predecir el generador

0:03:18.634,0:03:23.120
y definitivamente puede utilizarse para distinguir la salida del generador

0:03:23.120,0:03:28.097
desde una secuencia aleatoria. Básicamente el hecho de que cero, cero aparece más a menudo

0:03:28.097,0:03:32.414
lo que debería es el distinguisher. Y, a continuación, en el último segmento hablamos sobre

0:03:32.414,0:03:36.313
ataques de clave relacionada que se utilizaron para atacar WEP, que básicamente dicen

0:03:36.313,0:03:41.078
Si uno usa las claves que están estrechamente relacionadas entre sí es posible

0:03:41.078,0: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

0:03:45.732,0:03:50.217
resultado, se recomienda que nuevos sistemas realmente no utilizan RC4 y en su lugar utilizan un

0:03:50.217,0:03:54.421
moderno generador pseudoaleatorio. Vale, la segunda es el ejemplo que quiero darle un

0:03:54.421,0:03:59.131
cifrado de flujo mal roto que se utiliza para cifrar las películas en DVD. Cuando compres un DVD

0:03:59.131,0:04:03.504
en la tienda, la película real se cifra mediante un cifrado de flujo que se llama el

0:04:03.504,0:04:07.933
sistema de codificación, CSS de contenido. CSS resulta para ser un cifrado de flujo mal roto,

0:04:07.933,0:04:12.523
muy fácilmente podemos romperlo y quiero mostrarle cómo el algoritmo de ataque

0:04:12.523,0:04:16.894
obras. Que estamos haciendo para que pueda ver un ejemplo de un algoritmo de ataque, pero en

0:04:16.894,0:04:21.435
hecho, hay muchos sistemas que hay que utilizar básicamente este ataque para descifrar

0:04:21.435,0:04:25.749
DVDs cifrados. Así que la CSS stream cipher es basado en algo que el hardware

0:04:25.749,0:04:30.291
como diseñadores. Ha diseñado para ser un cifrado de flujo de hardware que se supone que

0:04:30.291,0:04:34.491
ser fácil de implementar en hardware y se basa en un mecanismo llamado lineal

0:04:34.491,0:04:38.749
Feedback shift register. Por lo tanto un registro de desplazamiento lineal de retroalimentación es básicamente un registro

0:04:38.749,0:04:43.801
consiste en células donde cada celda contiene un bit. A continuación, básicamente

0:04:43.801,0:04:49.046
lo que pasa es que hay Estos grifos en ciertas células, no todas las células, ciertos

0:04:49.046,0:04:54.134
posiciones son llamados grifos. Y luego estos grifos de alimentación en un XOR y, a continuación, en

0:04:54.134,0:04:59.053
cada ciclo de reloj, el cambio de registrar cambios hacia la izquierda. Cae el último bit

0:04:59.053,0:05:04.345
y entonces el primer bit se convierte en el resultado de este XOR. Por lo que se puede ver que

0:05:04.345,0:05:08.703
Este es un mecanismo muy simple de implementar y en hardware tiene muy pocos

0:05:08.703,0:05:13.622
transistores. Sólo el cambio justo, cae el bit último y el primer bit sólo

0:05:13.622,0:05:18.541
se convierte en el XOR de los bits anteriores. Por eso la semilla para este LFSR

0:05:18.541,0:05:23.460
Básicamente, es el estado inicial de la LFSR.

0:05:23.650,0:05:28.538
Y es la base de un número de cifrados en flujo. Aquí hay algunos ejemplos. Así, como

0:05:28.538,0:05:33.362
Es decir, DVD cifrado utiliza dos LFSR.[br]Te voy a mostrar cómo funciona sólo un

0:05:33.362,0:05:38.060
en segundo lugar. Cifrado GSM, estos son algoritmos llamados A51 y A52. Y

0:05:38.060,0:05:43.456
utiliza tres LFSR Bluetooth cifrado es un algoritmo llamado, cero E. Estos son todos los

0:05:43.456,0:05:48.534
cifrados en flujo, y que utiliza cuatro LFSR. resulta que todos estos son mal roto,

0:05:48.534,0:05:53.245
y realmente, realmente no debe confiar para cifrar el tráfico, pero son todos

0:05:53.245,0:05:56.705
implementado en el hardware, por lo que ahora es un poco difícil para cambiar el hardware

0:05:56.705,0:06:01.047
hace. Pero el más simple de estos, CSS, realmente tiene un lindo ataque sobre él, así que

0:06:01.047,0:06:05.459
me muestran cómo funciona el ataque. Por lo tanto, vamos a describir cómo funciona CSS. Por lo tanto,

0:06:05.459,0:06:11.073
la clave para CSS es cinco bytes, es decir, 40 bits, cinco veces ocho es de 40 bits. El

0:06:11.073,0:06:15.587
razón tuvieron que limitarse a sólo 40 bits es que fue cifrado de DVD

0:06:15.587,0:06:19.941
diseñado en un momento donde sólo permitieron regulaciones de exportación de Estados Unidos para la exportación de

0:06:19.941,0:06:25.086
algoritmos de crpyto donde la clave fue sólo de 40 bits. Así fueron los diseñadores de CSS

0:06:25.086,0:06:30.206
ya limitado a claves muy, muy cortas.[br]Sólo las claves de 40 bits. Por lo tanto, su diseño funciona

0:06:30.206,0:06:35.398
como sigue. Básicamente, CSS utiliza de dos LFSR. Uno es un LFSR de 17 bits. En otras palabras,

0:06:35.398,0:06:40.806
el registro contiene 17 bits. Y el otro es un LFSR 25 bits,

0:06:40.806,0:06:46.647
es un poco más, 25 bits LFSR. Y la forma en que se siembran estos LFSR

0:06:46.647,0:06:51.870
es como sigue. Así que la clave para el cifrado, básicamente se ve como sigue.

0:06:51.870,0:06:57.669
Comienzas con un uno, y se concatenar para los dos primeros bytes de

0:06:57.669,0:07:02.947
la clave. Y es el estado inicial de la LFSR.

0:07:02.947,0:07:08.256
Y luego la segunda LFSR básicamente es intitialized la misma manera.

0:07:08.256,0:07:14.012
Uno concatenados los tres últimos bytes de la clave. Y esa es la

0:07:14.012,0:07:19.889
cargado en el estado inicial de la LFSR.[br]Puede ver que los dos primeros bytes son

0:07:19.889,0:07:25.411
dieciséis bits, además de un líder, que diecisiete bits en general, mientras que el segundo

0:07:25.411,0:07:31.217
LFSR es 24 bits más uno que es de 25 bits.[br]Y observa que usamos todos los cinco bits de

0:07:31.217,0:07:36.881
la clave. Entonces que estos LFSR es básicamente durará ocho ciclos, por lo que generan

0:07:36.881,0:07:42.333
ocho bits de salida. Y luego se van a través de esta víbora que hace básicamente

0:07:42.333,0: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

0:07:48.197,0:07:54.325
técnica lo que sucede. De hecho vamos a realmente — también agregó es el acarreo de la

0:07:54.325,0:07:59.723
bloque anterior. Pero eso no es tan importante. Eso es un detalle que no es así

0:07:59.723,0:08:04.761
pertinentes. OK, así que cada bloque, notará que estamos haciendo suma módulo 256 y

0:08:04.761,0:08:09.982
nosotros estamos ignorando el acarreo, pero el transporte básicamente se agrega como un cero o un uno a la

0:08:09.982,0:08:15.147
adición del siguiente bloque. ¿Vale? Y, a continuación, básicamente esta salida un byte por ronda.

0:08:15.147,0:08:20.411
Vale, y entonces este byte es entonces por supuesto utilizado, XOR-ed con la adecuada

0:08:20.411,0:08:25.167
byte de la película que está siendo encriptada.[br]Bueno, por lo que es una secuencia muy simple

0:08:25.167,0:08:29.986
cifrado, tarda muy poco hardware a implementar. Se ejecutará rápido, incluso muy

0:08:29.986,0:08:35.830
hardware barato y se cifrará películas.[br]Por lo que resulta de esto es fácil de romper

0:08:35.830,0:08:41.222
en tiempo aproximadamente dos a los diecisiete años. Ahora Permítanme mostrarles cómo.

0:08:41.222,0:08:45.734
Así que supongamos que interceptar las películas, así que aquí tenemos un

0:08:45.734,0:08:50.647
película cifrado que desea descifrar.[br]Así que vamos a decir que esto es todo cifrado lo

0:08:50.647,0:08:55.279
no tienes idea lo que está dentro de aquí.[br]Sin embargo, resulta sólo porque

0:08:55.279,0:08:59.970
Codificación de DVD está utilizando archivos MPEG, sucede si usted sabe de un prefijo de la

0:08:59.970,0:09:04.250
texto plano, digamos tal vez esto es veinte bytes. Ahora bien, sabemos que si usted

0:09:04.250,0:09:08.589
XOR estas dos cosas juntas, en otras palabras, que hacer el XOR aquí,

0:09:08.589,0:09:13.523
lo que usted obtendrá es el segmento inicial de la PRG. Así, obtendrá el

0:09:13.523,0:09:18.472
primeros veinte bytes de la salida de CSS, la salida de este PRG. Bueno, ahora

0:09:18.472,0:09:23.986
aquí es lo que vamos a hacer. Así tenemos los veinte primeros bytes de la salida. Ahora

0:09:23.986,0:09:31.405
hacemos lo siguiente. Tratamos todos los dos a los diecisiete valores posibles de la primera

0:09:31.405,0:09:37.088
LFSR. ¿Vale? Dos a los diecisiete valores posibles. Para cada valor, para

0:09:37.088,0:09:42.622
cada de estos dos, a los diecisiete valores iniciales de la LFSR, vamos a ejecutar la

0:09:42.622,0:09:47.953
LFSR para veinte bytes, ¿vale? Por eso te generar 20 bytes de salidas de este

0:09:47.953,0:09:53.284
primera LFSR, asumiendo — para cada uno de los dos a las diecisiete configuraciones posibles.

0:09:53.284,0:09:58.615
Ahora, recuerde que tenemos la salida completa del sistema de la CSS. Así lo que podemos hacer es

0:09:58.615,0:10:03.814
puede tomar esta salida que tenemos. Y Réstelo de las mordeduras de veinte que nosotros

0:10:03.814,0:10:08.928
obtuvo de la primera LFSR y si de hecho nuestra estimación para el estado inicial de la primera

0:10:08.928,0:10:14.042
LFSR es correcta, lo que lleguemos es la primera salida de veinte bytes de la

0:10:14.042,0:10:19.222
segunda LFSR. ¿Verdad? Debido a es, por definición, lo que la salida de la CSS

0:10:19.222,0:10:24.501
es el sistema. Ahora, resulta que mirando una secuencia de 20 bytes, es muy fácil

0:10:24.501,0:10:29.763
para saber si esta secuencia de 20 bytes procede de un LFSR 25 bits o no. Si se

0:10:29.763,0:10:33.561
no, entonces sabemos que nuestra estimación de la LFSR de 17 bits

0:10:33.561,0:10:37.416
incorrecto y, a continuación, pasamos a la siguiente supongo que para el LFSR de 17 bits y

0:10:37.416,0:10:41.904
la próxima adivinar y así sucesivamente y así sucesivamente.[br]Hasta que finalmente nos alcanzaron el derecho inicial

0:10:41.904,0:10:46.937
Estado para el LFSR de 17 bits y luego nos pondremos realmente, veremos que

0:10:46.937,0:10:51.969
los 20 bytes que obtenemos como candidato es de salida para el LFSR 25 bits

0:10:51.969,0:10:56.936
de hecho de una posible salida para un LFSR 25 bits. Y entonces, no sólo tendremos

0:10:56.936,0:11:02.164
aprendió el correcto estado inicial para el LFSR de 17 bits, tendremos también

0:11:02.164,0:11:07.523
aprendió el correcto estado inicial de la LFSR 25 bits. Y, a continuación, podemos predecir el

0:11:07.523,0:11:12.796
restantes salidas de CSS y por supuesto, con que nos podemos descifrar el resto de

0:11:12.796,0:11:17.565
la película. Realmente podemos recuperar el texto restante. Esta bien. Esto es

0:11:17.565,0:11:22.335
cosas que hemos hablado antes. Por lo tanto, lo dicho un poco rápido, pero ojalá,

0:11:22.335,0:11:27.331
estaba claro. También vamos a estar haciendo un ejercicio de la tarea en este tipo de secuencia

0:11:27.331,0:11:31.444
tipo de cifrados y usted obtendrá el punto de cómo estos algoritmos de ataque

0:11:31.444,0:11:36.018
trabajo. Y debo mencionar que existen muchos sistemas de código abierto ahora que realmente

0:11:36.018,0:11:41.453
Utilice este método para descifrar los datos cifrados de CSS. Vale, ahora que hemos visto dos

0:11:41.453,0:11:45.888
ejemplos débiles, pasemos a ejemplos mejores y en particular el mejor

0:11:45.888,0:11:49.370
generadores pseudoaleatorios provienen de lo que ha llamado el eStream proyecto. Este es un

0:11:49.370,0:11:55.556
proyecto que concluyó en 2008, y califican básicamente cinco diferentes stream

0:11:55.556,0:12:00.207
cifrados, pero aquí quiero presentar sólo uno. Lo primero de todos los parámetros para

0:12:00.207,0:12:04.029
son un poco diferentes de lo que estamos acostumbrados a estos cifrados en flujo. Por lo que estas

0:12:04.029,0:12:08.340
secuencia de cifra normalmente tienen una semilla.[br]Pero además también tienen, lo que de

0:12:08.340,0:12:12.821
llamado un nonce y nos veremos qué se utiliza un nonce en sólo un minuto. Por lo tanto

0:12:12.821,0:12:17.487
llevan dos entradas una semilla y un nonce.[br]Vamos a ver qué se usa el nonce en

0:12:17.487,0:12:21.274
sólo un segundo. Y el supuesto producen una salida muy grande, así que n es aquí

0:12:21.274,0:12:26.603
mucho, mucho, mucho mayor que s. Ahora, cuando digo nonce, lo que quiero decir es un valor que

0:12:26.603,0:12:31.218
Nunca se va a repetir como la clave es fijo. Y explicaré en más

0:12:31.218,0:12:35.400
detalle en sólo un segundo. Pero por ahora, sólo piense en ello como un único no valor que nunca

0:12:35.400,0:12:40.527
repite como la clave es la misma.[br]Y tan naturalmente una vez que tenga este PRG,

0:12:40.527,0:12:45.357
se podría cifrar, usted obtiene un cifrado de flujo igual que antes, excepto ahora como ves, la

0:12:45.357,0:12:49.955
PRG toma como entrada el clave y el nonce. Y la propiedad de la nonce

0:12:49.955,0:12:56.350
que el par, k coma r, para que la coma clave la nonce, nunca, nunca se repite. Tiene

0:12:56.350,0: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

0:13:03.096,0:13:09.710
la clave, porque la nonce hace la pareja única, porque el k y r son sólo

0:13:09.710,0:13:16.135
usar una vez. Yo diría que son únicos. Bien por lo que es este nonce truco tipo de un lindo

0:13:16.135,0:13:21.541
nos ahorra la molestia de mover a una nueva clave cada vez. Está bien, así que el particular

0:13:21.541,0:13:26.000
ejemplo de la eStream que quiero mostrarle se llama Salsa veinte. Es un

0:13:26.000,0:13:30.292
cifrado de flujo que está diseñado para implementaciones de software y hardware

0:13:30.292,0:13:33.385
implementaciones. Es interesante.[br]Te das cuenta de que son algunos cifrados en flujo

0:13:33.385,0:13:38.763
diseñada para el software, como RC4.[br]Todo lo que hace está diseñada para hacer

0:13:38.763,0:13:42.689
implementación de software correr rápido, mientras que otros cifrados en flujo están diseñados para

0:13:42.689,0:13:48.143
hardware, como CSS, usando un LFSR que ha diseñado especialmente para hardware

0:13:48.143,0:13:50.963
implementaciones muy baratas. Es también, lo bueno de eso es que es

0:13:50.963,0:13:55.008
diseñado de manera que es tanto fácil de implementarlo en el hardware y su software

0:13:55.008,0:13:59.747
aplicación también es muy rápido. Así que permítanme explicar cómo funciona la Salsa. Bueno, Salsa

0:13:59.747,0:14:05.130
toma las llaves de 128 ó 256 bits. Sólo voy a explicar la versión de 128 bits de la Salsa.

0:14:05.130,0:14:11.244
Esto es la semilla. Y, a continuación, también tiene un nonce, justo como antes, que

0:14:11.244,0:14:15.425
pasa a ser de 64 bits. Y luego te genera una gran salida. Ahora, cómo se

0:14:15.425,0:14:21.060
¿realmente funciona? Así, la propia función se define como sigue. Básicamente, dado

0:14:21.060,0:14:26.378
la clave y el nonce, generará una muy larga, bueno, una larga pseudoaleatorio

0:14:26.378,0:14:31.222
secuencia, tanto tiempo como sea necesario. Y lo haremos utilizando esta función que voy denotar por

0:14:31.222,0:14:35.653
H. esta función h toma tres entradas.[br]Básicamente la clave. Bien, la semilla k,

0:14:35.653,0:14:40.498
la Nuna r y luego un contador que aumenta desde el paso a paso. So it goes

0:14:40.498,0:14:45.263
de cero a uno, dos, tres, cuatro como mucho como nosotros [inaudible] ser. ¿Vale? Así que, básicamente,

0:14:45.263,0:14:49.956
por evaluar este h en esta r k, pero este incremento contador, podemos obtener un

0:14:49.956,0:14:54.882
secuencia que es tan larga como queramos. Así lo único que tengo que hacer es describir cómo esta función

0:14:54.882,0:14:59.460
H obras. Ahora, permítanme hacer eso aquí para usted.[br]El funcionamiento es como sigue. Bueno, nos

0:14:59.460,0:15:04.693
empezar por la expansión de los Estados en algo bastante grande que es de 64 bytes

0:15:04.693,0:15:10.156
larga ya haga lo siguiente. Básicamente nos atenemos una constante desde el principio, así que

0:15:10.156,0:15:15.552
Hay tao cero, estas son cuatro bytes, es una constante de cuatro bytes, por lo tanto las especificaciones para

0:15:15.552,0:15:20.611
Salsa básicamente le da el valor para tao cero. Luego ponemos k en la que es

0:15:20.611,0:15:25.467
16 bytes. Luego ponemos otra constante. Nuevamente, esto es cuatro bytes. Y

0:15:25.467,0:15:30.795
como dije, la especificación especifica básicamente lo que es esta constante fija. A continuación, ponemos

0:15:30.795,0:15:37.435
el nonce, que es ocho bytes. A continuación ponemos el índice. Este es el contador a cero,

0:15:37.435,0:15:43.063
uno, dos, tres, cuatro, que es otro ocho bytes. Luego ponemos otra constante

0:15:43.063,0:15:49.056
Tau dos, que es otro cuatro bytes.[br]A continuación, ponemos la clave de nuevo, este es otro

0:15:49.056,0:15:54.714
16 bytes. Y entonces finalmente ponemos el tercer tau constante, tres, que es

0:15:54.714,0:15:59.948
otro cuatro bytes. Está bien tal como dije, si estas resumir, ves que te 64

0:15:59.948,0:16:05.249
bytes. Así que básicamente hemos ampliado la clave y el nonce y el contador en 64

0:16:05.249,0:16:10.886
bytes. Básicamente se repite la tecla dos veces supongo. Y entonces lo que hacemos es aplicar un

0:16:10.886,0:16:16.321
función, que llamaré esta h. poco funcional bien, por lo que aplicar esta función, poco h.

0:16:16.321,0: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

0:16:21.659,0:16:26.005
¿función completamente invertible, okay? Para esta función h es, como digo, es un

0:16:26.005,0:16:30.260
función invertable. Así que dada la entrada puede obtener la salida y la

0:16:30.260,0:16:34.906
Puedes volver a la entrada de la salida. Y está diseñado específicamente para que tiene un - fácil

0:16:34.906,0:16:39.553
para implementar en hardware y b-en un x 86, es extremadamente fácil de implementar porque

0:16:39.553,0:16:44.199
x 86 tiene este SSE2 conjunto de instrucciones que soporta todas las operaciones que debe hacer

0:16:44.199,0:16:48.622
para esta función. Es muy, muy rápido.[br]Como resultado, la Salsa tiene un flujo muy rápido

0:16:48.622,0:16:52.764
cifrado. Y luego lo hace básicamente una y otra vez. Por lo que se aplica esta

0:16:52.764,0:16:57.744
función h nuevamente y se obtiene otro de 64 bytes. Y así sucesivamente y así sucesivamente, básicamente

0:16:57.744,0:17:05.318
hace esto diez veces. Esta bien todo esto aquí, decir repite diez veces, así que

0:17:05.318,0:17:17.961
básicamente se aplican h diez veces. Y luego por sí mismo, esto es realmente no muy aleatorio.

0:17:17.961,0:17:22.144
No va a mirar al azar porque como hemos dicho, H es completamente invertable. Tan dado

0:17:22.144,0:17:25.521
Este resultado final, es muy fácil invertir sólo h y luego volver al original

0:17:25.521,0:17:31.831
entradas y luego prueba que la entrada tiene la estructura correcta. Entonces hacer uno más

0:17:31.831,0:17:36.979
cosa, que es básicamente XOR las entradas y las salidas finales. En realidad,

0:17:36.979,0:17:42.405
lo siento. No es un XOR. Es realmente una adición. Entonces hacer una palabra además

0:17:42.405,0:17:47.762
palabra. Así que si hay 64 bytes, no una adición de la palabra por palabra cuatro bytes en un

0:17:47.762,0:17:52.980
tiempo y finalmente obtener la salida de 64 bytes, y eso es todo. Eso es todo

0:17:52.980,0:17:57.175
generador pseudoaleatorio. Así que, es la función entera, poco h. Y como yo

0:17:57.175,0:18:01.758
explicó, esta construcción es la función de gran H. Y luego evaluar

0:18:01.758,0:18:06.009
Big h incrementando el contador desde cero, uno, dos, tres adelante. Y

0:18:06.009,0:18:10.408
le dará una secuencia pseudoaleatoria, siempre y cuando usted lo necesita para ser. Y

0:18:10.408,0:18:15.325
Básicamente, no hay ninguna signifigant ataques a este. Esto tiene la seguridad que

0:18:15.325,0:18:20.371
muy cerca de dos a los 128. Vamos a ver lo que significa más precisamente más tarde por.

0:18:20.371,0:18:25.417
Es un cifrado de flujo muy rápido, tanto en hardware como en software. Y, en cuanto

0:18:25.417,0:18:30.431
podemos decir, que parece ser impredecible como necesaria para un cifrado de flujo. Así que me

0:18:30.431,0:18:34.797
debería decir que el proyecto de eStream realmente tiene cinco cifrados en flujo como

0:18:34.797,0:18:39.395
esto. Elegí sólo Salsa porque creo que es la más elegante. Pero le puedo dar

0:18:39.395,0:18:44.053
aquí algunos números de rendimiento. Para que puedas ver, estos son números de rendimiento en un

0:18:44.053,0:18:48.768
2.2 gigahercios, sabes, tipo máquina x 86.[br]Y se puede ver que en realidad es RC4 el

0:18:48.768,0:18:53.017
más lento. Porque básicamente, bien no realmente toma ventaja de la

0:18:53.017,0:18:57.475
hardware. No sólo las operaciones de byte.[br]Así que hay un montón de desperdiciadas ciclos que

0:18:57.475,0:19:01.182
no están siendo utilizados. Pero los candidatos E-Stream, tanto Salsa y otros

0:19:01.182,0:19:05.202
candidato llamado Sosemanuk. Yo diría que estos son los finalistas eStream. Estos son

0:19:05.202,0:19:09.588
realmente cifrados en flujo que estén aprobados por el proyecto eStream. Se puede ver que

0:19:09.588,0:19:13.712
que han alcanzado una tasa significativa.[br]Se trata de 643 megabytes por segundo en este

0:19:13.712,0:19:18.150
arquitectura, más que suficiente para una película y estas son realmente impresionantes

0:19:18.150,0:19:22.432
tasas. Y ahora que has visto ejemplos de dos viejos cifrados en flujo no deberían ser

0:19:22.432,0:19:26.661
usa, incluidos ataques contra los cifrados en flujo.[br]Has visto lo que la corriente moderna de cifra

0:19:26.661,0:19:30.480
aspecto con este nonce. Y ver los números de rendimiento para estos

0:19:30.480,0:19:34.546
stream moderno de cifra por lo que si usted necesita un cifrado de flujo puede utilizar uno de

0:19:34.546,0:19:37.991
los finalistas eStream. En particular, se podría utilizar algo como Salsa.