WEBVTT 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. 00:00:03.583 --> 00:00:07.166 Esta semana vamos a poner a trabajar ese conocimiento y vamos a construir varios 00:00:07.166 --> 00:00:10.889 esquemas de criptografía de clave pública seguros. Pero primero es necesario definir qué es 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 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 00:00:18.241 --> 00:00:21.778 algoritmo de encriptación, normalmente denotado como E, y un algoritmo de 00:00:21.778 --> 00:00:25.361 desencriptado que denotamos como D. En cualquier caso, aquí el algoritmo de encriptación usa una 00:00:25.361 --> 00:00:29.477 clave pública, mientras que el de desencriptado usa una clave privada. Este par se denomina 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 00:00:34.356 --> 00:00:39.002 se utiliza para desencriptarlos. Por tanto, en este caso, un mensaje "m" se encripta usando 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, 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 00:00:48.643 --> 00:00:53.577 se obtiene del algoritmo de desencriptado es el mensaje original, "m". La encripción de clave 00:00:53.577 --> 00:00:57.989 pública tiene muchas aplicaciones. La semana pasada vimos la aplicación clásica, el 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 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, 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. 00:01:11.227 --> 00:01:15.546 Enviará la clave pública a Bob. Bob generará un valor aleatorio "x", que 00:01:15.546 --> 00:01:20.136 servirá como su secreto compartido y, entonces, envía "x" encriptada a Alice, 00:01:20.136 --> 00:01:24.904 encriptada con su clave pública [de Alice]. Alice puede desencriptar, recuperar "x" y ahora ambos 00:01:24.904 --> 00:01:29.554 disponen de este secreto compartido, "x", que pueden utilizar para comunicarse de forma segura 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 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 00:01:38.972 --> 00:01:43.800 información sobre "x". Vamos a definir esto de forma más precisa para entender 00:01:43.800 --> 00:01:48.507 qué significa no ser capaz de averiguar nada sobre "x". La criptografía pública, 00:01:48.507 --> 00:01:52.522 de hecho, tiene muchas otras aplicaciones. Por ejemplo, es muy útil en 00:01:52.522 --> 00:01:57.235 aplicaciones no interactivas. Así, pensad en un sistema de correo electrónico, por ejemplo. Aquí, Bob 00:01:57.235 --> 00:02:01.716 quiere enviar correo a Alice y, cuando Bob envía el correo, el correo pasa de 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á 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 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 00:02:15.045 --> 00:02:19.195 recibirá. Y Alice no debería tener que comunicarse con Bob a fin de desencriptar 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 00:02:23.502 --> 00:02:27.705 de establecer un secreto compartido entre Alice y Bob. Por tanto, en este caso, lo que 00:02:27.705 --> 00:02:32.169 ocurrirá es que Bob, básicamente, enviará el correo encriptado utilizando la clave pública de 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 00:02:36.571 --> 00:02:41.103 Alice, encriptado usando su clave pública [de Alice]. Cuando Alice recibe este correo, ella utiliza 00:02:41.103 --> 00:02:45.748 su clave privada para desencriptar el texto cifrado y recuperar el mensaje en texto llano. 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, 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 00:02:54.804 --> 00:02:58.297 de la clave pública de Alice, pero más adelante, cuando hablemos sobre firmas digitales, 00:02:58.297 --> 00:03:02.457 veremos cómo se puede hacer esto de forma muy eficiente utilizando lo que se 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. 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 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 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. 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, 00:03:22.898 --> 00:03:26.390 en las que cualquiera en el mundo, de forma no interactiva, necesita enviar un mensaje 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 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é 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. 00:03:40.347 --> 00:03:44.431 G se denomina algoritmo de generación de claves. Básicamente lo que hace es 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 00:03:48.672 --> 00:03:53.018 argumentos, pero en la vida real, G realmente usa un argumento denominado el parámetro 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 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 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 00:04:06.051 --> 00:04:10.530 usa la clave privada correspondiente y un texto cifrado y genera el correspondiente 00:04:10.530 --> 00:04:14.955 mensaje. Como siempre, para [la condición de] consistencia, diremos que si encriptamos un mensaje 00:04:14.955 --> 00:04:19.380 según una determinada clave pública y luego lo desencriptamos con la clave privada correspondiente, 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 00:04:23.852 --> 00:04:27.913 que sea seguro? Voy a empezar definiendo seguridad contra escucha 00:04:27.913 --> 00:04:32.002 y luego definiremos la seguridad contra ataques activos. La forma de 00:04:32.002 --> 00:04:36.237 definir seguridad contra escucha es muy similar a la del caso simétrico que hemos 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. 00:04:40.626 --> 00:04:44.808 Básicamente, el juego de ataque se define como sigue. Definimos estos dos experimentos, 00:04:44.808 --> 00:04:49.249 experimento cero y experimento uno. En cada experimento el retador generará 00:04:49.249 --> 00:04:52.965 un par de claves pública y privada. Le dará la clave pública 00:04:52.965 --> 00:04:57.342 al adversario. El adversario emitirá dos mensajes, m0 y m1 de la misma 00:04:57.342 --> 00:05:01.663 longitud y lo que recibe es la encripción de m0 o la 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 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 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í, 00:05:15.240 --> 00:05:19.676 en este juego, el atacante sólo obtiene un texto cifrado. Esto corresponde a un ataque 00:05:19.676 --> 00:05:24.226 de escucha en el que se limita a "escuchar" dicho texto cifrado "c". Y ahora 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 00:05:28.719 --> 00:05:34.221 permite manipular el texto cifrado "c" por ahora. Y, como es costumbre, diremos que el 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 00:05:38.206 --> 00:05:42.085 distinguir el experimento cero del experimento uno. En otras palabras, no puede 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 00:05:47.757 --> 00:05:52.311 a los ataques activos, quiero mencionar una relación inmediata entre la definición que acabamos 00:05:52.311 --> 00:05:56.105 de ver y la definición de seguridad de escucha para cifrado simétrico. 00:05:56.105 --> 00:06:00.438 Si lo recordáis, cuando hablamos sobre seguridad de escucha para cifrado 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 00:06:04.771 --> 00:06:08.998 clave se usaba varias veces. Y, de hecho, vimos que existe una clara 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 00:06:13.357 --> 00:06:17.382 un único mensaje, pero es completamente inseguro si la clave se usa para encriptar múltiples 00:06:17.382 --> 00:06:21.358 mensajes. Y, de hecho, teníamos dos definiciones diferentes, si os acordáis, teníamos una 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 00:06:25.383 --> 00:06:29.700 exigente, cuando la clave se usaba varias veces. La definición que os he mostrado en 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 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 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 00:06:43.124 --> 00:06:47.929 la clave. En otras palabras, no es necesario proporcionar explícitamente al atacante la habilidad 00:06:47.929 --> 00:06:53.171 para requerir encripciones de mensajes de su elección, ya que puede crear encripciones 00:06:53.171 --> 00:06:57.870 por si mismo. Dispone de la clave pública y, por tanto, puede 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 00:07:04.672 --> 00:07:09.289 de algún modo inherentemente se usan para encriptar varios mensajes ya que el atacante 00:07:09.289 --> 00:07:13.905 podría encriptar muchos, muchos mensajes de su elección usando la clave 00:07:13.905 --> 00:07:18.891 pública que le hemos proporcionado en el primer paso. Y así, como resultado, de hecho 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 00:07:23.692 --> 00:07:28.801 es por ello que nos referimos al concepto como indistinguibilidad bajo un ataque de 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 00:07:34.012 --> 00:07:37.770 de clave pública no necesitamos una definición más compleja para aprehender 00:07:37.770 --> 00:07:42.515 la seguridad ante escucha. Ahora que entendemos la seguridad ante escucha, 00:07:42.515 --> 00:07:47.343 vamos a ver adversarios mas fuertes que pueden montar ataques activos. Entonces, en 00:07:47.343 --> 00:07:51.585 particular, veamos el ejemplo del correo electronico. Así, aquí tenemos a nuestro amigo Bob 00:07:51.585 --> 00:07:56.228 que quiere enviar enviar un correo a su amiga Caroline. Y resulta que Caroline tiene una 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 00:08:00.699 --> 00:08:05.514 servidor de Gmail. El servidor de Gmail desencripta el correo electrónico, mira quienes son los 00:08:05.514 --> 00:08:09.297 destinatarios y luego, si es que el destinatario es Caroline, 00:08:09.297 --> 00:08:13.653 reenvia el correo electrónico a Caroline. Si el destinatario es el atacante, se 00:08:13.653 --> 00:08:18.573 lo reenvia al atacante. Esto es similar a cómo trabaja realmente Gmail, 00:08:18.573 --> 00:08:23.441 porque el remitente enviaría el correo encriptado sobre SSL al servidor Gmail, 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 00:08:28.087 --> 00:08:33.081 apropiados. Ahora supongamos que Bob encripta el correo usando un sistema que 00:08:33.081 --> 00:08:37.764 permita al adversario manipular el texto cifrado sin ser detectado. Por 00:08:37.764 --> 00:08:42.387 ejemplo, imaginad que el correo está encriptado usando el modo contador o 00:08:42.387 --> 00:08:47.070 similar. Entonces, cuando el atacante intercepta este correo puede cambiar el destinatario 00:08:47.070 --> 00:08:50.732 de forma que ahora el destinatario sea attacker@gmail.com. Y sabemos que, para el 00:08:50.732 --> 00:08:55.415 modo contador, por ejemplo. esto es muy fácil de hacer. El atacante sabe que el 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 00:09:00.278 --> 00:09:04.226 fácilmente cambiar el destinatario del correo a attacker@gmail.com y ahora, cuando el servidor 00:09:04.226 --> 00:09:08.129 recibe el correo, lo desencriptará, verá que el destinatario se supone que es el 00:09:08.129 --> 00:09:12.033 atacante y reenviará el cuerpo del mensaje al atacante. Ahora el atacante ha podido 00:09:12.033 --> 00:09:16.022 leer el cuerpo del mensaje que estaba destinado a Caroline. Así, 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: 00:09:21.198 --> 00:09:26.174 puede desencriptar cualquier texto cifrado en el que el destinatario sea "to:attacker", 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 00:09:31.548 --> 00:09:36.657 diseñar sistemas de clave pública que sean seguros incluso si el atacante puede manipular 00:09:36.657 --> 00:09:42.999 el texto cifrado y, posiblemente, desencriptar algunos textos cifrados. Y, de nuevo, quiero 00:09:42.999 --> 00:09:47.612 enfatizar que aquí el objetivo del atacante es obtener el cuerpo del mensaje. El atacante 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 00:09:52.055 --> 00:09:56.863 era cambiar el destinatario. Así, este ataque mediante manipulación motiva la 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 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 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 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 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 00:10:20.140 --> 00:10:24.313 a definir dos experimentos, experimento cero y experimento uno. Así, aquí "b" indica si 00:10:24.313 --> 00:10:28.222 el retador está implementando el experimento cero el el experimento 00:10:28.222 --> 00:10:32.659 uno. El retador empieza generando una clave pública y una clave privada y entonces proporciona 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 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 00:10:41.611 --> 00:10:46.452 c1 y obtiene la desencripción del texto cifrado c1, esto es, m1. Y lo repite 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, 00:10:51.414 --> 00:10:56.195 que es m2, el texto cifrado c3 y lo obtiene desencriptado, m3, y así en adelante. 00:10:56.195 --> 00:11:00.188 Finalmente, el adversario dice: "Esta fase de interrogación ha acabado" y ahora 00:11:00.188 --> 00:11:04.485 remite básicamente dos mensajes de la misma longitud, m0 y m1, como es habitual, y 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 00:11:08.820 --> 00:11:13.052 la encriptación de m1, dependiendo de si estamos en el experimento cero o el 00:11:13.052 --> 00:11:17.003 experimento uno. Ahora el adversario puede continuar enviando solicitudes de texto 00:11:17.003 --> 00:11:21.063 cifrado. Así, puede continuar remitiendo solicitudes de desencriptado. Así, el remite 00:11:21.063 --> 00:11:25.447 un texto cifrado y recibe el texto desencriptado, pero, por supuesto, ahora tiene que haver una 00:11:25.447 --> 00:11:29.994 limitación. Si el atacante pudiese solicitar textos cifrados arbitrarios de su elección, 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 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 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. 00:11:42.665 --> 00:11:46.825 Como resultado, ponemos la siguiente limitación, que dice que él puede de hecho enviar cualquier 00:11:46.825 --> 00:11:51.031 texto cifrado de su elección, excepto el texto cifrado del desafío. Así, el atacante 00:11:51.031 --> 00:11:55.034 podrá solicitar el desencriptado de cualquier texto cifrado de su elección que no sea el 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 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 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 00:12:09.212 --> 00:12:14.113 al atacante más poder del que vimos en la transparencia anterior. En la transparencia anterior, 00:12:14.113 --> 00:12:18.710 el atacante sólo podía desencriptar mensajes si el texto llano empezada con "to:attacker". 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, 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 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 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 00:12:37.918 --> 00:12:42.351 ante el experimento cero es básicamente la misma respuesta que en el experimento 00:12:42.351 --> 00:12:46.839 uno, sin ser capaz de diferenciar la encriptación de m0 de la encriptación de 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 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, 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 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 00:13:05.745 --> 00:13:10.587 que vimos antes. Supongamos que el sistema de encriptación usado es tal que simplemente dada 00:13:10.587 --> 00:13:15.429 un mensaje encriptado el atacante puede cambiar el destinatario, digamos, de Alice 00:13:15.429 --> 00:13:20.129 a Charlie. Entonces, así es como él ganaría el juego CCA. Bien, en el 00:13:20.129 --> 00:13:25.033 primer paso recibe, por supuesto, la clave pública. Y entonces el atacante lo que hará 00:13:25.033 --> 00:13:29.578 es proporcionar dos mensajes de igual longitud, esto es, en el primer mensaje el cuerpo contendrá 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 00:13:33.943 --> 00:13:39.890 Alice. Y, en respuesta, él recibirá el texto cifrado del desafío, "c". 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 00:13:45.130 --> 00:13:49.961 atacante es utilizar su habilidad para modificar el destinatario. 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 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 00:14:01.760 --> 00:14:07.822 cero o uno. Ahora, como que el texto llano es diferente, sabemos que 00:14:07.822 --> 00:14:12.486 el texto cifrado debe también ser diferente. En particular, c' debe ser diferente del 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 00:14:17.206 --> 00:14:21.758 consecuencia, el pobre retador ahora tiene que desencriptar, por definición del juego CCA. 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 00:14:26.141 --> 00:14:30.648 por el retador. Así, el retador desencripta, le da al adversario m'. Básicamente proporciona 00:14:30.648 --> 00:14:35.256 al adversario "b". Y ahora el adversario puede mostrar "b" como resultado del desafío 00:14:35.256 --> 00:14:40.293 y gana el juego con ventaja 1. Así, su ventaja con este esquema particular 00:14:40.293 --> 00:14:45.143 era uno. Simplemente porque el atacante era capaz de cambiar el texto cifrado del 00:14:45.146 --> 00:14:49.999 retador de un destinatario a otro, lo que le permite ganar el juego CCA con 00:14:49.999 --> 00:14:55.003 ventaja uno. Así, como ya dije, [el modelo] de seguridad de texto cifrado escogido es en 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 00:14:59.327 --> 00:15:03.651 un concepto muy interesante. De algún modo, aunque el atacante tenga la habilidad para 00:15:03.651 --> 00:15:07.839 desencriptar todo lo que quiera, excepto el texto cifrado del desafío, no es capaz de 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, 00:15:12.028 --> 00:15:16.275 de hecho, también el próximo, es construir sistemas seguros CCA. Se tiene que 00:15:16.275 --> 00:15:20.093 destacar que es posible y voy a mostraros exactamente cómo 00:15:20.093 --> 00:15:24.310 hacerlo. Y, de hecho, los sistemas seguros CCA que construiremos 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 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 00:15:33.007 --> 00:15:37.487 ataque y ha sido capaz de romperlo. Y vamos a ver algunos ejemplos de esos ataques 00:15:37.487 --> 00:15:39.280 en unos pocos segmentos.