1 00:00:00,000 --> 00:00:03,583 La semana pasada, aprendimos la teoría numérica necesaria para la criptografía de clave pública. 2 00:00:03,583 --> 00:00:07,166 Esta semana vamos a poner a trabajar ese conocimiento y vamos a construir varios 3 00:00:07,166 --> 00:00:10,889 esquemas de criptografía de clave pública seguros. Pero primero es necesario definir qué es 4 00:00:10,889 --> 00:00:14,565 la criptografía de clave pública y qué significa que la criptografía de clave pública sea 5 00:00:14,565 --> 00:00:18,241 segura. Así, permitidme recordaros que en un esquema de criptografía de clave pública hay un 6 00:00:18,241 --> 00:00:21,778 algoritmo de encriptación, normalmente denotado como E, y un algoritmo de 7 00:00:21,778 --> 00:00:25,361 desencriptado que denotamos como D. En cualquier caso, aquí el algoritmo de encriptación usa una 8 00:00:25,361 --> 00:00:29,477 clave pública, mientras que el de desencriptado usa una clave privada. Este par se denomina 9 00:00:29,477 --> 00:00:34,356 par de claves. Y la clave pública se utiliza para encriptar mensajes mientras que la clave privada 10 00:00:34,356 --> 00:00:39,002 se utiliza para desencriptarlos. Por tanto, en este caso, un mensaje "m" se encripta usando 11 00:00:39,002 --> 00:00:43,880 la clave pública y lo que se obtiene de ello es el texto cifrado, "c". Y, de forma similar, 12 00:00:43,880 --> 00:00:48,643 el texto cifrado se usa para alimentar el algoritmo de desencriptado usando la clave privada y lo que 13 00:00:48,643 --> 00:00:53,577 se obtiene del algoritmo de desencriptado es el mensaje original, "m". La encripción de clave 14 00:00:53,577 --> 00:00:57,989 pública tiene muchas aplicaciones. La semana pasada vimos la aplicación clásica, el 15 00:00:57,989 --> 00:01:02,455 establecimiento de sesión, esto es, intercambio de claves. Y por ahora vamos a limitarnos al intercambio de 16 00:01:02,455 --> 00:01:06,867 claves que sea seguro sólo contra escucha. Y, si recordáis cómo funciona el protocolo, 17 00:01:06,867 --> 00:01:11,227 básicamente Alice, lo que ella hará es generar un par de claves pública y privada. 18 00:01:11,227 --> 00:01:15,546 Enviará la clave pública a Bob. Bob generará un valor aleatorio "x", que 19 00:01:15,546 --> 00:01:20,136 servirá como su secreto compartido y, entonces, envía "x" encriptada a Alice, 20 00:01:20,136 --> 00:01:24,904 encriptada con su clave pública [de Alice]. Alice puede desencriptar, recuperar "x" y ahora ambos 21 00:01:24,904 --> 00:01:29,554 disponen de este secreto compartido, "x", que pueden utilizar para comunicarse de forma segura 22 00:01:29,554 --> 00:01:34,143 entre ellos. El atacante, por supuesto, todo lo que puede ver es la clave pública, la 23 00:01:34,143 --> 00:01:38,972 encriptación de "x" con la clave pública, de la cual no debería poder obtener ninguna 24 00:01:38,972 --> 00:01:43,800 información sobre "x". Vamos a definir esto de forma más precisa para entender 25 00:01:43,800 --> 00:01:48,507 qué significa no ser capaz de averiguar nada sobre "x". La criptografía pública, 26 00:01:48,507 --> 00:01:52,522 de hecho, tiene muchas otras aplicaciones. Por ejemplo, es muy útil en 27 00:01:52,522 --> 00:01:57,235 aplicaciones no interactivas. Así, pensad en un sistema de correo electrónico, por ejemplo. Aquí, Bob 28 00:01:57,235 --> 00:02:01,716 quiere enviar correo a Alice y, cuando Bob envía el correo, el correo pasa de 29 00:02:01,716 --> 00:02:06,603 agente de transporte a agente de transporte hasta que llega a Alice, momento en el que Alice deberá 30 00:02:06,603 --> 00:02:10,502 desencrciptar. La forma en que el sistema de correo está implementado está diseñada según una 31 00:02:10,502 --> 00:02:15,045 configuración no interactiva en la que Bob envía el correo y entonces Alice se supone que lo 32 00:02:15,045 --> 00:02:19,195 recibirá. Y Alice no debería tener que comunicarse con Bob a fin de desencriptar 33 00:02:19,195 --> 00:02:23,502 el correo. Por tanto, en este caso, a causa de la falta de interactividad, no existe la oportunidad 34 00:02:23,502 --> 00:02:27,705 de establecer un secreto compartido entre Alice y Bob. Por tanto, en este caso, lo que 35 00:02:27,705 --> 00:02:32,169 ocurrirá es que Bob, básicamente, enviará el correo encriptado utilizando la clave pública de 36 00:02:32,169 --> 00:02:36,571 Alice. Del mismo modo que él envía el correo, cualquiera en el mundo puede enviar el correo encriptado a 37 00:02:36,571 --> 00:02:41,103 Alice, encriptado usando su clave pública [de Alice]. Cuando Alice recibe este correo, ella utiliza 38 00:02:41,103 --> 00:02:45,748 su clave privada para desencriptar el texto cifrado y recuperar el mensaje en texto llano. 39 00:02:45,748 --> 00:02:50,507 Por supuesto, el inconveniente en un sistema como éste es que, de hecho, Bob necesita, de algún modo, 40 00:02:50,507 --> 00:02:54,804 obtener la clave pública de Alice. Así, por ahora, vamos a asumir, simplemente, que Bob ya dispone 41 00:02:54,804 --> 00:02:58,297 de la clave pública de Alice, pero más adelante, cuando hablemos sobre firmas digitales, 42 00:02:58,297 --> 00:03:02,457 veremos cómo se puede hacer esto de forma muy eficiente utilizando lo que se 43 00:03:02,457 --> 00:03:06,823 llama gestión de clave pública y, como ya he dicho, volveremos a ello más adelante. 44 00:03:06,823 --> 00:03:10,931 Lo más importante que quiero que recordéis es que la criptografía de clave pública se 45 00:03:10,931 --> 00:03:14,578 utiliza para establecer sesiones. Esto es muy común en la web, donde la criptografía de 46 00:03:14,578 --> 00:03:18,840 clave pública se utiliza para establecer una clave segura entre un navegador web y un servidor web. 47 00:03:18,840 --> 00:03:22,898 Y la criptografía de clave pública también es muy útil para aplicaciones no interactivas, 48 00:03:22,898 --> 00:03:26,390 en las que cualquiera en el mundo, de forma no interactiva, necesita enviar un mensaje 49 00:03:26,390 --> 00:03:30,653 a Alice, pudiendo encriptar el mensaje usando la clave pública de Alice y Alice puede desencriptar 50 00:03:30,653 --> 00:03:36,105 y recuperar el texto llano. Por tanto, permitidme que os recuerde con algo más de detalle qué 51 00:03:36,105 --> 00:03:40,347 es un sistema de criptografía de clave pública. Bien, consiste en tres algoritmos, G, E y D. 52 00:03:40,347 --> 00:03:44,431 G se denomina algoritmo de generación de claves. Básicamente lo que hace es 53 00:03:44,431 --> 00:03:48,672 generar este par de claves, la clave pública y la clave privada. Tal como se indica aquí, G no usa 54 00:03:48,672 --> 00:03:53,018 argumentos, pero en la vida real, G realmente usa un argumento denominado el parámetro 55 00:03:53,018 --> 00:03:57,260 de seguridad, que especifica el tamaño de las claves que se generan con este algoritmo de 56 00:03:57,260 --> 00:04:01,731 generación de claves. Luego está este algoritmo de encriptación, como es habitual, que usa una 57 00:04:01,731 --> 00:04:06,051 clave pública y un mensaje y genera un texto cifrado, y un algoritmo de desencriptado que 58 00:04:06,051 --> 00:04:10,530 usa la clave privada correspondiente y un texto cifrado y genera el correspondiente 59 00:04:10,530 --> 00:04:14,955 mensaje. Como siempre, para [la condición de] consistencia, diremos que si encriptamos un mensaje 60 00:04:14,955 --> 00:04:19,380 según una determinada clave pública y luego lo desencriptamos con la clave privada correspondiente, 61 00:04:19,380 --> 00:04:23,852 deberemos obtener de nuevo el mensaje original. Ahora, ¿qué significa para un sistema criptográfico de clave pública 62 00:04:23,852 --> 00:04:27,913 que sea seguro? Voy a empezar definiendo seguridad contra escucha 63 00:04:27,913 --> 00:04:32,002 y luego definiremos la seguridad contra ataques activos. La forma de 64 00:04:32,002 --> 00:04:36,237 definir seguridad contra escucha es muy similar a la del caso simétrico que hemos 65 00:04:36,237 --> 00:04:40,626 visto la semana pasada, así que vamos a pasar por ello rápidamente, sólo como repaso. 66 00:04:40,626 --> 00:04:44,808 Básicamente, el juego de ataque se define como sigue. Definimos estos dos experimentos, 67 00:04:44,808 --> 00:04:49,249 experimento cero y experimento uno. En cada experimento el retador generará 68 00:04:49,249 --> 00:04:52,965 un par de claves pública y privada. Le dará la clave pública 69 00:04:52,965 --> 00:04:57,342 al adversario. El adversario emitirá dos mensajes, m0 y m1 de la misma 70 00:04:57,342 --> 00:05:01,663 longitud y lo que recibe es la encripción de m0 o la 71 00:05:01,663 --> 00:05:06,039 encripción de m1. En el experimento cero obtiene la encripción de m0. En el experimento 72 00:05:06,039 --> 00:05:10,748 uno obtiene la encripción de m1. Y entonces el adversario se supone de debe indicar cuál 73 00:05:10,748 --> 00:05:15,240 ha recibido, ¿Ha recibido la encripción de m0 o ha recibido la encripción de m1? Así, 74 00:05:15,240 --> 00:05:19,676 en este juego, el atacante sólo obtiene un texto cifrado. Esto corresponde a un ataque 75 00:05:19,676 --> 00:05:24,226 de escucha en el que se limita a "escuchar" dicho texto cifrado "c". Y ahora 76 00:05:24,226 --> 00:05:28,719 su objetivo es determinar si el texto cifrado "c" es la encripción de m0 o m1. No se 77 00:05:28,719 --> 00:05:34,221 permite manipular el texto cifrado "c" por ahora. Y, como es costumbre, diremos que el 78 00:05:34,221 --> 00:05:38,206 esquema de criptografía de clave pública es semánticamente seguro si el atacante no puede 79 00:05:38,206 --> 00:05:42,085 distinguir el experimento cero del experimento uno. En otras palabras, no puede 80 00:05:42,085 --> 00:05:47,757 diferenciar si recibió la encripción de m0 o la encripción de m1. Antes de pasar 81 00:05:47,757 --> 00:05:52,311 a los ataques activos, quiero mencionar una relación inmediata entre la definición que acabamos 82 00:05:52,311 --> 00:05:56,105 de ver y la definición de seguridad de escucha para cifrado simétrico. 83 00:05:56,105 --> 00:06:00,438 Si lo recordáis, cuando hablamos sobre seguridad de escucha para cifrado 84 00:06:00,438 --> 00:06:04,771 simétrico, distinguíamos entre el caso en que la clave se usaba una vez y el caso en que la 85 00:06:04,771 --> 00:06:08,998 clave se usaba varias veces. Y, de hecho, vimos que existe una clara 86 00:06:08,998 --> 00:06:13,357 separación. Por ejemplo, el cuaderno de un solo uso es seguro si la clave se usa para encriptar 87 00:06:13,357 --> 00:06:17,382 un único mensaje, pero es completamente inseguro si la clave se usa para encriptar múltiples 88 00:06:17,382 --> 00:06:21,358 mensajes. Y, de hecho, teníamos dos definiciones diferentes, si os acordáis, teníamos una 89 00:06:21,358 --> 00:06:25,383 definición para seguridad de un solo uso y una definición diferente, que era más 90 00:06:25,383 --> 00:06:29,700 exigente, cuando la clave se usaba varias veces. La definición que os he mostrado en 91 00:06:29,700 --> 00:06:34,043 la transparencia anterior es muy similar a la definición de seguridad de un solo uso para 92 00:06:34,043 --> 00:06:38,499 cifras simétricas. Y, de hecho, resulta que para la criptografía de clave pública, si un 93 00:06:38,499 --> 00:06:43,124 sistema es seguro en el caso de un solo uso de la clave, en cierto sentido, también es seguro para uso múltiple de 94 00:06:43,124 --> 00:06:47,929 la clave. En otras palabras, no es necesario proporcionar explícitamente al atacante la habilidad 95 00:06:47,929 --> 00:06:53,171 para requerir encripciones de mensajes de su elección, ya que puede crear encripciones 96 00:06:53,171 --> 00:06:57,870 por si mismo. Dispone de la clave pública y, por tanto, puede 97 00:06:57,870 --> 00:07:04,672 por si mismo encriptar cualquier mensaje que desee. Como resultado, cualquier par de claves pública y privada 98 00:07:04,672 --> 00:07:09,289 de algún modo inherentemente se usan para encriptar varios mensajes ya que el atacante 99 00:07:09,289 --> 00:07:13,905 podría encriptar muchos, muchos mensajes de su elección usando la clave 100 00:07:13,905 --> 00:07:18,891 pública que le hemos proporcionado en el primer paso. Y así, como resultado, de hecho 101 00:07:18,891 --> 00:07:23,692 la definición de seguridad para un solo uso es suficiente para implicar seguridad de varios usos y 102 00:07:23,692 --> 00:07:28,801 es por ello que nos referimos al concepto como indistinguibilidad bajo un ataque de 103 00:07:28,801 --> 00:07:34,012 texto llano escogido. Así, este es sólo un punto menor para explicar por qué en la configuración de criptografía 104 00:07:34,012 --> 00:07:37,770 de clave pública no necesitamos una definición más compleja para aprehender 105 00:07:37,770 --> 00:07:42,515 la seguridad ante escucha. Ahora que entendemos la seguridad ante escucha, 106 00:07:42,515 --> 00:07:47,343 vamos a ver adversarios mas fuertes que pueden montar ataques activos. Entonces, en 107 00:07:47,343 --> 00:07:51,585 particular, veamos el ejemplo del correo electronico. Así, aquí tenemos a nuestro amigo Bob 108 00:07:51,585 --> 00:07:56,228 que quiere enviar enviar un correo a su amiga Caroline. Y resulta que Caroline tiene una 109 00:07:56,228 --> 00:08:00,699 cuenta en Gmail. Y esto funciona básicamente así, el correo electrónico se envía encriptado al 110 00:08:00,699 --> 00:08:05,514 servidor de Gmail. El servidor de Gmail desencripta el correo electrónico, mira quienes son los 111 00:08:05,514 --> 00:08:09,297 destinatarios y luego, si es que el destinatario es Caroline, 112 00:08:09,297 --> 00:08:13,653 reenvia el correo electrónico a Caroline. Si el destinatario es el atacante, se 113 00:08:13,653 --> 00:08:18,573 lo reenvia al atacante. Esto es similar a cómo trabaja realmente Gmail, 114 00:08:18,573 --> 00:08:23,441 porque el remitente enviaría el correo encriptado sobre SSL al servidor Gmail, 115 00:08:23,441 --> 00:08:28,087 el servidor Gmail terminaría [la sesión] SSL y reenviaría el mensaje a los destinatarios 116 00:08:28,087 --> 00:08:33,081 apropiados. Ahora supongamos que Bob encripta el correo usando un sistema que 117 00:08:33,081 --> 00:08:37,764 permita al adversario manipular el texto cifrado sin ser detectado. Por 118 00:08:37,764 --> 00:08:42,387 ejemplo, imaginad que el correo está encriptado usando el modo contador o 119 00:08:42,387 --> 00:08:47,070 similar. Entonces, cuando el atacante intercepta este correo puede cambiar el destinatario 120 00:08:47,070 --> 00:08:50,732 de forma que ahora el destinatario sea attacker@gmail.com. Y sabemos que, para el 121 00:08:50,732 --> 00:08:55,415 modo contador, por ejemplo. esto es muy fácil de hacer. El atacante sabe que el 122 00:08:55,415 --> 00:09:00,278 correo está dirigido a Caroline, él está sólo interesado en el cuerpo del correo. Por tanto, puede 123 00:09:00,278 --> 00:09:04,226 fácilmente cambiar el destinatario del correo a attacker@gmail.com y ahora, cuando el servidor 124 00:09:04,226 --> 00:09:08,129 recibe el correo, lo desencriptará, verá que el destinatario se supone que es el 125 00:09:08,129 --> 00:09:12,033 atacante y reenviará el cuerpo del mensaje al atacante. Ahora el atacante ha podido 126 00:09:12,033 --> 00:09:16,022 leer el cuerpo del mensaje que estaba destinado a Caroline. Así, 127 00:09:16,022 --> 00:09:21,198 este es un ejemplo clásico de ataque activo, y podéis ver lo que el atacante ha conseguido: 128 00:09:21,198 --> 00:09:26,174 puede desencriptar cualquier texto cifrado en el que el destinatario sea "to:attacker", 129 00:09:26,174 --> 00:09:31,548 esto es, un texto cifrado en el que el texto llano empiece por "to:attacker". Así, nuestro objetivo es empiece 130 00:09:31,548 --> 00:09:36,657 diseñar sistemas de clave pública que sean seguros incluso si el atacante puede manipular 131 00:09:36,657 --> 00:09:42,999 el texto cifrado y, posiblemente, desencriptar algunos textos cifrados. Y, de nuevo, quiero 132 00:09:42,999 --> 00:09:47,612 enfatizar que aquí el objetivo del atacante es obtener el cuerpo del mensaje. El atacante 133 00:09:47,612 --> 00:09:52,055 ya sabía que el correo estaba destinado a Caroline. Y todo lo que él tenía que hacer 134 00:09:52,055 --> 00:09:56,863 era cambiar el destinatario. Así, este ataque mediante manipulación motiva la 135 00:09:56,863 --> 00:10:01,620 definición de seguridad de texto cifrado escogido. y, de hecho, esta es la noción estándar de 136 00:10:01,620 --> 00:10:07,462 seguridad para la criptografía de clave pública. Así, permitidme explicaros cómo funciona el esquema del 137 00:10:07,462 --> 00:10:11,899 ataque. Como ya dije, nuestro objetivo es construir sistemas que sean seguros bajo esta noción tan 138 00:10:11,899 --> 00:10:15,756 conservadora de encripción. Así, tenemos un esquema de encripción G, E, D y digamos que 139 00:10:15,756 --> 00:10:20,140 está definido sobre nuestro espacio de mensajes y de textos cifrados M, C. Como es habitual, vamos 140 00:10:20,140 --> 00:10:24,313 a definir dos experimentos, experimento cero y experimento uno. Así, aquí "b" indica si 141 00:10:24,313 --> 00:10:28,222 el retador está implementando el experimento cero el el experimento 142 00:10:28,222 --> 00:10:32,659 uno. El retador empieza generando una clave pública y una clave privada y entonces proporciona 143 00:10:32,659 --> 00:10:37,254 la clave privada al adversario. Ahora el adversario puede decir "Bien, aquí hay un puñado de 144 00:10:37,254 --> 00:10:41,611 textos cifrados, por favor desencríptalos por mí." Así que el adversario envía el texto cifrado 145 00:10:41,611 --> 00:10:46,452 c1 y obtiene la desencripción del texto cifrado c1, esto es, m1. Y lo repite 146 00:10:46,452 --> 00:10:51,414 una y otra vez, de forma que envía el texto cifrado c2 y obtiene la desencripción, 147 00:10:51,414 --> 00:10:56,195 que es m2, el texto cifrado c3 y lo obtiene desencriptado, m3, y así en adelante. 148 00:10:56,195 --> 00:11:00,188 Finalmente, el adversario dice: "Esta fase de interrogación ha acabado" y ahora 149 00:11:00,188 --> 00:11:04,485 remite básicamente dos mensajes de la misma longitud, m0 y m1, como es habitual, y 150 00:11:04,485 --> 00:11:08,820 recibe en respuesta el texto cifrado de desafío, "c", que es la encriptación de m0 o 151 00:11:08,820 --> 00:11:13,052 la encriptación de m1, dependiendo de si estamos en el experimento cero o el 152 00:11:13,052 --> 00:11:17,003 experimento uno. Ahora el adversario puede continuar enviando solicitudes de texto 153 00:11:17,003 --> 00:11:21,063 cifrado. Así, puede continuar remitiendo solicitudes de desencriptado. Así, el remite 154 00:11:21,063 --> 00:11:25,447 un texto cifrado y recibe el texto desencriptado, pero, por supuesto, ahora tiene que haver una 155 00:11:25,447 --> 00:11:29,994 limitación. Si el atacante pudiese solicitar textos cifrados arbitrarios de su elección, 156 00:11:29,994 --> 00:11:34,270 por supuesto que podría romper el desafío. Lo único que tendría que hacer es remitir al 157 00:11:34,270 --> 00:11:38,506 retador el texto cifrado "c" como una solicitud de desencriptado y entonces se le diría si en la 158 00:11:38,506 --> 00:11:42,665 fase de desafío se le ha dado la encriptación de m0 o la encriptación de m1. 159 00:11:42,665 --> 00:11:46,825 Como resultado, ponemos la siguiente limitación, que dice que él puede de hecho enviar cualquier 160 00:11:46,825 --> 00:11:51,031 texto cifrado de su elección, excepto el texto cifrado del desafío. Así, el atacante 161 00:11:51,031 --> 00:11:55,034 podrá solicitar el desencriptado de cualquier texto cifrado de su elección que no sea el 162 00:11:55,034 --> 00:11:59,297 texto cifrado del desafío. Y, a pesar de que se le hayan dado todos esos textos desencriptados, a pesar de todo 163 00:11:59,297 --> 00:12:03,196 no debería ser capaz de decir si ha recibido la encriptación de m0 o la 164 00:12:03,196 --> 00:12:09,212 encriptación de m1. Por tanto, daros cuenta de que se trata de una definición muy conservadora. Proporciona 165 00:12:09,212 --> 00:12:14,113 al atacante más poder del que vimos en la transparencia anterior. En la transparencia anterior, 166 00:12:14,113 --> 00:12:18,710 el atacante sólo podía desencriptar mensajes si el texto llano empezada con "to:attacker". 167 00:12:18,710 --> 00:12:23,611 Aquí, lo que vemos es que el atacante puede desencriptar cualquier texto cifrado de su elección, 168 00:12:23,611 --> 00:12:29,717 siempre se que sea distinto del texto cifrado del desafío, "c". ¿De acuerdo? Y entonces su 169 00:12:29,717 --> 00:12:34,094 objetivo es decir si el texto cifrado del desafío es la encriptación de m0 o la 170 00:12:34,094 --> 00:12:37,918 encriptación de m1. Y, como es habitual, si no puede hacerlo, en otras palabras, su respuesta 171 00:12:37,918 --> 00:12:42,351 ante el experimento cero es básicamente la misma respuesta que en el experimento 172 00:12:42,351 --> 00:12:46,839 uno, sin ser capaz de diferenciar la encriptación de m0 de la encriptación de 173 00:12:46,839 --> 00:12:51,219 m1 a pesar del poder del que disponía, entonces decimos que el sistema es semánticamente 174 00:12:51,219 --> 00:12:55,877 seguro frente a ataque de texto cifrado escogido, seguro CCA. En ocasiones se utiliza este acrónimo, 175 00:12:55,877 --> 00:13:00,596 el acrónimo de INDistinguible frente a un Ataque de texto Cifrado esCogido [IND-CCA], pero me voy 176 00:13:00,596 --> 00:13:05,745 a limitar a llamarlo "seguro CCA". Así, vamos a ver como esto refleja el ejemplo con el correo electrónico 177 00:13:05,745 --> 00:13:10,587 que vimos antes. Supongamos que el sistema de encriptación usado es tal que simplemente dada 178 00:13:10,587 --> 00:13:15,429 un mensaje encriptado el atacante puede cambiar el destinatario, digamos, de Alice 179 00:13:15,429 --> 00:13:20,129 a Charlie. Entonces, así es como él ganaría el juego CCA. Bien, en el 180 00:13:20,129 --> 00:13:25,033 primer paso recibe, por supuesto, la clave pública. Y entonces el atacante lo que hará 181 00:13:25,033 --> 00:13:29,578 es proporcionar dos mensajes de igual longitud, esto es, en el primer mensaje el cuerpo contendrá 182 00:13:29,578 --> 00:13:33,943 un cero. En el segundo mensaje el cuerpo contendrá un uno. Pero ambos mensajes están dirigidos a 183 00:13:33,943 --> 00:13:39,890 Alice. Y, en respuesta, él recibirá el texto cifrado del desafío, "c". 184 00:13:39,890 --> 00:13:45,130 Bien, así que ahora tenemos nuestro texto cifrado del desafío, "c". Ahora, lo que hará el 185 00:13:45,130 --> 00:13:49,961 atacante es utilizar su habilidad para modificar el destinatario. 186 00:13:49,961 --> 00:13:55,269 Y devolverá un texto cifrado c' [c prima] en el que c' es la encriptación del 187 00:13:55,269 --> 00:14:01,760 mensaje para Charlie con el cuerpo del desafío, "b". Esto es, si os acordáis, o 188 00:14:01,760 --> 00:14:07,822 cero o uno. Ahora, como que el texto llano es diferente, sabemos que 189 00:14:07,822 --> 00:14:12,486 el texto cifrado debe también ser diferente. En particular, c' debe ser diferente del 190 00:14:12,486 --> 00:14:17,206 texto del desafío "c", ¿no es así? Esto es, c' debe ser diferente de "c". Y como 191 00:14:17,206 --> 00:14:21,758 consecuencia, el pobre retador ahora tiene que desencriptar, por definición del juego CCA. 192 00:14:21,758 --> 00:14:26,141 El retador tiene que desencriptar cualquier texto crifrado que no sea igual a un texto cifrado enviado 193 00:14:26,141 --> 00:14:30,648 por el retador. Así, el retador desencripta, le da al adversario m'. Básicamente proporciona 194 00:14:30,648 --> 00:14:35,256 al adversario "b". Y ahora el adversario puede mostrar "b" como resultado del desafío 195 00:14:35,256 --> 00:14:40,293 y gana el juego con ventaja 1. Así, su ventaja con este esquema particular 196 00:14:40,293 --> 00:14:45,143 era uno. Simplemente porque el atacante era capaz de cambiar el texto cifrado del 197 00:14:45,146 --> 00:14:49,999 retador de un destinatario a otro, lo que le permite ganar el juego CCA con 198 00:14:49,999 --> 00:14:55,003 ventaja uno. Así, como ya dije, [el modelo] de seguridad de texto cifrado escogido es en 199 00:14:55,003 --> 00:14:59,327 realidad la noción de seguridad correcta para los sistemas de criptografía de clave pública. Y este es 200 00:14:59,327 --> 00:15:03,651 un concepto muy interesante. De algún modo, aunque el atacante tenga la habilidad para 201 00:15:03,651 --> 00:15:07,839 desencriptar todo lo que quiera, excepto el texto cifrado del desafío, no es capaz de 202 00:15:07,839 --> 00:15:12,028 conocer el texto cifrado del retador. Así, lo que haremos lo que haremos durante lo que queda de este módulo y, 203 00:15:12,028 --> 00:15:16,275 de hecho, también el próximo, es construir sistemas seguros CCA. Se tiene que 204 00:15:16,275 --> 00:15:20,093 destacar que es posible y voy a mostraros exactamente cómo 205 00:15:20,093 --> 00:15:24,310 hacerlo. Y, de hecho, los sistemas seguros CCA que construiremos 206 00:15:24,310 --> 00:15:28,579 son los que se utilizan en el mundo real. Y cada vez que se ha intentado implementar un 207 00:15:28,737 --> 00:15:33,007 sistema de criptografía de clave pública que no ha sido seguro CCA, alguien ha encontrado un 208 00:15:33,007 --> 00:15:37,487 ataque y ha sido capaz de romperlo. Y vamos a ver algunos ejemplos de esos ataques 209 00:15:37,487 --> 00:15:39,280 en unos pocos segmentos.