WEBVTT 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. 00:00:04.010 --> 00:00:07.072 Voy a empezar con dos ejemplos antiguos, supongo 00:00:07.072 --> 00:00:11.017 que no son usados en nuevos sistemas. Pero si embargo, todavia son 00:00:11.017 --> 00:00:14.164 ampliamente usados, y solo quiero mencionar los nombres de modo que se familiarice con 00:00:14.164 --> 00:00:19.087 estos conceptos. La primera secuencia de cifrado de la quiero hablar es llamado RC4, diseñado 00:00:19.087 --> 00:00:23.429 en 1987. Solo quiero dar una breve descripcion de el, y entonces 00:00:23.429 --> 00:00:27.818 hablaremos acerca de algunas debilidades de RC4 y dejarlo en eso. RC4 toma una 00:00:27.818 --> 00:00:32.702 semilla de tamaño variable, aquí yo sólo puso como ejemplo donde tomaría 128 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. 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 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 00:00:46.382 --> 00:00:51.197 Esta expansión, básicamente ejecuta un bucle muy simple, donde cada iteración del 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 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, 00:01:00.653 --> 00:01:05.205 bastante popular. Se utiliza en el protocolo HTTPS comúnmente realmente. 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 00:01:11.888 --> 00:01:15.686 discutido en el último segmento, pero por supuesto en WEP, se utiliza incorrectamente y 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, 00:01:18.861 --> 00:01:23.886 se han encontrado algunas deficiencias en RC4, y como resultado, se recomienda que nuevos proyectos 00:01:23.886 --> 00:01:28.793 en realidad no utilizar RC4 pero prefiere usar un generador pseudoaleatorio más moderno como veremos 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. 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 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 00:01:44.630 --> 00:01:49.780 completamente al azar, la probabilidad de que el segundo byte pasa a ser igual a cero 00:01:49.780 --> 00:01:54.744 exactamente uno sería más de 256. Hay 256 bytes posibles, la probabilidad de que 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 00:01:59.646 --> 00:02:04.486 realmente dos sobre 256, lo que significa que si usas la salida RC4 para cifrar una 00:02:04.486 --> 00:02:09.574 mensaje el segundo byte es probable que no sean encriptados. En otras palabras le 00:02:09.574 --> 00:02:14.575 ser XOR-ed con cero con dos veces la probabilidad de que se supone que. 00:02:14.575 --> 00:02:19.436 Dos sobre 256, en lugar de uno sobre 256. Y por cierto debo decir que hay 00:02:19.436 --> 00:02:22.849 nada especial en el segundo byte. Resulta que la primera y los terceros bytes 00:02:22.849 --> 00:02:27.818 también están sesgadas. Y de hecho se ahora recomienda si vas a usar RC4, 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 00:02:32.800 --> 00:02:37.246 empezar a utilizar la salida del generador a partir de byte 257. La primera pareja 00:02:37.246 --> 00:02:41.241 de bytes resultados ser sesgada, así que usted sólo ignorarlos. El segundo ataque 00:02:41.241 --> 00:02:48.482 se descubrió que de hecho si observas una muy larga salida de RC4 resulta 00:02:48.482 --> 00:02:53.863 que es más probable conseguir la secuencia 00. En otras palabras, eres más 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 00:02:58.970 --> 00:03:03.948 fue completamente al azar la probabilidad de ver cero, cero sería exactamente 1/256 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 00:03:08.556 --> 00:03:13.718 resulta de este sesgo comienza realmente después de varios gigabytes de datos son producidos por 00:03:13.718 --> 00:03:18.634 RC4. Pero sin embargo, esto es algo que puede utilizarse para predecir el generador 00:03:18.634 --> 00:03:23.120 y definitivamente puede utilizarse para distinguir la salida del generador 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 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 00:03:32.414 --> 00:03:36.313 ataques de clave relacionada que se utilizaron para atacar WEP, que básicamente dicen 00:03:36.313 --> 00:03:41.078 Si uno usa las claves que están estrechamente relacionadas entre sí es posible 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 00:03:45.732 --> 00:03:50.217 resultado, se recomienda que nuevos sistemas realmente no utilizan RC4 y en su lugar utilizan un 00:03:50.217 --> 00:03:54.421 moderno generador pseudoaleatorio. Vale, la segunda es el ejemplo que quiero darle un 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 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 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, 00:04:07.933 --> 00:04:12.523 muy fácilmente podemos romperlo y quiero mostrarle cómo el algoritmo de ataque 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 00:04:16.894 --> 00:04:21.435 hecho, hay muchos sistemas que hay que utilizar básicamente este ataque para descifrar 00:04:21.435 --> 00:04:25.749 DVDs cifrados. Así que la CSS stream cipher es basado en algo que el hardware 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 00:04:30.291 --> 00:04:34.491 ser fácil de implementar en hardware y se basa en un mecanismo llamado lineal 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 00:04:38.749 --> 00:04:43.801 consiste en células donde cada celda contiene un bit. A continuación, básicamente 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 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 00:04:54.134 --> 00:04:59.053 cada ciclo de reloj, el cambio de registrar cambios hacia la izquierda. Cae el último bit 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 00:05:04.345 --> 00:05:08.703 Este es un mecanismo muy simple de implementar y en hardware tiene muy pocos 00:05:08.703 --> 00:05:13.622 transistores. Sólo el cambio justo, cae el bit último y el primer bit sólo 00:05:13.622 --> 00:05:18.541 se convierte en el XOR de los bits anteriores. Por eso la semilla para este LFSR 00:05:18.541 --> 00:05:23.460 Básicamente, es el estado inicial de la LFSR. 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 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 00:05:33.362 --> 00:05:38.060 en segundo lugar. Cifrado GSM, estos son algoritmos llamados A51 y A52. Y 00:05:38.060 --> 00:05:43.456 utiliza tres LFSR Bluetooth cifrado es un algoritmo llamado, cero E. Estos son todos los 00:05:43.456 --> 00:05:48.534 cifrados en flujo, y que utiliza cuatro LFSR. resulta que todos estos son mal roto, 00:05:48.534 --> 00:05:53.245 y realmente, realmente no debe confiar para cifrar el tráfico, pero son todos 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 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 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, 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 00:06:11.073 --> 00:06:15.587 razón tuvieron que limitarse a sólo 40 bits es que fue cifrado de DVD 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 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 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 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, 00:06:35.398 --> 00:06:40.806 el registro contiene 17 bits. Y el otro es un LFSR 25 bits, 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 00:06:46.647 --> 00:06:51.870 es como sigue. Así que la clave para el cifrado, básicamente se ve como sigue. 00:06:51.870 --> 00:06:57.669 Comienzas con un uno, y se concatenar para los dos primeros bytes de 00:06:57.669 --> 00:07:02.947 la clave. Y es el estado inicial de la LFSR. 00:07:02.947 --> 00:07:08.256 Y luego la segunda LFSR básicamente es intitialized la misma manera. 00:07:08.256 --> 00:07:14.012 Uno concatenados los tres últimos bytes de la clave. Y esa es la 00:07:14.012 --> 00:07:19.889 cargado en el estado inicial de la LFSR. Puede ver que los dos primeros bytes son 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 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 00:07:31.217 --> 00:07:36.881 la clave. Entonces que estos LFSR es básicamente durará ocho ciclos, por lo que generan 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 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 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 00:07:54.325 --> 00:07:59.723 bloque anterior. Pero eso no es tan importante. Eso es un detalle que no es así 00:07:59.723 --> 00:08:04.761 pertinentes. OK, así que cada bloque, notará que estamos haciendo suma módulo 256 y 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 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. 00:08:15.147 --> 00:08:20.411 Vale, y entonces este byte es entonces por supuesto utilizado, XOR-ed con la adecuada 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 00:08:25.167 --> 00:08:29.986 cifrado, tarda muy poco hardware a implementar. Se ejecutará rápido, incluso muy 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 00:08:35.830 --> 00:08:41.222 en tiempo aproximadamente dos a los diecisiete años. Ahora Permítanme mostrarles cómo. 00:08:41.222 --> 00:08:45.734 Así que supongamos que interceptar las películas, así que aquí tenemos un 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 00:08:50.647 --> 00:08:55.279 no tienes idea lo que está dentro de aquí. Sin embargo, resulta sólo porque 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 00:08:59.970 --> 00:09:04.250 texto plano, digamos tal vez esto es veinte bytes. Ahora bien, sabemos que si usted 00:09:04.250 --> 00:09:08.589 XOR estas dos cosas juntas, en otras palabras, que hacer el XOR aquí, 00:09:08.589 --> 00:09:13.523 lo que usted obtendrá es el segmento inicial de la PRG. Así, obtendrá el 00:09:13.523 --> 00:09:18.472 primeros veinte bytes de la salida de CSS, la salida de este PRG. Bueno, ahora 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 00:09:23.986 --> 00:09:31.405 hacemos lo siguiente. Tratamos todos los dos a los diecisiete valores posibles de la primera 00:09:31.405 --> 00:09:37.088 LFSR. ¿Vale? Dos a los diecisiete valores posibles. Para cada valor, para 00:09:37.088 --> 00:09:42.622 cada de estos dos, a los diecisiete valores iniciales de la LFSR, vamos a ejecutar la 00:09:42.622 --> 00:09:47.953 LFSR para veinte bytes, ¿vale? Por eso te generar 20 bytes de salidas de este 00:09:47.953 --> 00:09:53.284 primera LFSR, asumiendo — para cada uno de los dos a las diecisiete configuraciones posibles. 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 00:09:58.615 --> 00:10:03.814 puede tomar esta salida que tenemos. Y Réstelo de las mordeduras de veinte que nosotros 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 00:10:08.928 --> 00:10:14.042 LFSR es correcta, lo que lleguemos es la primera salida de veinte bytes de la 00:10:14.042 --> 00:10:19.222 segunda LFSR. ¿Verdad? Debido a es, por definición, lo que la salida de la CSS 00:10:19.222 --> 00:10:24.501 es el sistema. Ahora, resulta que mirando una secuencia de 20 bytes, es muy fácil 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 00:10:29.763 --> 00:10:33.561 no, entonces sabemos que nuestra estimación de la LFSR de 17 bits 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 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 00:10:41.904 --> 00:10:46.937 Estado para el LFSR de 17 bits y luego nos pondremos realmente, veremos que 00:10:46.937 --> 00:10:51.969 los 20 bytes que obtenemos como candidato es de salida para el LFSR 25 bits 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 00:10:56.936 --> 00:11:02.164 aprendió el correcto estado inicial para el LFSR de 17 bits, tendremos también 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 00:11:07.523 --> 00:11:12.796 restantes salidas de CSS y por supuesto, con que nos podemos descifrar el resto de 00:11:12.796 --> 00:11:17.565 la película. Realmente podemos recuperar el texto restante. Esta bien. Esto es 00:11:17.565 --> 00:11:22.335 cosas que hemos hablado antes. Por lo tanto, lo dicho un poco rápido, pero ojalá, 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 00:11:27.331 --> 00:11:31.444 tipo de cifrados y usted obtendrá el punto de cómo estos algoritmos de ataque 00:11:31.444 --> 00:11:36.018 trabajo. Y debo mencionar que existen muchos sistemas de código abierto ahora que realmente 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 00:11:41.453 --> 00:11:45.888 ejemplos débiles, pasemos a ejemplos mejores y en particular el mejor 00:11:45.888 --> 00:11:49.370 generadores pseudoaleatorios provienen de lo que ha llamado el eStream proyecto. Este es un 00:11:49.370 --> 00:11:55.556 proyecto que concluyó en 2008, y califican básicamente cinco diferentes stream 00:11:55.556 --> 00:12:00.207 cifrados, pero aquí quiero presentar sólo uno. Lo primero de todos los parámetros para 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 00:12:04.029 --> 00:12:08.340 secuencia de cifra normalmente tienen una semilla. Pero además también tienen, lo que de 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 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 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í 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 00:12:26.603 --> 00:12:31.218 Nunca se va a repetir como la clave es fijo. Y explicaré en más 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 00:12:35.400 --> 00:12:40.527 repite como la clave es la misma. Y tan naturalmente una vez que tenga este PRG, 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 00:12:45.357 --> 00:12:49.955 PRG toma como entrada el clave y el nonce. Y la propiedad de la nonce 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 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 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 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 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 00:13:21.541 --> 00:13:26.000 ejemplo de la eStream que quiero mostrarle se llama Salsa veinte. Es un 00:13:26.000 --> 00:13:30.292 cifrado de flujo que está diseñado para implementaciones de software y hardware 00:13:30.292 --> 00:13:33.385 implementaciones. Es interesante. Te das cuenta de que son algunos cifrados en flujo 00:13:33.385 --> 00:13:38.763 diseñada para el software, como RC4. Todo lo que hace está diseñada para hacer 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 00:13:42.689 --> 00:13:48.143 hardware, como CSS, usando un LFSR que ha diseñado especialmente para hardware 00:13:48.143 --> 00:13:50.963 implementaciones muy baratas. Es también, lo bueno de eso es que es 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 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 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. 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 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 00:14:15.425 --> 00:14:21.060 ¿realmente funciona? Así, la propia función se define como sigue. Básicamente, dado 00:14:21.060 --> 00:14:26.378 la clave y el nonce, generará una muy larga, bueno, una larga pseudoaleatorio 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 00:14:31.222 --> 00:14:35.653 H. esta función h toma tres entradas. Básicamente la clave. Bien, la semilla k, 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 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, 00:14:45.263 --> 00:14:49.956 por evaluar este h en esta r k, pero este incremento contador, podemos obtener un 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 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 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 00:15:04.693 --> 00:15:10.156 larga ya haga lo siguiente. Básicamente nos atenemos una constante desde el principio, así que 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 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 00:15:20.611 --> 00:15:25.467 16 bytes. Luego ponemos otra constante. Nuevamente, esto es cuatro bytes. Y 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 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, 00:15:37.435 --> 00:15:43.063 uno, dos, tres, cuatro, que es otro ocho bytes. Luego ponemos otra constante 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 00:15:49.056 --> 00:15:54.714 16 bytes. Y entonces finalmente ponemos el tercer tau constante, tres, que es 00:15:54.714 --> 00:15:59.948 otro cuatro bytes. Está bien tal como dije, si estas resumir, ves que te 64 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 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 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. 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 00:16:21.659 --> 00:16:26.005 ¿función completamente invertible, okay? Para esta función h es, como digo, es un 00:16:26.005 --> 00:16:30.260 función invertable. Así que dada la entrada puede obtener la salida y la 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 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 00:16:39.553 --> 00:16:44.199 x 86 tiene este SSE2 conjunto de instrucciones que soporta todas las operaciones que debe hacer 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 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 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 00:16:57.744 --> 00:17:05.318 hace esto diez veces. Esta bien todo esto aquí, decir repite diez veces, así que 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. 00:17:17.961 --> 00:17:22.144 No va a mirar al azar porque como hemos dicho, H es completamente invertable. Tan dado 00:17:22.144 --> 00:17:25.521 Este resultado final, es muy fácil invertir sólo h y luego volver al original 00:17:25.521 --> 00:17:31.831 entradas y luego prueba que la entrada tiene la estructura correcta. Entonces hacer uno más 00:17:31.831 --> 00:17:36.979 cosa, que es básicamente XOR las entradas y las salidas finales. En realidad, 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 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 00:17:47.762 --> 00:17:52.980 tiempo y finalmente obtener la salida de 64 bytes, y eso es todo. Eso es todo 00:17:52.980 --> 00:17:57.175 generador pseudoaleatorio. Así que, es la función entera, poco h. Y como yo 00:17:57.175 --> 00:18:01.758 explicó, esta construcción es la función de gran H. Y luego evaluar 00:18:01.758 --> 00:18:06.009 Big h incrementando el contador desde cero, uno, dos, tres adelante. Y 00:18:06.009 --> 00:18:10.408 le dará una secuencia pseudoaleatoria, siempre y cuando usted lo necesita para ser. Y 00:18:10.408 --> 00:18:15.325 Básicamente, no hay ninguna signifigant ataques a este. Esto tiene la seguridad que 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. 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 00:18:25.417 --> 00:18:30.431 podemos decir, que parece ser impredecible como necesaria para un cifrado de flujo. Así que me 00:18:30.431 --> 00:18:34.797 debería decir que el proyecto de eStream realmente tiene cinco cifrados en flujo como 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 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 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 00:18:48.768 --> 00:18:53.017 más lento. Porque básicamente, bien no realmente toma ventaja de la 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 00:18:57.475 --> 00:19:01.182 no están siendo utilizados. Pero los candidatos E-Stream, tanto Salsa y otros 00:19:01.182 --> 00:19:05.202 candidato llamado Sosemanuk. Yo diría que estos son los finalistas eStream. Estos son 00:19:05.202 --> 00:19:09.588 realmente cifrados en flujo que estén aprobados por el proyecto eStream. Se puede ver que 00:19:09.588 --> 00:19:13.712 que han alcanzado una tasa significativa. Se trata de 643 megabytes por segundo en este 00:19:13.712 --> 00:19:18.150 arquitectura, más que suficiente para una película y estas son realmente impresionantes 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 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 00:19:26.661 --> 00:19:30.480 aspecto con este nonce. Y ver los números de rendimiento para estos 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 00:19:34.546 --> 00:19:37.991 los finalistas eStream. En particular, se podría utilizar algo como Salsa.