0:00:00.000,0:00:03.583
La semana pasada, aprendimos la teoría numérica [br]necesaria para la criptografía de clave pública.

0:00:03.583,0:00:07.166
Esta semana vamos a poner a trabajar ese [br]conocimiento y vamos a construir varios

0:00:07.166,0:00:10.889
esquemas de criptografía de clave pública seguros. [br]Pero primero es necesario definir qué es

0:00:10.889,0:00:14.565
la criptografía de clave pública y qué significa [br]que la criptografía de clave pública sea

0:00:14.565,0:00:18.241
segura. Así, permitidme recordaros que en un [br]esquema de criptografía de clave pública hay un

0:00:18.241,0:00:21.778
algoritmo de encriptación, normalmente denotado [br]como E, y un algoritmo de

0:00:21.778,0:00:25.361
desencriptado que denotamos como D. En cualquier [br]caso, aquí el algoritmo de encriptación usa una

0:00:25.361,0:00:29.477
clave pública, mientras que el de desencriptado [br]usa una clave privada. Este par se denomina

0:00:29.477,0:00:34.356
par de claves. Y la clave pública se utiliza para [br]encriptar mensajes mientras que la clave privada

0:00:34.356,0:00:39.002
se utiliza para desencriptarlos. Por tanto, en este [br]caso, un mensaje "m" se encripta usando

0:00:39.002,0:00:43.880
la clave pública y lo que se obtiene de ello es el [br]texto cifrado, "c". Y, de forma similar,

0:00:43.880,0:00:48.643
el texto cifrado se usa para alimentar el algoritmo de [br]desencriptado usando la clave privada y lo que

0:00:48.643,0:00:53.577
se obtiene del algoritmo de desencriptado es [br]el mensaje original, "m". La encripción de clave

0:00:53.577,0:00:57.989
pública tiene muchas aplicaciones. La semana [br]pasada vimos la aplicación clásica, el

0:00:57.989,0:01:02.455
establecimiento de sesión, esto es, intercambio de [br]claves. Y por ahora vamos a limitarnos al intercambio de

0:01:02.455,0:01:06.867
claves que sea seguro sólo contra escucha. Y, si [br]recordáis cómo funciona el protocolo,

0:01:06.867,0:01:11.227
básicamente Alice, lo que ella hará es generar [br]un par de claves pública y privada.

0:01:11.227,0:01:15.546
Enviará la clave pública a Bob. Bob [br]generará un valor aleatorio "x", que

0:01:15.546,0:01:20.136
servirá como su secreto compartido y, [br]entonces, envía "x" encriptada a Alice,

0:01:20.136,0:01:24.904
encriptada con su clave pública [de Alice]. Alice puede [br]desencriptar, recuperar "x" y ahora ambos

0:01:24.904,0:01:29.554
disponen de este secreto compartido, "x", que [br]pueden utilizar para comunicarse de forma segura

0:01:29.554,0:01:34.143
entre ellos. El atacante, por supuesto, todo lo que [br]puede ver es la clave pública, la

0:01:34.143,0:01:38.972
encriptación de "x" con la clave pública, de la cual [br]no debería poder obtener ninguna

0:01:38.972,0:01:43.800
información sobre "x". Vamos a definir esto [br]de forma más precisa para entender

0:01:43.800,0:01:48.507
qué significa no ser capaz de averiguar nada [br]sobre "x". La criptografía pública,

0:01:48.507,0:01:52.522
de hecho, tiene muchas otras aplicaciones. [br]Por ejemplo, es muy útil en

0:01:52.522,0:01:57.235
aplicaciones no interactivas. Así, pensad en un [br]sistema de correo electrónico, por ejemplo. Aquí, Bob

0:01:57.235,0:02:01.716
quiere enviar correo a Alice y, cuando Bob [br]envía el correo, el correo pasa de

0:02:01.716,0:02:06.603
agente de transporte a agente de transporte hasta que [br]llega a Alice, momento en el que Alice deberá

0:02:06.603,0:02:10.502
desencrciptar. La forma en que el sistema de correo [br]está implementado está diseñada según una

0:02:10.502,0:02:15.045
configuración no interactiva en la que Bob envía [br]el correo y entonces Alice se supone que lo

0:02:15.045,0:02:19.195
recibirá. Y Alice no debería tener que comunicarse [br]con Bob a fin de desencriptar

0:02:19.195,0:02:23.502
el correo. Por tanto, en este caso, a causa de la [br]falta de interactividad, no existe la oportunidad

0:02:23.502,0:02:27.705
de establecer un secreto compartido entre Alice y [br]Bob. Por tanto, en este caso, lo que

0:02:27.705,0:02:32.169
ocurrirá es que Bob, básicamente, enviará [br]el correo encriptado utilizando la clave pública de

0:02:32.169,0:02:36.571
Alice. Del mismo modo que él envía el correo, cualquiera [br]en el mundo puede enviar el correo encriptado a

0:02:36.571,0:02:41.103
Alice, encriptado usando su clave pública [de Alice]. [br]Cuando Alice recibe este correo, ella utiliza

0:02:41.103,0:02:45.748
su clave privada para desencriptar el texto cifrado y [br]recuperar el mensaje en texto llano.

0:02:45.748,0:02:50.507
Por supuesto, el inconveniente en un sistema como [br]éste es que, de hecho, Bob necesita, de algún modo,

0:02:50.507,0:02:54.804
obtener la clave pública de Alice. Así, por ahora, vamos [br]a asumir, simplemente, que Bob ya dispone

0:02:54.804,0:02:58.297
de la clave pública de Alice, pero más adelante, [br]cuando hablemos sobre firmas digitales,

0:02:58.297,0:03:02.457
veremos cómo se puede hacer esto de [br]forma muy eficiente utilizando lo que se

0:03:02.457,0:03:06.823
llama gestión de clave pública y, como ya he [br]dicho, volveremos a ello más adelante.

0:03:06.823,0:03:10.931
Lo más importante que quiero que recordéis es [br]que la criptografía de clave pública se

0:03:10.931,0:03:14.578
utiliza para establecer sesiones. Esto es muy [br]común en la web, donde la criptografía de

0:03:14.578,0:03:18.840
clave pública se utiliza para establecer una clave [br]segura entre un navegador web y un servidor web.

0:03:18.840,0:03:22.898
Y la criptografía de clave pública también es muy [br]útil para aplicaciones no interactivas,

0:03:22.898,0:03:26.390
en las que cualquiera en el mundo, de forma [br]no interactiva, necesita enviar un mensaje

0:03:26.390,0:03:30.653
a Alice, pudiendo encriptar el mensaje usando la [br]clave pública de Alice y Alice puede desencriptar

0:03:30.653,0:03:36.105
y recuperar el texto llano. Por tanto, permitidme que [br]os recuerde con algo más de detalle qué

0:03:36.105,0:03:40.347
es un sistema de criptografía de clave pública. Bien, [br]consiste en tres algoritmos, G, E y D.

0:03:40.347,0:03:44.431
G se denomina algoritmo de generación de [br]claves. Básicamente lo que hace es

0:03:44.431,0:03:48.672
generar este par de claves, la clave pública y la [br]clave privada. Tal como se indica aquí, G no usa

0:03:48.672,0:03:53.018
argumentos, pero en la vida real, G realmente usa [br]un argumento denominado el parámetro

0:03:53.018,0:03:57.260
de seguridad, que especifica el tamaño de las [br]claves que se generan con este algoritmo de

0:03:57.260,0:04:01.731
generación de claves. Luego está este algoritmo [br]de encriptación, como es habitual, que usa una

0:04:01.731,0:04:06.051
clave pública y un mensaje y genera un texto [br]cifrado, y un algoritmo de desencriptado que

0:04:06.051,0:04:10.530
usa la clave privada correspondiente y un [br]texto cifrado y genera el correspondiente

0:04:10.530,0:04:14.955
mensaje. Como siempre, para [la condición de] [br]consistencia, diremos que si encriptamos un mensaje

0:04:14.955,0:04:19.380
según una determinada clave pública y luego lo [br]desencriptamos con la clave privada correspondiente,

0:04:19.380,0:04:23.852
deberemos obtener de nuevo el mensaje original. Ahora, [br]¿qué significa para un sistema criptográfico de clave pública

0:04:23.852,0:04:27.913
que sea seguro? Voy a empezar definiendo [br]seguridad contra escucha

0:04:27.913,0:04:32.002
y luego definiremos la seguridad contra [br]ataques activos. La forma de

0:04:32.002,0:04:36.237
definir seguridad contra escucha es muy [br]similar a la del caso simétrico que hemos

0:04:36.237,0:04:40.626
visto la semana pasada, así que vamos a pasar [br]por ello rápidamente, sólo como repaso.

0:04:40.626,0:04:44.808
Básicamente, el juego de ataque se define como [br]sigue. Definimos estos dos experimentos,

0:04:44.808,0:04:49.249
experimento cero y experimento uno. En [br]cada experimento el retador generará

0:04:49.249,0:04:52.965
un par de claves pública y privada. [br]Le dará la clave pública

0:04:52.965,0:04:57.342
al adversario. El adversario emitirá [br]dos mensajes, m0 y m1 de la misma

0:04:57.342,0:05:01.663
longitud y lo que recibe es la [br]encripción de m0 o la

0:05:01.663,0:05:06.039
encripción de m1. En el experimento cero [br]obtiene la encripción de m0. En el experimento

0:05:06.039,0:05:10.748
uno obtiene la encripción de m1. Y entonces el [br]adversario se supone de debe indicar cuál

0:05:10.748,0:05:15.240
ha recibido, ¿Ha recibido la encripción de [br]m0 o ha recibido la encripción de m1? Así,

0:05:15.240,0:05:19.676
en este juego, el atacante sólo obtiene un [br]texto cifrado. Esto corresponde a un ataque

0:05:19.676,0:05:24.226
de escucha en el que se limita a "escuchar" [br]dicho texto cifrado "c". Y ahora

0:05:24.226,0:05:28.719
su objetivo es determinar si el texto cifrado "c" [br]es la encripción de m0 o m1. No se

0:05:28.719,0:05:34.221
permite manipular el texto cifrado "c" por ahora. [br]Y, como es costumbre, diremos que el

0:05:34.221,0:05:38.206
esquema de criptografía de clave pública es [br]semánticamente seguro si el atacante no puede

0:05:38.206,0:05:42.085
distinguir el experimento cero del experimento [br]uno. En otras palabras, no puede

0:05:42.085,0:05:47.757
diferenciar si recibió la encripción de m0 [br]o la encripción de m1. Antes de pasar

0:05:47.757,0:05:52.311
a los ataques activos, quiero mencionar una [br]relación inmediata entre la definición que acabamos

0:05:52.311,0:05:56.105
de ver y la definición de seguridad de [br]escucha para cifrado simétrico.

0:05:56.105,0:06:00.438
Si lo recordáis, cuando hablamos sobre [br]seguridad de escucha para cifrado

0:06:00.438,0:06:04.771
simétrico, distinguíamos entre el caso en que la [br]clave se usaba una vez y el caso en que la

0:06:04.771,0:06:08.998
clave se usaba varias veces. Y, de hecho, [br]vimos que existe una clara

0:06:08.998,0:06:13.357
separación. Por ejemplo, el cuaderno de un solo [br]uso es seguro si la clave se usa para encriptar

0:06:13.357,0:06:17.382
un único mensaje, pero es completamente inseguro [br]si la clave se usa para encriptar múltiples

0:06:17.382,0:06:21.358
mensajes. Y, de hecho, teníamos dos definiciones [br]diferentes, si os acordáis, teníamos una

0:06:21.358,0:06:25.383
definición para seguridad de un solo uso y una [br]definición diferente, que era más

0:06:25.383,0:06:29.700
exigente, cuando la clave se usaba varias [br]veces. La definición que os he mostrado en

0:06:29.700,0:06:34.043
la transparencia anterior es muy similar a la [br]definición de seguridad de un solo uso para

0:06:34.043,0:06:38.499
cifras simétricas. Y, de hecho, resulta que para [br]la criptografía de clave pública, si un

0:06:38.499,0:06:43.124
sistema es seguro en el caso de un solo uso de la clave, [br]en cierto sentido, también es seguro para uso múltiple de

0:06:43.124,0:06:47.929
la clave. En otras palabras, no es necesario [br]proporcionar explícitamente al atacante la habilidad

0:06:47.929,0:06:53.171
para requerir encripciones de mensajes de su [br]elección, ya que puede crear encripciones

0:06:53.171,0:06:57.870
por si mismo. Dispone de la clave [br]pública y, por tanto, puede

0:06:57.870,0:07:04.672
por si mismo encriptar cualquier mensaje que desee. [br]Como resultado, cualquier par de claves pública y privada

0:07:04.672,0:07:09.289
de algún modo inherentemente se usan para [br]encriptar varios mensajes ya que el atacante

0:07:09.289,0:07:13.905
podría encriptar muchos, muchos mensajes [br]de su elección usando la clave

0:07:13.905,0:07:18.891
pública que le hemos proporcionado en el [br]primer paso. Y así, como resultado, de hecho

0:07:18.891,0:07:23.692
la definición de seguridad para un solo uso es [br]suficiente para implicar seguridad de varios usos y

0:07:23.692,0:07:28.801
es por ello que nos referimos al concepto como [br]indistinguibilidad bajo un ataque de

0:07:28.801,0:07:34.012
texto llano escogido. Así, este es sólo un punto menor [br]para explicar por qué en la configuración de criptografía

0:07:34.012,0:07:37.770
de clave pública no necesitamos una [br]definición más compleja para aprehender

0:07:37.770,0:07:42.515
la seguridad ante escucha. Ahora que [br]entendemos la seguridad ante escucha,

0:07:42.515,0:07:47.343
vamos a ver adversarios mas fuertes que pueden [br]montar ataques activos. Entonces, en

0:07:47.343,0:07:51.585
particular, veamos el ejemplo del correo electronico. [br]Así, aquí tenemos a nuestro amigo Bob

0:07:51.585,0:07:56.228
que quiere enviar enviar un correo a su amiga [br]Caroline. Y resulta que Caroline tiene una

0:07:56.228,0:08:00.699
cuenta en Gmail. Y esto funciona básicamente [br]así, el correo electrónico se envía encriptado al

0:08:00.699,0:08:05.514
servidor de Gmail. El servidor de Gmail desencripta [br]el correo electrónico, mira quienes son los

0:08:05.514,0:08:09.297
destinatarios y luego, si es que el [br]destinatario es Caroline,

0:08:09.297,0:08:13.653
reenvia el correo electrónico a Caroline. [br]Si el destinatario es el atacante, se

0:08:13.653,0:08:18.573
lo reenvia al atacante. Esto es similar a [br]cómo trabaja realmente Gmail,

0:08:18.573,0:08:23.441
porque el remitente enviaría el correo encriptado [br]sobre SSL al servidor Gmail,

0:08:23.441,0:08:28.087
el servidor Gmail terminaría [la sesión] SSL y [br]reenviaría el mensaje a los destinatarios

0:08:28.087,0:08:33.081
apropiados. Ahora supongamos que Bob [br]encripta el correo usando un sistema que

0:08:33.081,0:08:37.764
permita al adversario manipular el [br]texto cifrado sin ser detectado. Por

0:08:37.764,0:08:42.387
ejemplo, imaginad que el correo está [br]encriptado usando el modo contador o

0:08:42.387,0:08:47.070
similar. Entonces, cuando el atacante intercepta [br]este correo puede cambiar el destinatario

0:08:47.070,0:08:50.732
de forma que ahora el destinatario sea [br]attacker@gmail.com. Y sabemos que, para el

0:08:50.732,0:08:55.415
modo contador, por ejemplo. esto es muy [br]fácil de hacer. El atacante sabe que el

0:08:55.415,0:09:00.278
correo está dirigido a Caroline, él está sólo [br]interesado en el cuerpo del correo. Por tanto, puede

0:09:00.278,0:09:04.226
fácilmente cambiar el destinatario del correo [br]a attacker@gmail.com y ahora, cuando el servidor

0:09:04.226,0:09:08.129
recibe el correo, lo desencriptará, verá que [br]el destinatario se supone que es el

0:09:08.129,0:09:12.033
atacante y reenviará el cuerpo del mensaje al [br]atacante. Ahora el atacante ha podido

0:09:12.033,0:09:16.022
leer el cuerpo del mensaje que [br]estaba destinado a Caroline. Así,

0:09:16.022,0:09:21.198
este es un ejemplo clásico de ataque activo, y [br]podéis ver lo que el atacante ha conseguido:

0:09:21.198,0:09:26.174
puede desencriptar cualquier texto cifrado [br]en el que el destinatario sea "to:attacker",

0:09:26.174,0:09:31.548
esto es, un texto cifrado en el que el texto llano[br]empiece por "to:attacker". Así, nuestro objetivo es [br]empiece

0:09:31.548,0:09:36.657
diseñar sistemas de clave pública que sean [br]seguros incluso si el atacante puede manipular

0:09:36.657,0:09:42.999
el texto cifrado y, posiblemente, desencriptar [br]algunos textos cifrados. Y, de nuevo, quiero

0:09:42.999,0:09:47.612
enfatizar que aquí el objetivo del atacante es [br]obtener el cuerpo del mensaje. El atacante

0:09:47.612,0:09:52.055
ya sabía que el correo estaba destinado [br]a Caroline. Y todo lo que él tenía que hacer

0:09:52.055,0:09:56.863
era cambiar el destinatario. Así, este [br]ataque mediante manipulación motiva la

0:09:56.863,0:10:01.620
definición de seguridad de texto cifrado escogido. [br]y, de hecho, esta es la noción estándar de

0:10:01.620,0:10:07.462
seguridad para la criptografía de clave pública. Así, [br]permitidme explicaros cómo funciona el esquema del

0:10:07.462,0:10:11.899
ataque. Como ya dije, nuestro objetivo es construir [br]sistemas que sean seguros bajo esta noción tan

0:10:11.899,0:10:15.756
conservadora de encripción. Así, tenemos un [br]esquema de encripción G, E, D y digamos que

0:10:15.756,0:10:20.140
está definido sobre nuestro espacio de mensajes [br]y de textos cifrados M, C. Como es habitual, vamos

0:10:20.140,0:10:24.313
a definir dos experimentos, experimento cero y [br]experimento uno. Así, aquí "b" indica si

0:10:24.313,0:10:28.222
el retador está implementando el [br]experimento cero el el experimento

0:10:28.222,0:10:32.659
uno. El retador empieza generando una clave [br]pública y una clave privada y entonces proporciona

0:10:32.659,0:10:37.254
la clave privada al adversario. Ahora el adversario [br]puede decir "Bien, aquí hay un puñado de

0:10:37.254,0:10:41.611
textos cifrados, por favor desencríptalos por mí." Así [br]que el adversario envía el texto cifrado

0:10:41.611,0:10:46.452
c1 y obtiene la desencripción del [br]texto cifrado c1, esto es, m1. Y lo repite

0:10:46.452,0:10:51.414
una y otra vez, de forma que envía el [br]texto cifrado c2 y obtiene la desencripción,

0:10:51.414,0:10:56.195
que es m2, el texto cifrado c3 y lo obtiene [br]desencriptado, m3, y así en adelante.

0:10:56.195,0:11:00.188
Finalmente, el adversario dice: "Esta fase [br]de interrogación ha acabado" y ahora

0:11:00.188,0:11:04.485
remite básicamente dos mensajes de la misma [br]longitud, m0 y m1, como es habitual, y

0:11:04.485,0:11:08.820
recibe en respuesta el texto cifrado de [br]desafío, "c", que es la encriptación de m0 o

0:11:08.820,0:11:13.052
la encriptación de m1, dependiendo de si [br]estamos en el experimento cero o el

0:11:13.052,0:11:17.003
experimento uno. Ahora el adversario puede[br]continuar enviando solicitudes de texto

0:11:17.003,0:11:21.063
cifrado. Así, puede continuar remitiendo [br]solicitudes de desencriptado. Así, el remite

0:11:21.063,0:11:25.447
un texto cifrado y recibe el texto desencriptado,[br]pero, por supuesto, ahora tiene que haver una

0:11:25.447,0:11:29.994
limitación. Si el atacante pudiese solicitar textos [br]cifrados arbitrarios de su elección,

0:11:29.994,0:11:34.270
por supuesto que podría romper el desafío. Lo [br]único que tendría que hacer es remitir al

0:11:34.270,0:11:38.506
retador el texto cifrado "c" como una solicitud de [br]desencriptado y entonces se le diría si en la

0:11:38.506,0:11:42.665
fase de desafío se le ha dado la encriptación [br]de m0 o la encriptación de m1.

0:11:42.665,0:11:46.825
Como resultado, ponemos la siguiente limitación, [br]que dice que él puede de hecho enviar cualquier

0:11:46.825,0:11:51.031
texto cifrado de su elección, excepto el texto [br]cifrado del desafío. Así, el atacante

0:11:51.031,0:11:55.034
podrá solicitar el desencriptado de cualquier [br]texto cifrado de su elección que no sea el

0:11:55.034,0:11:59.297
texto cifrado del desafío. Y, a pesar de que se le hayan [br]dado todos esos textos desencriptados, a pesar de todo

0:11:59.297,0:12:03.196
no debería ser capaz de decir si ha [br]recibido la encriptación de m0 o la

0:12:03.196,0:12:09.212
encriptación de m1. Por tanto, daros cuenta de que [br]se trata de una definición muy conservadora. Proporciona

0:12:09.212,0:12:14.113
al atacante más poder del que vimos en la [br]transparencia anterior. En la transparencia anterior,

0:12:14.113,0:12:18.710
el atacante sólo podía desencriptar mensajes [br]si el texto llano empezada con "to:attacker".

0:12:18.710,0:12:23.611
Aquí, lo que vemos es que el atacante puede [br]desencriptar cualquier texto cifrado de su elección,

0:12:23.611,0:12:29.717
siempre se que sea distinto del texto cifrado del [br]desafío, "c". ¿De acuerdo? Y entonces su

0:12:29.717,0:12:34.094
objetivo es decir si el texto cifrado del [br]desafío es la encriptación de m0 o la

0:12:34.094,0:12:37.918
encriptación de m1. Y, como es habitual, si no [br]puede hacerlo, en otras palabras, su respuesta

0:12:37.918,0:12:42.351
ante el experimento cero es básicamente la [br]misma respuesta que en el experimento

0:12:42.351,0:12:46.839
uno, sin ser capaz de diferenciar la[br]encriptación de m0 de la encriptación de

0:12:46.839,0:12:51.219
m1 a pesar del poder del que disponía, [br]entonces decimos que el sistema es semánticamente

0:12:51.219,0:12:55.877
seguro frente a ataque de texto cifrado escogido, [br]seguro CCA. En ocasiones se utiliza este acrónimo,

0:12:55.877,0:13:00.596
el acrónimo de INDistinguible frente a un Ataque [br]de texto Cifrado esCogido [IND-CCA], pero me voy

0:13:00.596,0:13:05.745
a limitar a llamarlo "seguro CCA". Así, vamos a ver [br]como esto refleja el ejemplo con el correo electrónico

0:13:05.745,0:13:10.587
que vimos antes. Supongamos que el sistema de [br]encriptación usado es tal que simplemente dada

0:13:10.587,0:13:15.429
un mensaje encriptado el atacante puede [br]cambiar el destinatario, digamos, de Alice

0:13:15.429,0:13:20.129
a Charlie. Entonces, así es como él [br]ganaría el juego CCA. Bien, en el

0:13:20.129,0:13:25.033
primer paso recibe, por supuesto, la clave [br]pública. Y entonces el atacante lo que hará

0:13:25.033,0:13:29.578
es proporcionar dos mensajes de igual longitud,[br]esto es, en el primer mensaje el cuerpo contendrá

0:13:29.578,0:13:33.943
un cero. En el segundo mensaje el cuerpo contendrá [br]un uno. Pero ambos mensajes están dirigidos a

0:13:33.943,0:13:39.890
Alice. Y, en respuesta, él recibirá el [br]texto cifrado del desafío, "c".

0:13:39.890,0:13:45.130
Bien, así que ahora tenemos nuestro texto [br]cifrado del desafío, "c". Ahora, lo que hará el

0:13:45.130,0:13:49.961
atacante es utilizar su habilidad para [br]modificar el destinatario.

0:13:49.961,0:13:55.269
Y devolverá un texto cifrado c' [c prima] [br]en el que c' es la encriptación del

0:13:55.269,0:14:01.760
mensaje para Charlie con el cuerpo del [br]desafío, "b". Esto es, si os acordáis, o

0:14:01.760,0:14:07.822
cero o uno. Ahora, como que el [br]texto llano es diferente, sabemos que

0:14:07.822,0:14:12.486
el texto cifrado debe también ser diferente. [br]En particular, c' debe ser diferente del

0:14:12.486,0:14:17.206
texto del desafío "c", ¿no es así? Esto es, [br]c' debe ser diferente de "c". Y como

0:14:17.206,0:14:21.758
consecuencia, el pobre retador ahora tiene [br]que desencriptar, por definición del juego CCA.

0:14:21.758,0:14:26.141
El retador tiene que desencriptar cualquier texto [br]crifrado que no sea igual a un texto cifrado enviado

0:14:26.141,0:14:30.648
por el retador. Así, el retador desencripta, le [br]da al adversario m'. Básicamente proporciona

0:14:30.648,0:14:35.256
al adversario "b". Y ahora el adversario [br]puede mostrar "b" como resultado del desafío

0:14:35.256,0:14:40.293
y gana el juego con ventaja 1. Así, su [br]ventaja con este esquema particular

0:14:40.293,0:14:45.143
era uno. Simplemente porque el atacante [br]era capaz de cambiar el texto cifrado del

0:14:45.146,0:14:49.999
retador de un destinatario a otro, lo [br]que le permite ganar el juego CCA con

0:14:49.999,0:14:55.003
ventaja uno. Así, como ya dije, [el modelo] de [br]seguridad de texto cifrado escogido es en

0:14:55.003,0:14:59.327
realidad la noción de seguridad correcta para los [br]sistemas de criptografía de clave pública. Y este es

0:14:59.327,0:15:03.651
un concepto muy interesante. De algún modo, [br]aunque el atacante tenga la habilidad para

0:15:03.651,0:15:07.839
desencriptar todo lo que quiera, excepto el [br]texto cifrado del desafío, no es capaz de

0:15:07.839,0:15:12.028
conocer el texto cifrado del retador. Así, lo que haremos [br]lo que haremos durante lo que queda de este módulo y,

0:15:12.028,0:15:16.275
de hecho, también el próximo, es construir [br]sistemas seguros CCA. Se tiene que

0:15:16.275,0:15:20.093
destacar que es posible y voy a [br]mostraros exactamente cómo

0:15:20.093,0:15:24.310
hacerlo. Y, de hecho, los sistemas [br]seguros CCA que construiremos

0:15:24.310,0:15:28.579
son los que se utilizan en el mundo real. [br]Y cada vez que se ha intentado implementar un

0:15:28.737,0:15:33.007
sistema de criptografía de clave pública que no ha [br]sido seguro CCA, alguien ha encontrado un

0:15:33.007,0:15:37.487
ataque y ha sido capaz de romperlo. Y vamos [br]a ver algunos ejemplos de esos ataques

0:15:37.487,0:15:39.280
en unos pocos segmentos.