< Return to Video

Real-world stream ciphers (20 min)

  • 0:00 - 0:04
    En este segmento, quiero dar unos cuantos ejemplos de secuencias de cifrado que se utilizan en la practica.
  • 0:04 - 0:07
    Voy a empezar con dos ejemplos antiguos, supongo
  • 0:07 - 0:11
    que no son usados en nuevos sistemas. Pero si embargo, todavia son
  • 0:11 - 0:14
    ampliamente usados, y solo quiero mencionar los nombres de modo que se familiarice con
  • 0:14 - 0:19
    estos conceptos. La primera secuencia de cifrado de la quiero hablar es llamado RC4, diseñado
  • 0:19 - 0:23
    en 1987. Solo quiero dar una breve descripcion de el, y entonces
  • 0:23 - 0:28
    hablaremos acerca de algunas debilidades de RC4 y dejarlo en eso. RC4 toma una
  • 0:28 - 0:33
    semilla de tamaño variable, aquí yo sólo puso como ejemplo donde tomaría 128
  • 0:33 - 0:37
    bits como el tamaño de la semilla, que luego se utilizaría como la clave para el cifrado de flujo.
  • 0:37 - 0:42
    Lo primero hace, es que expande la clave secreta de 128-bit a 2.048 bits, que
  • 0:42 - 0:46
    se va a utilizar como del estado interno para el generador. Y luego, una vez que se hace
  • 0:46 - 0:51
    Esta expansión, básicamente ejecuta un bucle muy simple, donde cada iteración del
  • 0:51 - 0:56
    Este bucle de salidas de un byte de salida. Así que, esencialmente, puede ejecutar el generador para
  • 0:56 - 1:01
    mientras que desee y genera un byte a la vez. Ahora RC4 es realmente, como he dicho,
  • 1:01 - 1:05
    bastante popular. Se utiliza en el protocolo HTTPS comúnmente realmente.
  • 1:05 - 1:12
    Estos días, por ejemplo, Google utiliza RC4 en su HTTPS. También se utiliza en WEP como nosotros
  • 1:12 - 1:16
    discutido en el último segmento, pero por supuesto en WEP, se utiliza incorrectamente y
  • 1:16 - 1:19
    es completamente inseguro la forma en que se utiliza dentro de WEP. Lo largo de los años,
  • 1:19 - 1:24
    se han encontrado algunas deficiencias en RC4, y como resultado, se recomienda que nuevos proyectos
  • 1:24 - 1:29
    en realidad no utilizar RC4 pero prefiere usar un generador pseudoaleatorio más moderno como veremos
  • 1:29 - 1:34
    discutir hacia el final del segmento. Así que permítanme mencionar sólo dos de los puntos débiles.
  • 1:34 - 1:40
    Por lo que es la primera de ellas, es tipo de extraño básicamente, si nos fijamos en el segundo byte
  • 1:40 - 1:45
    de la salida de RC4. Resulta que el segundo byte está ligeramente sesgada. Si fue de RC4
  • 1:45 - 1:50
    completamente al azar, la probabilidad de que el segundo byte pasa a ser igual a cero
  • 1:50 - 1:55
    exactamente uno sería más de 256. Hay 256 bytes posibles, la probabilidad de que
  • 1:55 - 2:00
    es la cero debería ser uno más de 256. Resulta que para RC4 la probabilidad es
  • 2:00 - 2:04
    realmente dos sobre 256, lo que significa que si usas la salida RC4 para cifrar una
  • 2:04 - 2:10
    mensaje el segundo byte es probable que no sean encriptados. En otras palabras le
  • 2:10 - 2:15
    ser XOR-ed con cero con dos veces la probabilidad de que se supone que.
  • 2:15 - 2:19
    Dos sobre 256, en lugar de uno sobre 256.
    Y por cierto debo decir que hay
  • 2:19 - 2:23
    nada especial en el segundo byte. Resulta que la primera y los terceros bytes
  • 2:23 - 2:28
    también están sesgadas. Y de hecho se ahora recomienda si vas a usar RC4,
  • 2:28 - 2:33
    lo que debe hacer es ignorar básicamente los primeros 256 bytes de la salida y sólo
  • 2:33 - 2:37
    empezar a utilizar la salida del generador a partir de byte 257. La primera pareja
  • 2:37 - 2:41
    de bytes resultados ser sesgada, así que usted sólo ignorarlos. El segundo ataque
  • 2:41 - 2:48
    se descubrió que de hecho si observas una muy larga salida de RC4 resulta
  • 2:48 - 2:54
    que es más probable conseguir la secuencia 00. En otras palabras, eres más
  • 2:54 - 2:59
    probabilidades de tener dieciséis bits, dos bytes de cero, cero, lo que debería. Nuevamente, si RC4
  • 2:59 - 3:04
    fue completamente al azar la probabilidad de ver cero, cero sería exactamente 1/256
  • 3:04 - 3:09
    cuadrado. Resulta que es un poco tendencioso RC4 y el sesgo en cubos de 1/256. Se
  • 3:09 - 3:14
    resulta de este sesgo comienza realmente después de varios gigabytes de datos son producidos por
  • 3:14 - 3:19
    RC4. Pero sin embargo, esto es algo que puede utilizarse para predecir el generador
  • 3:19 - 3:23
    y definitivamente puede utilizarse para distinguir la salida del generador
  • 3:23 - 3:28
    desde una secuencia aleatoria. Básicamente el hecho de que cero, cero aparece más a menudo
  • 3:28 - 3:32
    lo que debería es el distinguisher. Y, a continuación, en el último segmento hablamos sobre
  • 3:32 - 3:36
    ataques de clave relacionada que se utilizaron para atacar WEP, que básicamente dicen
  • 3:36 - 3:41
    Si uno usa las claves que están estrechamente relacionadas entre sí es posible
  • 3:41 - 3:46
    para recuperar la clave raíz. Así que estos son los puntos débiles que se conocen de RC4 y, como un
  • 3:46 - 3:50
    resultado, se recomienda que nuevos sistemas realmente no utilizan RC4 y en su lugar utilizan un
  • 3:50 - 3:54
    moderno generador pseudoaleatorio. Vale, la segunda es el ejemplo que quiero darle un
  • 3:54 - 3:59
    cifrado de flujo mal roto que se utiliza para cifrar las películas en DVD. Cuando compres un DVD
  • 3:59 - 4:04
    en la tienda, la película real se cifra mediante un cifrado de flujo que se llama el
  • 4:04 - 4:08
    sistema de codificación, CSS de contenido. CSS resulta para ser un cifrado de flujo mal roto,
  • 4:08 - 4:13
    muy fácilmente podemos romperlo y quiero mostrarle cómo el algoritmo de ataque
  • 4:13 - 4:17
    obras. Que estamos haciendo para que pueda ver un ejemplo de un algoritmo de ataque, pero en
  • 4:17 - 4:21
    hecho, hay muchos sistemas que hay que utilizar básicamente este ataque para descifrar
  • 4:21 - 4:26
    DVDs cifrados. Así que la CSS stream cipher es basado en algo que el hardware
  • 4:26 - 4:30
    como diseñadores. Ha diseñado para ser un cifrado de flujo de hardware que se supone que
  • 4:30 - 4:34
    ser fácil de implementar en hardware y se basa en un mecanismo llamado lineal
  • 4:34 - 4:39
    Feedback shift register. Por lo tanto un registro de desplazamiento lineal de retroalimentación es básicamente un registro
  • 4:39 - 4:44
    consiste en células donde cada celda contiene un bit. A continuación, básicamente
  • 4:44 - 4:49
    lo que pasa es que hay Estos grifos en ciertas células, no todas las células, ciertos
  • 4:49 - 4:54
    posiciones son llamados grifos. Y luego estos grifos de alimentación en un XOR y, a continuación, en
  • 4:54 - 4:59
    cada ciclo de reloj, el cambio de registrar cambios hacia la izquierda. Cae el último bit
  • 4:59 - 5:04
    y entonces el primer bit se convierte en el resultado de este XOR. Por lo que se puede ver que
  • 5:04 - 5:09
    Este es un mecanismo muy simple de implementar y en hardware tiene muy pocos
  • 5:09 - 5:14
    transistores. Sólo el cambio justo, cae el bit último y el primer bit sólo
  • 5:14 - 5:19
    se convierte en el XOR de los bits anteriores. Por eso la semilla para este LFSR
  • 5:19 - 5:23
    Básicamente, es el estado inicial de la LFSR.
  • 5:24 - 5:29
    Y es la base de un número de cifrados en flujo. Aquí hay algunos ejemplos. Así, como
  • 5:29 - 5:33
    Es decir, DVD cifrado utiliza dos LFSR.
    Te voy a mostrar cómo funciona sólo un
  • 5:33 - 5:38
    en segundo lugar. Cifrado GSM, estos son algoritmos llamados A51 y A52. Y
  • 5:38 - 5:43
    utiliza tres LFSR Bluetooth cifrado es un algoritmo llamado, cero E. Estos son todos los
  • 5:43 - 5:49
    cifrados en flujo, y que utiliza cuatro LFSR. resulta que todos estos son mal roto,
  • 5:49 - 5:53
    y realmente, realmente no debe confiar para cifrar el tráfico, pero son todos
  • 5:53 - 5:57
    implementado en el hardware, por lo que ahora es un poco difícil para cambiar el hardware
  • 5:57 - 6:01
    hace. Pero el más simple de estos, CSS, realmente tiene un lindo ataque sobre él, así que
  • 6:01 - 6:05
    me muestran cómo funciona el ataque. Por lo tanto, vamos a describir cómo funciona CSS. Por lo tanto,
  • 6:05 - 6:11
    la clave para CSS es cinco bytes, es decir, 40 bits, cinco veces ocho es de 40 bits. El
  • 6:11 - 6:16
    razón tuvieron que limitarse a sólo 40 bits es que fue cifrado de DVD
  • 6:16 - 6:20
    diseñado en un momento donde sólo permitieron regulaciones de exportación de Estados Unidos para la exportación de
  • 6:20 - 6:25
    algoritmos de crpyto donde la clave fue sólo de 40 bits. Así fueron los diseñadores de CSS
  • 6:25 - 6:30
    ya limitado a claves muy, muy cortas.
    Sólo las claves de 40 bits. Por lo tanto, su diseño funciona
  • 6:30 - 6:35
    como sigue. Básicamente, CSS utiliza de dos LFSR. Uno es un LFSR de 17 bits. En otras palabras,
  • 6:35 - 6:41
    el registro contiene 17 bits. Y el otro es un LFSR 25 bits,
  • 6:41 - 6:47
    es un poco más, 25 bits LFSR. Y la forma en que se siembran estos LFSR
  • 6:47 - 6:52
    es como sigue. Así que la clave para el cifrado, básicamente se ve como sigue.
  • 6:52 - 6:58
    Comienzas con un uno, y se concatenar para los dos primeros bytes de
  • 6:58 - 7:03
    la clave. Y es el estado inicial de la LFSR.
  • 7:03 - 7:08
    Y luego la segunda LFSR básicamente es intitialized la misma manera.
  • 7:08 - 7:14
    Uno concatenados los tres últimos bytes de la clave. Y esa es la
  • 7:14 - 7:20
    cargado en el estado inicial de la LFSR.
    Puede ver que los dos primeros bytes son
  • 7:20 - 7:25
    dieciséis bits, además de un líder, que diecisiete bits en general, mientras que el segundo
  • 7:25 - 7:31
    LFSR es 24 bits más uno que es de 25 bits.
    Y observa que usamos todos los cinco bits de
  • 7:31 - 7:37
    la clave. Entonces que estos LFSR es básicamente durará ocho ciclos, por lo que generan
  • 7:37 - 7:42
    ocho bits de salida. Y luego se van a través de esta víbora que hace básicamente
  • 7:42 - 7:48
    suma módulo 256. Sí, por lo que se trata de un cuadro de adición, módulo 256. Hay uno más
  • 7:48 - 7:54
    técnica lo que sucede. De hecho vamos a realmente — también agregó es el acarreo de la
  • 7:54 - 8:00
    bloque anterior. Pero eso no es tan importante. Eso es un detalle que no es así
  • 8:00 - 8:05
    pertinentes. OK, así que cada bloque, notará que estamos haciendo suma módulo 256 y
  • 8:05 - 8:10
    nosotros estamos ignorando el acarreo, pero el transporte básicamente se agrega como un cero o un uno a la
  • 8:10 - 8:15
    adición del siguiente bloque. ¿Vale? Y, a continuación, básicamente esta salida un byte por ronda.
  • 8:15 - 8:20
    Vale, y entonces este byte es entonces por supuesto utilizado, XOR-ed con la adecuada
  • 8:20 - 8:25
    byte de la película que está siendo encriptada.
    Bueno, por lo que es una secuencia muy simple
  • 8:25 - 8:30
    cifrado, tarda muy poco hardware a implementar. Se ejecutará rápido, incluso muy
  • 8:30 - 8:36
    hardware barato y se cifrará películas.
    Por lo que resulta de esto es fácil de romper
  • 8:36 - 8:41
    en tiempo aproximadamente dos a los diecisiete años. Ahora Permítanme mostrarles cómo.
  • 8:41 - 8:46
    Así que supongamos que interceptar las películas, así que aquí tenemos un
  • 8:46 - 8:51
    película cifrado que desea descifrar.
    Así que vamos a decir que esto es todo cifrado lo
  • 8:51 - 8:55
    no tienes idea lo que está dentro de aquí.
    Sin embargo, resulta sólo porque
  • 8:55 - 9:00
    Codificación de DVD está utilizando archivos MPEG, sucede si usted sabe de un prefijo de la
  • 9:00 - 9:04
    texto plano, digamos tal vez esto es veinte bytes. Ahora bien, sabemos que si usted
  • 9:04 - 9:09
    XOR estas dos cosas juntas, en otras palabras, que hacer el XOR aquí,
  • 9:09 - 9:14
    lo que usted obtendrá es el segmento inicial de la PRG. Así, obtendrá el
  • 9:14 - 9:18
    primeros veinte bytes de la salida de CSS, la salida de este PRG. Bueno, ahora
  • 9:18 - 9:24
    aquí es lo que vamos a hacer. Así tenemos los veinte primeros bytes de la salida. Ahora
  • 9:24 - 9:31
    hacemos lo siguiente. Tratamos todos los dos a los diecisiete valores posibles de la primera
  • 9:31 - 9:37
    LFSR. ¿Vale? Dos a los diecisiete valores posibles. Para cada valor, para
  • 9:37 - 9:43
    cada de estos dos, a los diecisiete valores iniciales de la LFSR, vamos a ejecutar la
  • 9:43 - 9:48
    LFSR para veinte bytes, ¿vale? Por eso te generar 20 bytes de salidas de este
  • 9:48 - 9:53
    primera LFSR, asumiendo — para cada uno de los dos a las diecisiete configuraciones posibles.
  • 9:53 - 9:59
    Ahora, recuerde que tenemos la salida completa del sistema de la CSS. Así lo que podemos hacer es
  • 9:59 - 10:04
    puede tomar esta salida que tenemos. Y Réstelo de las mordeduras de veinte que nosotros
  • 10:04 - 10:09
    obtuvo de la primera LFSR y si de hecho nuestra estimación para el estado inicial de la primera
  • 10:09 - 10:14
    LFSR es correcta, lo que lleguemos es la primera salida de veinte bytes de la
  • 10:14 - 10:19
    segunda LFSR. ¿Verdad? Debido a es, por definición, lo que la salida de la CSS
  • 10:19 - 10:25
    es el sistema. Ahora, resulta que mirando una secuencia de 20 bytes, es muy fácil
  • 10:25 - 10:30
    para saber si esta secuencia de 20 bytes procede de un LFSR 25 bits o no. Si se
  • 10:30 - 10:34
    no, entonces sabemos que nuestra estimación de la LFSR de 17 bits
  • 10:34 - 10:37
    incorrecto y, a continuación, pasamos a la siguiente supongo que para el LFSR de 17 bits y
  • 10:37 - 10:42
    la próxima adivinar y así sucesivamente y así sucesivamente.
    Hasta que finalmente nos alcanzaron el derecho inicial
  • 10:42 - 10:47
    Estado para el LFSR de 17 bits y luego nos pondremos realmente, veremos que
  • 10:47 - 10:52
    los 20 bytes que obtenemos como candidato es de salida para el LFSR 25 bits
  • 10:52 - 10:57
    de hecho de una posible salida para un LFSR 25 bits. Y entonces, no sólo tendremos
  • 10:57 - 11:02
    aprendió el correcto estado inicial para el LFSR de 17 bits, tendremos también
  • 11:02 - 11:08
    aprendió el correcto estado inicial de la LFSR 25 bits. Y, a continuación, podemos predecir el
  • 11:08 - 11:13
    restantes salidas de CSS y por supuesto, con que nos podemos descifrar el resto de
  • 11:13 - 11:18
    la película. Realmente podemos recuperar el texto restante. Esta bien. Esto es
  • 11:18 - 11:22
    cosas que hemos hablado antes. Por lo tanto, lo dicho un poco rápido, pero ojalá,
  • 11:22 - 11:27
    estaba claro. También vamos a estar haciendo un ejercicio de la tarea en este tipo de secuencia
  • 11:27 - 11:31
    tipo de cifrados y usted obtendrá el punto de cómo estos algoritmos de ataque
  • 11:31 - 11:36
    trabajo. Y debo mencionar que existen muchos sistemas de código abierto ahora que realmente
  • 11:36 - 11:41
    Utilice este método para descifrar los datos cifrados de CSS. Vale, ahora que hemos visto dos
  • 11:41 - 11:46
    ejemplos débiles, pasemos a ejemplos mejores y en particular el mejor
  • 11:46 - 11:49
    generadores pseudoaleatorios provienen de lo que ha llamado el eStream proyecto. Este es un
  • 11:49 - 11:56
    proyecto que concluyó en 2008, y califican básicamente cinco diferentes stream
  • 11:56 - 12:00
    cifrados, pero aquí quiero presentar sólo uno. Lo primero de todos los parámetros para
  • 12:00 - 12:04
    son un poco diferentes de lo que estamos acostumbrados a estos cifrados en flujo. Por lo que estas
  • 12:04 - 12:08
    secuencia de cifra normalmente tienen una semilla.
    Pero además también tienen, lo que de
  • 12:08 - 12:13
    llamado un nonce y nos veremos qué se utiliza un nonce en sólo un minuto. Por lo tanto
  • 12:13 - 12:17
    llevan dos entradas una semilla y un nonce.
    Vamos a ver qué se usa el nonce en
  • 12:17 - 12:21
    sólo un segundo. Y el supuesto producen una salida muy grande, así que n es aquí
  • 12:21 - 12:27
    mucho, mucho, mucho mayor que s. Ahora, cuando digo nonce, lo que quiero decir es un valor que
  • 12:27 - 12:31
    Nunca se va a repetir como la clave es fijo. Y explicaré en más
  • 12:31 - 12:35
    detalle en sólo un segundo. Pero por ahora, sólo piense en ello como un único no valor que nunca
  • 12:35 - 12:41
    repite como la clave es la misma.
    Y tan naturalmente una vez que tenga este PRG,
  • 12:41 - 12:45
    se podría cifrar, usted obtiene un cifrado de flujo igual que antes, excepto ahora como ves, la
  • 12:45 - 12:50
    PRG toma como entrada el clave y el nonce. Y la propiedad de la nonce
  • 12:50 - 12:56
    que el par, k coma r, para que la coma clave la nonce, nunca, nunca se repite. Tiene
  • 12:56 - 13:03
    Nunca utilizar más de una vez. Así que la línea de fondo es que se puede reutilizar la clave, reutilización
  • 13:03 - 13:10
    la clave, porque la nonce hace la pareja única, porque el k y r son sólo
  • 13:10 - 13:16
    usar una vez. Yo diría que son únicos. Bien por lo que es este nonce truco tipo de un lindo
  • 13:16 - 13:22
    nos ahorra la molestia de mover a una nueva clave cada vez. Está bien, así que el particular
  • 13:22 - 13:26
    ejemplo de la eStream que quiero mostrarle se llama Salsa veinte. Es un
  • 13:26 - 13:30
    cifrado de flujo que está diseñado para implementaciones de software y hardware
  • 13:30 - 13:33
    implementaciones. Es interesante.
    Te das cuenta de que son algunos cifrados en flujo
  • 13:33 - 13:39
    diseñada para el software, como RC4.
    Todo lo que hace está diseñada para hacer
  • 13:39 - 13:43
    implementación de software correr rápido, mientras que otros cifrados en flujo están diseñados para
  • 13:43 - 13:48
    hardware, como CSS, usando un LFSR que ha diseñado especialmente para hardware
  • 13:48 - 13:51
    implementaciones muy baratas. Es también, lo bueno de eso es que es
  • 13:51 - 13:55
    diseñado de manera que es tanto fácil de implementarlo en el hardware y su software
  • 13:55 - 14:00
    aplicación también es muy rápido. Así que permítanme explicar cómo funciona la Salsa. Bueno, Salsa
  • 14:00 - 14:05
    toma las llaves de 128 ó 256 bits. Sólo voy a explicar la versión de 128 bits de la Salsa.
  • 14:05 - 14:11
    Esto es la semilla. Y, a continuación, también tiene un nonce, justo como antes, que
  • 14:11 - 14:15
    pasa a ser de 64 bits. Y luego te genera una gran salida. Ahora, cómo se
  • 14:15 - 14:21
    ¿realmente funciona? Así, la propia función se define como sigue. Básicamente, dado
  • 14:21 - 14:26
    la clave y el nonce, generará una muy larga, bueno, una larga pseudoaleatorio
  • 14:26 - 14:31
    secuencia, tanto tiempo como sea necesario. Y lo haremos utilizando esta función que voy denotar por
  • 14:31 - 14:36
    H. esta función h toma tres entradas.
    Básicamente la clave. Bien, la semilla k,
  • 14:36 - 14:40
    la Nuna r y luego un contador que aumenta desde el paso a paso. So it goes
  • 14:40 - 14:45
    de cero a uno, dos, tres, cuatro como mucho como nosotros [inaudible] ser. ¿Vale? Así que, básicamente,
  • 14:45 - 14:50
    por evaluar este h en esta r k, pero este incremento contador, podemos obtener un
  • 14:50 - 14:55
    secuencia que es tan larga como queramos. Así lo único que tengo que hacer es describir cómo esta función
  • 14:55 - 14:59
    H obras. Ahora, permítanme hacer eso aquí para usted.
    El funcionamiento es como sigue. Bueno, nos
  • 14:59 - 15:05
    empezar por la expansión de los Estados en algo bastante grande que es de 64 bytes
  • 15:05 - 15:10
    larga ya haga lo siguiente. Básicamente nos atenemos una constante desde el principio, así que
  • 15:10 - 15:16
    Hay tao cero, estas son cuatro bytes, es una constante de cuatro bytes, por lo tanto las especificaciones para
  • 15:16 - 15:21
    Salsa básicamente le da el valor para tao cero. Luego ponemos k en la que es
  • 15:21 - 15:25
    16 bytes. Luego ponemos otra constante. Nuevamente, esto es cuatro bytes. Y
  • 15:25 - 15:31
    como dije, la especificación especifica básicamente lo que es esta constante fija. A continuación, ponemos
  • 15:31 - 15:37
    el nonce, que es ocho bytes. A continuación ponemos el índice. Este es el contador a cero,
  • 15:37 - 15:43
    uno, dos, tres, cuatro, que es otro ocho bytes. Luego ponemos otra constante
  • 15:43 - 15:49
    Tau dos, que es otro cuatro bytes.
    A continuación, ponemos la clave de nuevo, este es otro
  • 15:49 - 15:55
    16 bytes. Y entonces finalmente ponemos el tercer tau constante, tres, que es
  • 15:55 - 16:00
    otro cuatro bytes. Está bien tal como dije, si estas resumir, ves que te 64
  • 16:00 - 16:05
    bytes. Así que básicamente hemos ampliado la clave y el nonce y el contador en 64
  • 16:05 - 16:11
    bytes. Básicamente se repite la tecla dos veces supongo. Y entonces lo que hacemos es aplicar un
  • 16:11 - 16:16
    función, que llamaré esta h. poco funcional bien, por lo que aplicar esta función, poco h.
  • 16:16 - 16:22
    Y esta es una función que es uno a uno, por lo que asigna 64 bytes a 64 bytes. Es un
  • 16:22 - 16:26
    ¿función completamente invertible, okay? Para esta función h es, como digo, es un
  • 16:26 - 16:30
    función invertable. Así que dada la entrada puede obtener la salida y la
  • 16:30 - 16:35
    Puedes volver a la entrada de la salida. Y está diseñado específicamente para que tiene un - fácil
  • 16:35 - 16:40
    para implementar en hardware y b-en un x 86, es extremadamente fácil de implementar porque
  • 16:40 - 16:44
    x 86 tiene este SSE2 conjunto de instrucciones que soporta todas las operaciones que debe hacer
  • 16:44 - 16:49
    para esta función. Es muy, muy rápido.
    Como resultado, la Salsa tiene un flujo muy rápido
  • 16:49 - 16:53
    cifrado. Y luego lo hace básicamente una y otra vez. Por lo que se aplica esta
  • 16:53 - 16:58
    función h nuevamente y se obtiene otro de 64 bytes. Y así sucesivamente y así sucesivamente, básicamente
  • 16:58 - 17:05
    hace esto diez veces. Esta bien todo esto aquí, decir repite diez veces, así que
  • 17:05 - 17:18
    básicamente se aplican h diez veces. Y luego por sí mismo, esto es realmente no muy aleatorio.
  • 17:18 - 17:22
    No va a mirar al azar porque como hemos dicho, H es completamente invertable. Tan dado
  • 17:22 - 17:26
    Este resultado final, es muy fácil invertir sólo h y luego volver al original
  • 17:26 - 17:32
    entradas y luego prueba que la entrada tiene la estructura correcta. Entonces hacer uno más
  • 17:32 - 17:37
    cosa, que es básicamente XOR las entradas y las salidas finales. En realidad,
  • 17:37 - 17:42
    lo siento. No es un XOR. Es realmente una adición. Entonces hacer una palabra además
  • 17:42 - 17:48
    palabra. Así que si hay 64 bytes, no una adición de la palabra por palabra cuatro bytes en un
  • 17:48 - 17:53
    tiempo y finalmente obtener la salida de 64 bytes, y eso es todo. Eso es todo
  • 17:53 - 17:57
    generador pseudoaleatorio. Así que, es la función entera, poco h. Y como yo
  • 17:57 - 18:02
    explicó, esta construcción es la función de gran H. Y luego evaluar
  • 18:02 - 18:06
    Big h incrementando el contador desde cero, uno, dos, tres adelante. Y
  • 18:06 - 18:10
    le dará una secuencia pseudoaleatoria, siempre y cuando usted lo necesita para ser. Y
  • 18:10 - 18:15
    Básicamente, no hay ninguna signifigant ataques a este. Esto tiene la seguridad que
  • 18:15 - 18:20
    muy cerca de dos a los 128. Vamos a ver lo que significa más precisamente más tarde por.
  • 18:20 - 18:25
    Es un cifrado de flujo muy rápido, tanto en hardware como en software. Y, en cuanto
  • 18:25 - 18:30
    podemos decir, que parece ser impredecible como necesaria para un cifrado de flujo. Así que me
  • 18:30 - 18:35
    debería decir que el proyecto de eStream realmente tiene cinco cifrados en flujo como
  • 18:35 - 18:39
    esto. Elegí sólo Salsa porque creo que es la más elegante. Pero le puedo dar
  • 18:39 - 18:44
    aquí algunos números de rendimiento. Para que puedas ver, estos son números de rendimiento en un
  • 18:44 - 18:49
    2.2 gigahercios, sabes, tipo máquina x 86.
    Y se puede ver que en realidad es RC4 el
  • 18:49 - 18:53
    más lento. Porque básicamente, bien no realmente toma ventaja de la
  • 18:53 - 18:57
    hardware. No sólo las operaciones de byte.
    Así que hay un montón de desperdiciadas ciclos que
  • 18:57 - 19:01
    no están siendo utilizados. Pero los candidatos E-Stream, tanto Salsa y otros
  • 19:01 - 19:05
    candidato llamado Sosemanuk. Yo diría que estos son los finalistas eStream. Estos son
  • 19:05 - 19:10
    realmente cifrados en flujo que estén aprobados por el proyecto eStream. Se puede ver que
  • 19:10 - 19:14
    que han alcanzado una tasa significativa.
    Se trata de 643 megabytes por segundo en este
  • 19:14 - 19:18
    arquitectura, más que suficiente para una película y estas son realmente impresionantes
  • 19:18 - 19:22
    tasas. Y ahora que has visto ejemplos de dos viejos cifrados en flujo no deberían ser
  • 19:22 - 19:27
    usa, incluidos ataques contra los cifrados en flujo.
    Has visto lo que la corriente moderna de cifra
  • 19:27 - 19:30
    aspecto con este nonce. Y ver los números de rendimiento para estos
  • 19:30 - 19:35
    stream moderno de cifra por lo que si usted necesita un cifrado de flujo puede utilizar uno de
  • 19:35 - 19:38
    los finalistas eStream. En particular, se podría utilizar algo como Salsa.
Title:
Real-world stream ciphers (20 min)
Video Language:
English

Spanish subtitles

Revisions