WEBVTT 00:00:00.000 --> 00:00:03.837 En este segmento, vamos a construir sistemas de cifrado autenticado. A partir de 00:00:03.837 --> 00:00:08.250 haber conseguido cifrado seguro CPA y tener MACs seguros, la pregunta obvia 00:00:08.250 --> 00:00:12.824 es si podemos combinar los dos de alguna manera, a fin de obtener cifrado autenticado. 00:00:12.824 --> 00:00:15.721 Y eso es exactamente lo que vamos a hacer en este segmento. El cifrado autenticado 00:00:15.721 --> 00:00:20.447 fue introducido en el año 2000, en dos informes independientes que indicaré al 00:00:20.447 --> 00:00:25.915 final de este módulo. Antes de eso, muchas librerías criptográficas proporcionaban una API que, 00:00:25.915 --> 00:00:31.215 por separado, admitían cifrado seguro CPA, y MACing. Así que había una 00:00:31.215 --> 00:00:36.175 función para implementar el cifrado seguro CPA, por ejemplo, CBC con 00:00:36.175 --> 00:00:41.136 IV aleatorio, y otra función para implementar MAC. Y a continuación, cada desarrollador que 00:00:41.136 --> 00:00:45.646 quería implementar el cifrado, tenía que llamar por separado al esquema de 00:00:45.646 --> 00:00:50.552 cifrado CPA y al esquema de MAC. En concreto, cada desarrollador tuvo que inventar 00:00:50.552 --> 00:00:55.697 su propio modo de combinar MAC-ing y cifrado para proporcionar algún tipo de 00:00:55.697 --> 00:00:59.376 cifrado autenticado. Pero los objetivos de la combinación de cifrado y MAC-ing 00:00:59.376 --> 00:01:03.690 no fueron bien entendidos ya que el cifrado autenticado no había sido definido aún. 00:01:03.690 --> 00:01:08.497 No estaba muy claro qué combinaciones de cifrado y MAC-ing eran correctos y 00:01:08.497 --> 00:01:13.243 cuales no. Y como dije, cada proyecto tuvo que inventar su propia combinación. 00:01:13.243 --> 00:01:17.202 Y de hecho, no todas las combinaciones eran correctas. Y les puedo decir ya que 00:01:17.202 --> 00:01:22.556 el error más común en proyectos software fue básicamente combinar incorrectamente los 00:01:22.556 --> 00:01:27.025 mecanismos de cifrado e integridad. Así que esperemos que, al final de este módulo, usted 00:01:27.025 --> 00:01:31.260 sepa cómo combinarlos correctamente y no cometer estos errores. 00:01:31.260 --> 00:01:35.174 Analicemos algunas combinaciones de cifrado seguro CPA y 00:01:35.174 --> 00:01:39.303 MAC, que fueron introducidas por los diferentes proyectos. Aquí hay tres ejemplos. 00:01:39.303 --> 00:01:43.816 En primer lugar, en los tres ejemplos hay una clave independiente para el cifrado, y 00:01:43.816 --> 00:01:47.774 otra clave independiente para integridad. Estas dos claves son independientes una de otra, y 00:01:47.774 --> 00:01:52.224 ambas se generan en tiempo de instalación de la sesión. Y vamos a ver cómo generar estas 00:01:52.224 --> 00:01:57.071 dos claves más adelante en el curso. El primer ejemplo es el protocolo SSL. 00:01:57.071 --> 00:02:02.681 El modo en que SSL combina cifrado y MAC con la esperanza de lograr cifrado autenticado 00:02:02.681 --> 00:02:07.656 es la siguiente. Básicamente toma el texto plano m, y luego calcula el MAC 00:02:07.656 --> 00:02:13.415 de ese texto plano m. De esta forma, se usa la clave MAC Ki, para calcular la etiqueta de este mensaje 00:02:13.415 --> 00:02:17.787 m. Y, a continuación, se anexa la etiqueta al mensaje y se cifra la 00:02:17.787 --> 00:02:22.580 combinación de mensaje y etiqueta, obteniendo el texto cifrado final. 00:02:22.580 --> 00:02:26.710 Esta es la opción número uno. La segunda opción es lo que hace IPsec. 00:02:26.710 --> 00:02:31.160 Aquí, tomamos el mensaje, y lo primero que se hace es cifrar el mensaje. 00:02:31.160 --> 00:02:35.692 Y, a continuación, calcular una etiqueta a partir del texto cifrado resultante. Obsérvese que la 00:02:35.692 --> 00:02:40.238 etiqueta se calcula sobre el texto cifrado resultante. Una tercera opción es lo que hace 00:02:40.238 --> 00:02:45.429 el protocolo SSH. Aquí, el SSH toma el mensaje y lo cifra utilizando un 00:02:45.429 --> 00:02:50.944 esquema de cifrado seguro CPA. Y a continuación se agrega una etiqueta al mensaje. La 00:02:50.944 --> 00:02:55.567 diferencia entre IPsec y SSH, es que en IPsec la etiqueta es calculada a partir del 00:02:55.567 --> 00:02:59.988 texto cifrado, mientras que en SSH la etiqueta se calcula a partir del mensaje. Por tanto, estas 00:02:59.988 --> 00:03:04.536 son tres formas completamente diferentes de combinar cifrado y MAC. Y la 00:03:04.536 --> 00:03:09.090 cuestión es cual de ellos es seguro. Por tanto, le permitiré pensar en esto un 00:03:09.090 --> 00:03:12.105 segundo y luego seguiremos y juntos haremos el análisis. Muy bien. Vamos a 00:03:13.197 --> 00:03:17.164 comenzar con el método SSH. En el método SSH observará que la etiqueta se calcula 00:03:17.164 --> 00:03:21.629 en el mensaje y, a continuación se concatena en claro en el texto cifrado. Esto es 00:03:21.629 --> 00:03:26.407 realmente un problema porque MAC por sí mismo no está diseñado para proporcionar 00:03:26.407 --> 00:03:30.784 confidencialidad. MAC sólo está diseñado para integridad. Y de hecho, no hay 00:03:30.784 --> 00:03:36.008 [...no revisado a partir de aquí..] nada malo con un Mac que como parte de la etiqueta genera unos trozos de la llanura 00:03:36.008 --> 00:03:41.458 texto. Salidas de unos bits del mensaje M. Eso sería una etiqueta perfectamente bien. Y si 00:03:41.458 --> 00:03:46.667 hicimos que rompería completamente seguridad CPA aquí, porque algunos bits de 00:03:46.667 --> 00:03:51.815 el mensaje se filtró en el texto cifrado. Y así el SSH enfoque, aunque el 00:03:51.815 --> 00:03:56.595 características de SSH son finos y el periódico propio no se vea comprometido por 00:03:56.595 --> 00:04:00.818 Esta combinación específica, generalmente es recomendable no utilizar este enfoque. Simplemente 00:04:00.818 --> 00:04:05.928 debido a la salida de la max firma de ritmo posible fuga bits del mensaje. Por lo tanto 00:04:05.928 --> 00:04:11.481 Ahora analicemos SSL y IBSEC. Según parece, el método recomendado en realidad 00:04:11.481 --> 00:04:16.556 es el método IBSEC. Porque resulta que no importa qué sistema seguro de CPA y mac 00:04:16.556 --> 00:04:21.134 clave que se utiliza la combinación siempre es va a proporcionar encriptación autenticada. 00:04:21.134 --> 00:04:26.070 Permítanme explicar muy brevemente por qué. Básicamente lo que sucede es que una vez que ciframos 00:04:26.070 --> 00:04:31.005 el mensaje bien el mensaje de contenido ahora está oculto dentro del texto de cypher y ahora 00:04:31.005 --> 00:04:35.761 cuando nos calcular una etiqueta de texto cypher básicamente nos estamos bloqueo, los bloqueos de esta etiqueta 00:04:35.761 --> 00:04:40.815 el texto de cypher y hace que nadie puede producir un texto de cypher diferentes que 00:04:40.815 --> 00:04:45.314 aspecto válido. Y como resultado este enfoque asegura que cualquier modificación a la 00:04:45.314 --> 00:04:49.555 Cypher texto será detectado por el decrypter simplemente porque no la mac 00:04:49.555 --> 00:04:54.026 va a comprobar. Pues resulta que, por el enfoque SSL, realmente hay tipo de 00:04:54.026 --> 00:04:59.348 ejemplos patológicos, donde se combina CPA sistema de cifrado seguro con un seguro 00:04:59.348 --> 00:05:03.542 MAC. Y el resultado es vulnerable a un ataque de texto cifrado elegido, por lo que lo hace 00:05:03.542 --> 00:05:07.978 en realidad no proporcionan cifrado autenticado. Básicamente, la razón y que 00:05:07.978 --> 00:05:12.824 podría suceder, es que hay algún tipo de una mala interacción entre el cifrado 00:05:12.824 --> 00:05:17.319 esquema y el algoritmo de MAC. Tal que, de hecho, habrá un cifrado elegido 00:05:17.319 --> 00:05:21.752 ataque de texto. Así que si va a diseñar un nuevo proyecto ahora la recomendación es 00:05:21.752 --> 00:05:26.162 siempre uso entonces cifrar Mac debido a que es seguro no importa qué CPA segura 00:05:26.162 --> 00:05:30.607 cifrado y el algoritmo seguro de Mac que está combinando. Ahora, sólo para establecer la 00:05:30.607 --> 00:05:37.995 terminología, el método SSL se denomina Mac. Y, a continuación, cifrar. Y el 00:05:37.995 --> 00:05:45.039 Se llama al método de IP-SEC cifrar luego Mac El método [inaudible] a pesar de su 00:05:45.039 --> 00:05:51.898 no supone que para usarlo, se llama cifrar y Mac. Muy bien, por lo que a menudo va a: 00:05:51.898 --> 00:05:57.002 cifrar y MAC y MAC y cifrar para diferenciar SSL y IP sec. Okay, tan 00:05:57.002 --> 00:06:02.112 sólo para repetir lo que he de acaba. El método [inaudible] ip cifrar siempre en mac 00:06:02.112 --> 00:06:07.160 nos proporcionan un cifrado indicado. Si inicia desde [inaudible] y un mac seguro. 00:06:07.160 --> 00:06:11.110 Siempre obtendrá cifrado autenticado. Como dije, [inaudible] en 00:06:11.110 --> 00:06:15.737 hecho, hay casos patológicos donde el resultado es vulnerable a hechos de ECP y 00:06:15.737 --> 00:06:20.308 por lo tanto no proporciona cifrado autenticado. Sin embargo, la historia s un poco 00:06:20.308 --> 00:06:24.653 poco más interesante que eso, que resulta que, si realmente está utilizando 00:06:24.653 --> 00:06:29.224 aleatorios a modo de contador o CBC aleatorio, entonces resulta que, para los particulares 00:06:29.224 --> 00:06:33.625 Esquemas de cifrado seguro de CPA, [inaudible] realmente proporcionar autenticado 00:06:33.625 --> 00:06:38.028 cifrado y por lo tanto es seguro. De hecho, hay incluso una más interesante 00:06:38.028 --> 00:06:42.334 Twist aquí que si utiliza el modo contador aleatorios. Entonces, es suficiente 00:06:42.334 --> 00:06:46.804 que el algoritmo de Mac solo una vez segura. No tiene que ser un completo 00:06:46.804 --> 00:06:51.561 Mac seguro. Sólo tiene que ser seguro cuando se utiliza una clave para cifrar un mensaje único, 00:06:51.561 --> 00:06:56.088 ¿bien? Y cuando hablamos de la integridad del mensaje, vimos que hay realmente 00:06:56.088 --> 00:07:00.575 Macs mucho más rápidos que una vez seguro que Macs que son totalmente seguras. Como un 00:07:00.575 --> 00:07:04.454 resultado, si está utilizando el modo de contador aleatorios MAC cifrar podría realmente 00:07:04.454 --> 00:07:08.187 como resultado de un mecanismo de cifrado más eficaz. Sin embargo, voy a repetir 00:07:08.187 --> 00:07:12.213 Esto otra vez. La recomendación es utilizar cifrar entonces MAC y nos vamos a ver un 00:07:12.213 --> 00:07:16.093 número de ataques a sistemas que no utilizan entonces cifrar Mac Y así hacer 00:07:16.093 --> 00:07:20.120 seguro cosas son seguras sin tener que pensar demasiado sobre ello. Una vez más, estoy 00:07:20.120 --> 00:07:24.118 va a recomienda que siempre utilice luego cifrar Mac Ahora, una vez el concepto de 00:07:24.118 --> 00:07:27.759 cifrado autenticado se hizo más popular, estandarizado de un número de 00:07:27.759 --> 00:07:31.609 criterios para la combinación de cifrado y Mac activado. Y esos fueron incluso 00:07:31.609 --> 00:07:35.978 estandarizado por el Instituto Nacional de estándares. Por lo que sólo me va a mencionar tres 00:07:35.978 --> 00:07:41.031 de estas normas. Dos de ellos fueron estandarizados por el NIST. Y estos son 00:07:41.031 --> 00:07:46.138 llamado Galois modo de contador y contador CBC. Y así que Permítanme explicar lo que hacen. 00:07:46.138 --> 00:07:51.245 Modo de contador de Galois básicamente utiliza cifrado de modo de contador, por lo tanto un contador aleatorio 00:07:51.245 --> 00:07:56.164 modo con una MAC Carter-Wagmon, por lo que un hecho Carter Wagmon Mac. Y la forma del 00:07:56.164 --> 00:08:01.146 Carter Wagmon MAC funciona en GCM es básicamente es una función de hash del mensaje 00:08:01.146 --> 00:08:06.311 está siendo MACed. Y, a continuación, el resultado se encriptan usando un PRF. Ahora esta hash 00:08:06.311 --> 00:08:11.562 función de GCM ya es bastante rápido hasta el punto donde el grueso de la marcha 00:08:11.562 --> 00:08:15.845 tiempo de GCM está dominada por el cifrado de modo de contador y incluso hizo más 00:08:15.845 --> 00:08:22.371 en Intel introduce una instrucción especial PCLMULQDQ específicamente 00:08:22.371 --> 00:08:27.432 diseñado para el propósito de hacer la función de hash en ejecución GCM tan rápido como 00:08:27.432 --> 00:08:32.950 posible. Ahora CCM Com módem es otra perdida estándar utiliza un Mac de CBC. Y 00:08:32.950 --> 00:08:37.276 a continuación, cifrado de modo de contador. Así que este mecanismo, usted sabe, esto utiliza MAC, entonces 00:08:37.276 --> 00:08:40.906 cifrar, como SSL. Así que esto realmente no es la manera recomendada de hacerlo 00:08:40.906 --> 00:08:44.023 las cosas, pero contador [inaudible] se utiliza el cifrado de modo. Esto es realmente un 00:08:44.023 --> 00:08:47.945 mecanismo de cifrado perfectamente bien. Una cosa que me gustaría señalar sobre 00:08:47.945 --> 00:08:53.799 MCC, es que todo se basa en AES. Observará que está usando AES para el CBC 00:08:53.799 --> 00:08:58.778 MAC y lo está usando AES para el cifrado de modo de contador. Y como resultado, puede CCM 00:08:58.778 --> 00:09:03.084 aplicarse con relativamente poco código. ?Hacer todo lo que necesita es un motor AES 00:09:03.084 --> 00:09:08.343 y nada más. Debido a esto, CCM realmente fue aprobado por la Wi-Fi 00:09:08.343 --> 00:09:13.963 Alianza, y de hecho, probablemente utilizas CCM diariamente si utilizas 00:09:13.963 --> 00:09:19.093 cifrado Wi-Fi, 80211I. A continuación, utiliza básicamente ccm cifrar el tráfico 00:09:19.093 --> 00:09:23.450 entre el portátil y el punto de acceso. Hay otro modo llamado un eax que 00:09:23.450 --> 00:09:28.922 utiliza cifrado de modo de contador y, a continuación, cmac. Por lo tanto, otra vez notará cifrar y mac 00:09:28.922 --> 00:09:31.906 y eso es una aleta, otro modo fino a utilizar. Haremos una comparación de todos estos 00:09:31.906 --> 00:09:36.806 modos en tan sólo un minuto. Ahora quisiera mencionar que en primer lugar, todas estas son 00:09:36.806 --> 00:09:41.190 basado en nonce. En otras palabras, no utilizan ningún aleatoriedad pero tienen como 00:09:41.190 --> 00:09:46.360 entrada un nonce y el nonce tiene que ser único por clave. En otras palabras, como usted 00:09:46.360 --> 00:09:50.600 Recuerde que debe repetir nunca, nunca la nonce común clave par. Pero el 00:09:50.600 --> 00:09:53.851 nonce sí necesitan no ser aleatorio, por lo que es perfectamente bien para utilizar un contador, para 00:09:53.851 --> 00:09:57.520 ejemplo, como un [inaudible]. Y el otro punto importante es que, en realidad, todos 00:09:57.520 --> 00:10:01.384 Estos modos son lo que denomina cifrado autenticado con asociados 00:10:01.384 --> 00:10:04.936 datos. Se trata de una extensión de cifrado autenticado, pero que viene 00:10:04.936 --> 00:10:10.884 hasta muy a menudo en protocolos de red. Así que la idea entre AEAD. Es que, de hecho, 00:10:10.884 --> 00:10:15.223 el mensaje siempre es que el modo de cifrado no está pensado para ser plenamente 00:10:15.223 --> 00:10:19.924 cifrado. Sólo una parte del mensaje pretende ser cifrada, pero todos los 00:10:19.924 --> 00:10:24.157 mensaje pretende ser autenticado. Un buen ejemplo de esto es un paquete de red. 00:10:24.157 --> 00:10:29.408 Piensa como un paquete ip donde hay un encabezado. Y, a continuación, hay una carga y 00:10:29.408 --> 00:10:33.157 normalmente es el encabezado no va a ser codificado. Por ejemplo, podría el encabezado 00:10:33.157 --> 00:10:36.905 contener el destino del paquete, pero entonces el encabezado había mejor no 00:10:36.905 --> 00:10:40.950 enrutadores cifrados del camino no saben dónde enrutar el paquete. 00:10:40.950 --> 00:10:45.225 Y por lo tanto, normalmente se envía el encabezado de la clara, que la carga, por supuesto, es 00:10:45.225 --> 00:10:49.500 siempre cifrada, pero qué gustaría hacer es tener el encabezado de ser autenticado. 00:10:49.500 --> 00:10:55.907 No cifrados por autenticado. Esto es exactamente lo que estos modos AEAD, do. Ellos 00:10:55.907 --> 00:11:00.033 será autenticar el encabezado y, a continuación, cifre la carga. Pero el encabezado y 00:11:00.033 --> 00:11:04.177 la carga están enlazados juntos en la autenticación para que la autenticación no se puede 00:11:04.177 --> 00:11:07.803 realmente estar separados. Así que esto no es difícil de hacer. Lo que sucede en estos 00:11:07.803 --> 00:11:14.170 tres modos de GCM, CCM y EAX, básicamente el MAC se aplica a los datos de todos. Pero 00:11:14.170 --> 00:11:18.852 el cifrado se aplica solamente a la parte de los datos que necesita ser codificado. Por lo tanto 00:11:18.852 --> 00:11:22.983 Quería mostrarles lo que un cifrado de API [inaudible] autenticado con 00:11:22.983 --> 00:11:28.716 asociados parecen esquemas de cifrado de datos. Así que aquí es lo que parece 00:11:28.716 --> 00:11:33.609 [inaudible]. Por ejemplo, esto es, una API para GCM. Así que lo que haces es llamar a la 00:11:33.609 --> 00:11:37.404 a mediados de función para inicializar el cifrado modo y le aviso le darle una clave y 00:11:37.404 --> 00:11:40.609 nonce. El nonce nuevamente, no tiene que ser aleatorio, pero tiene que 00:11:40.609 --> 00:11:44.402 ser único. Y después de la inicialización, sería llamar a esta función de cifrar, donde 00:11:44.402 --> 00:11:48.169 ves que da los datos asociados que se va a ser autenticado, pero 00:11:48.169 --> 00:11:51.794 no cifrada. Se le da los datos, y se va a ser tanto autentica y 00:11:51.794 --> 00:11:55.752 cifrado. Y le da vuelta el texto cifrado completo, que es un cifrado de la 00:11:55.752 --> 00:11:59.582 datos, pero por supuesto no incluye la AAD, porque la AAD es va a ser enviado 00:11:59.582 --> 00:12:04.535 [inaudible]. Así que ahora que comprendemos este modo de cifrar luego MAC, podemos ir 00:12:04.535 --> 00:12:09.951 volver a la definición de MAC seguridad y podemos explicarle algo que podría 00:12:09.951 --> 00:12:13.970 han sido un poco oscuro cuando analizamos esa definición. Así que si te acuerdas, 00:12:13.970 --> 00:12:18.570 uno de los requisitos que siguieron desde nuestra definición de MACs seguros significa que 00:12:18.570 --> 00:12:25.689 dado un mensaje par MAC en un mensaje M, el atacante no puede producir otra etiqueta en 00:12:25.689 --> 00:12:30.386 el mismo mensaje M. En otras palabras, aunque el atacante ya tiene una etiqueta para 00:12:30.386 --> 00:12:34.771 el mensaje M, él shouldn? t ser capaz de producir una nueva etiqueta para el mismo mensaje M. 00:12:34.771 --> 00:12:39.382 Y realmente no está claro, ¿por qué eso importa? A quién le importa si el adversario ya 00:12:39.382 --> 00:12:44.038 ¿tiene una etiqueta en el mensaje de M? ¿A quién le importa si él puede producir otra etiqueta? Así, resulta 00:12:44.038 --> 00:12:48.828 que el MAC no tiene esta propiedad. En otras palabras, dado un mensaje 00:12:48.828 --> 00:12:53.618 Par de MAC, puede producir otra MAC en el mismo mensaje y, a continuación, sería MAC 00:12:53.618 --> 00:12:58.694 como resultado un modo inseguro de MAC cifrados. Y por lo tanto, si queremos que nuestro MAC cifrado a 00:12:58.694 --> 00:13:03.961 integridad self-adjust, es crucial que nuestra seguridad MAC implicaría una fuerte 00:13:03.961 --> 00:13:08.910 noción de seguridad, que, por supuesto, no es porque hemos definido correctamente. 00:13:08.910 --> 00:13:13.613 Así que vamos a ver lo que podría salir mal, si, de hecho, era fácil producir este tipo de 00:13:13.613 --> 00:13:18.081 falsificación. Por lo tanto lo que haremos es te voy a mostrar un ataque de texto cifrado elegido en el 00:13:18.081 --> 00:13:22.784 resultando cifrar, luego sistema Mac. Y dado que el sistema tiene un texto cifrado elegido 00:13:22.784 --> 00:13:27.193 ataque, significa necesariamente que no proporciona un autenticado 00:13:27.193 --> 00:13:31.458 cifrado. Así que vamos a ver. Así que empieza a gonnna del adversario mediante el envío de dos 00:13:31.458 --> 00:13:35.861 mensajes, M0 y M1. Y él se va a recibir, como de costumbre, el cifrado de una 00:13:35.861 --> 00:13:39.522 de ellos, el cifrado de M0 o el cifrado de M1. Y ya que estamos 00:13:39.522 --> 00:13:44.907 uso de cifrar, el Mac, el adversario recibe un texto cifrado llamaremos a una c 00:13:44.907 --> 00:13:49.883 cero y Mac en el texto cifrado c cero. Pues ahora hemos dicho que el mac de 00:13:49.883 --> 00:13:53.827 un mensaje el adversario puede producir otro mac en el mismo mensaje. Y qué 00:13:53.827 --> 00:13:57.994 él es va a hacer es que se va a producir otro mac en el mensaje de CO. Ahora él tiene 00:13:57.994 --> 00:14:03.532 un nuevo cypher texto, CO, T prime, que es un texto de cypher perfectamente válida. Primo de t es un 00:14:03.532 --> 00:14:09.558 mac válida de CO. Por lo tanto, el adversario ahora puede enviar una consulta de texto elegido cypher 00:14:09.558 --> 00:14:14.492 C prime y esto es un texto válido cypher elegido consulta porque es diferente 00:14:14.492 --> 00:14:19.288 de C. Es un nuevo texto de cifrado. El challenger pobre ahora se ve obligado a descifrar esto 00:14:19.288 --> 00:14:23.278 primer texto c de cifrado por lo que él va a volver a enviar el descifrado de c prime. Es un 00:14:23.278 --> 00:14:29.093 el texto cifrado válidos, por tanto, el descifrado de prime c es el mensaje MB pero ahora el 00:14:29.093 --> 00:14:32.318 atacante sólo aprendió el valor de b porque él puede probar si MB es igual a 00:14:32.318 --> 00:14:37.371 M0 o MB es igual al M1. Como resultado de él sólo puede salida b y saca ventaja 00:14:37.371 --> 00:14:43.468 uno. En la alimentación del sistema. Y así otra vez si no implica nuestra seguridad mac 00:14:43.468 --> 00:14:48.471 Esta propiedad aquí. Entonces, habrá un elegido [inaudible] un cifrar en mac. Y 00:14:48.471 --> 00:14:53.181 por lo tanto, no sería seguro. Por lo tanto el hecho de que definimos seguridad Mac correctamente 00:14:53.181 --> 00:14:57.241 significa que cifrar y Mac realmente proporcionan cifrado autenticado. Y 00:14:57.241 --> 00:15:01.728 a lo largo de todas las Macs que hablamos realmente satisfacer esta noción fuerte de 00:15:01.728 --> 00:15:06.146 unforgeability. Así, curiosamente, esto no es el final de la historia. Por lo tanto, como dijimos 00:15:06.146 --> 00:15:10.385 antes de que se introdujo el concepto de cifrado autenticado todos era 00:15:10.385 --> 00:15:15.295 sólo la combinación de macs y cifrado de diversas maneras con la esperanza de lograr 00:15:15.295 --> 00:15:19.201 algunos, algunos cifrado autenticado. Después de la noción de cifrado autenticado 00:15:19.201 --> 00:15:23.553 fue formalizado y rigurosa un poco comenzó arañando sus cabezas y dijo: 00:15:23.553 --> 00:15:28.130 bueno, espere un minuto. Quizás logremos cifrado autenticado más eficiente 00:15:28.130 --> 00:15:32.722 que mediante la combinación de un mac y un esquema de cifrado. De hecho, si uno piensa en cómo 00:15:32.722 --> 00:15:37.366 Esta combinación de MAC y encriptación funciona, digamos que combinamos a modo de contador 00:15:37.366 --> 00:15:42.134 con CMAC, entonces para cada bloque de texto, en primer lugar tiene que utilizar 00:15:42.134 --> 00:15:46.419 el cifrado por bloques a modo de contador y, a continuación, tiene que utilizar para el cifrado por bloques 00:15:46.419 --> 00:15:51.357 una vez más, para el CBC-MAC. Esto significa que si usted combina CPA seguro cifrado con una 00:15:51.357 --> 00:15:55.943 MAC, para cada bloque de texto, tienes que evaluar dos veces, el cifrado por bloques 00:15:55.943 --> 00:16:00.535 una vez para MAC y una vez en el esquema de cifrado. Así que la pregunta natural 00:16:00.535 --> 00:16:05.396 fue, nosotros podemos construir un esquema de cifrado autenticado directamente desde un PRP 00:16:05.396 --> 00:16:10.345 tal que tendríamos que evaluar sólo el PRP una vez por bloque. Y resulta 00:16:10.345 --> 00:16:14.117 la respuesta es sí y hay estas hermosa construcción llamada TOC, que 00:16:14.117 --> 00:16:18.343 muy bonita hace todo lo que desee y es mucho más rápido que las construcciones que son 00:16:18.343 --> 00:16:22.467 construido por separado a partir de un cifrado y un Mac. Así que escribí abajo, tipo de un esquema 00:16:22.467 --> 00:16:26.290 de OCD. No quiero explicar en detalle. Sólo un poco a explicarlo en un 00:16:26.290 --> 00:16:30.025 alto nivel. Así que aquí tenemos a la entrada de texto, aquí en la parte superior. Y usted 00:16:30.025 --> 00:16:34.540 Observe que, en primer lugar, TOC es paralyzable, completamente paralyzable. Por lo tanto 00:16:34.540 --> 00:16:39.700 cada bloque puede cifrarse por separado de cada otro bloque. La otra cosa que 00:16:39.700 --> 00:16:44.338 aviso es que como lo prometido es deuda, sólo evaluar su cifrado en bloque una vez por la llanura 00:16:44.338 --> 00:16:49.318 bloque de texto. Y, a continuación, se evalúa una vez más al final para construir su 00:16:49.318 --> 00:16:53.887 ficha autenticación y, a continuación, la sobrecarga de la OCB más allá de sólo una cifra de bloque es 00:16:53.887 --> 00:16:58.749 mínima. Todo lo que tienes que hacer es evaluar una determinada función muy simple clave que la 00:16:58.749 --> 00:17:02.844 no [inaudible] en el p observará, la clave entra en esta p y, a continuación, hay una 00:17:02.844 --> 00:17:08.238 contador de bloque que va en este p. Tan sólo evaluar esta función P, dos veces 00:17:08.238 --> 00:17:12.748 para cada bloque y el resultado antes y después de utilizar cifrado XOR el 00:17:12.748 --> 00:17:17.553 cypher de bloque y eso es todo. Eso es todo lo que tienes que hacer y, a continuación, obtendrá una muy rápida 00:17:17.553 --> 00:17:22.241 y eficiente esquema de cifrado autentica construido a partir de una cifra de bloque. Así OCB 00:17:22.241 --> 00:17:26.065 realmente tiene un teorema de seguridad agradable asociado y voy a punto 00:17:26.065 --> 00:17:29.567 un libro sobre OCB cuando lleguemos al final de este módulo donde te enumero algunas más 00:17:29.567 --> 00:17:34.457 lectura de documentos que pueden echar un vistazo. Por lo que podría estar preguntándose si la OCB es así 00:17:34.457 --> 00:17:40.168 mucho mejor que todo lo que has visto hasta ahora todas estas tres normas MCC, GCM y 00:17:40.168 --> 00:17:46.037 EAX ¿por qué no utilizan OCB o por qué no OCB el estándar? Y la respuesta es un 00:17:46.037 --> 00:17:50.729 poco triste. La CBC de respuesta primaria [inaudible] no está siendo utilizada es realmente porque 00:17:50.729 --> 00:17:54.567 de varias patentes. Y sólo podrá dejarlo en ese. Para concluir esta sección I 00:17:54.567 --> 00:17:58.216 quería mostrarle algunos números de rendimiento. Así que aquí a la derecha aparece 00:17:58.216 --> 00:18:02.368 números de rendimiento de modos que no debería estar utilizando. Así que esto es para 00:18:02.368 --> 00:18:07.879 modo de contador aleatorios y esto es para CBC aleatorio. Y se puede ver también el 00:18:07.879 --> 00:18:12.460 rendimiento de CBC MAC es básicamente el mismo que el rendimiento de cifrado CBC. 00:18:12.460 --> 00:18:16.221 Muy bien. Y aquí están los modos de cifrado autenticado, por lo que estos son los 00:18:16.221 --> 00:18:20.083 que se supone que utilizando, estos se supone no estar usando en su 00:18:20.083 --> 00:18:23.795 derecho propio. Estos dos nunca debe utilizar estos dos porque ellos sólo 00:18:23.795 --> 00:18:27.858 proporcionar seguridad habilitados en la CPA, realmente no proporcionan seguridad contra activo 00:18:27.858 --> 00:18:31.669 ataques. Sólo se supone utilizar cifrado autenticado para el cifrado. 00:18:31.669 --> 00:18:35.509 Y así se trata de sus números de rendimiento para las tres normas. Y me permito recordar 00:18:35.509 --> 00:18:40.109 básicamente lo GCM utiliza un hash muy rápido. Y, a continuación, utiliza el modo de contador para 00:18:40.109 --> 00:18:43.770 cifrado real. Y se puede ver que es la sobrecarga de GCM a modo de contador 00:18:43.770 --> 00:18:49.554 relativamente pequeño. CCM y EAX usan un sitio de bloque para una codificación base y una 00:18:49.554 --> 00:18:54.627 sitio de bloque para mac base. Y como resultado su sobre dos veces como lento como contador 00:18:54.627 --> 00:18:59.196 modos. Se ve que la OCB es realmente el más rápido de estos, principalmente porque se 00:18:59.196 --> 00:19:03.820 sólo utilice el cifrado de bloque por bloque de mensaje. Por lo tanto basado en estas rendimiento 00:19:03.820 --> 00:19:08.328 números, uno pensaría que el GCM es exactamente el modo correcto para usar siempre. Pero 00:19:08.328 --> 00:19:12.659 resulta que si estás en el hardware de espacio limitado, GCM no es ideal. 00:19:12.659 --> 00:19:16.709 Sobre todo porque su aplicación requiere código mayor que los otros dos 00:19:16.709 --> 00:19:21.323 modos. Sin embargo, como ya he dicho, Intel específicamente agrega instrucciones para acelerar 00:19:21.323 --> 00:19:26.064 modo de GCM. Y como resultado, aplicación de GCM sobre una arquitectura [inaudible] toma 00:19:26.064 --> 00:19:30.315 muy poco código. Pero en otras plataformas de hardware, visto en tarjetas inteligentes u otros 00:19:30.315 --> 00:19:34.745 entornos limitados, los sitios de código para implementar GCM sería considerablemente 00:19:34.745 --> 00:19:39.387 más grande que los otros dos meses. Pero si el tamaño del código no es una restricción entonces gcm 00:19:39.387 --> 00:19:43.928 es el modo correcto de utilizar. Para resumir este segmento quiere decir que uno más 00:19:43.928 --> 00:19:48.267 tiempo cuando desea cifrar mensajes que tienes que utilizar una autenticación 00:19:48.267 --> 00:19:52.716 modo de cifrado y la manera recomendada de hacerlo es utilizar uno de los estándares, 00:19:52.716 --> 00:19:57.037 principalmente uno de estos tres modos para proporcionar autenticación cifrado. No 00:19:57.037 --> 00:19:59.846 aplicar el esquema de cifrado, en otra palabras generar, implementar cifrar 00:19:59.846 --> 00:20:05.842 y mac usted mismo. Sólo tiene que utilizar uno de estos tres estándares. Muchos cifrar las bibliotecas 00:20:05.842 --> 00:20:10.513 ahora prever estos tres modos de ABI estándar y estos son los de uno que debe 00:20:10.513 --> 00:20:14.347 estar utilizando y nada más. En el siguiente segmento vamos a ver qué otra cosa puede 00:20:14.347 --> 00:20:17.500 salir mal cuando se intenta implementar un cifrado sonicated.