0:00:00.000,0:00:03.837
En este segmento, vamos a construir sistemas de cifrado autenticado. A partir de

0:00:03.837,0:00:08.250
haber conseguido cifrado seguro CPA y tener MACs seguros, la pregunta obvia

0:00:08.250,0:00:12.824
es si podemos combinar los dos de alguna manera, a fin de obtener cifrado autenticado.

0:00:12.824,0:00:15.721
Y eso es exactamente lo que vamos a hacer en este segmento. El cifrado autenticado

0:00:15.721,0:00:20.447
fue introducido en el año 2000, en dos informes independientes que indicaré al

0:00:20.447,0:00:25.915
final de este módulo. Antes de eso, muchas librerías criptográficas proporcionaban una API que,

0:00:25.915,0:00:31.215
por separado, admitían cifrado seguro CPA, y MACing. Así que había una

0:00:31.215,0:00:36.175
función para implementar el cifrado seguro CPA, por ejemplo, CBC con

0:00:36.175,0:00:41.136
IV aleatorio, y otra función para implementar MAC. Y a continuación, cada desarrollador que

0:00:41.136,0:00:45.646
quería implementar el cifrado, tenía que llamar por separado al esquema de

0:00:45.646,0:00:50.552
cifrado CPA y al esquema de MAC. En concreto, cada desarrollador tuvo que inventar

0:00:50.552,0:00:55.697
su propio modo de combinar MAC-ing y cifrado para proporcionar algún tipo de

0:00:55.697,0:00:59.376
cifrado autenticado. Pero los objetivos de la combinación de cifrado y MAC-ing

0:00:59.376,0:01:03.690
no fueron bien entendidos ya que el cifrado autenticado no había sido definido aún.

0:01:03.690,0:01:08.497
No estaba muy claro qué combinaciones de cifrado y MAC-ing eran correctos y

0:01:08.497,0:01:13.243
cuales no. Y como dije, cada proyecto tuvo que inventar su propia combinación.

0:01:13.243,0:01:17.202
Y de hecho, no todas las combinaciones eran correctas. Y les puedo decir ya que

0:01:17.202,0:01:22.556
el error más común en proyectos software fue básicamente combinar incorrectamente los

0:01:22.556,0:01:27.025
mecanismos de cifrado e integridad. Así que esperemos que, al final de este módulo, usted

0:01:27.025,0:01:31.260
sepa cómo combinarlos correctamente y no cometer estos errores.

0:01:31.260,0:01:35.174
Analicemos algunas combinaciones de cifrado seguro CPA y

0:01:35.174,0:01:39.303
MAC, que fueron introducidas por los diferentes proyectos. Aquí hay tres ejemplos.

0:01:39.303,0:01:43.816
En primer lugar, en los tres ejemplos hay una clave independiente para el cifrado, y

0:01:43.816,0:01:47.774
otra clave independiente para integridad. Estas dos claves son independientes una de otra, y

0:01:47.774,0:01:52.224
ambas se generan en tiempo de instalación de la sesión.[br]Y vamos a ver cómo generar estas

0:01:52.224,0:01:57.071
dos claves más adelante en el curso. El primer ejemplo es el protocolo SSL.

0:01:57.071,0:02:02.681
El modo en que SSL combina cifrado y MAC con la esperanza de lograr cifrado autenticado

0:02:02.681,0:02:07.656
es la siguiente. Básicamente toma el texto plano m, y luego calcula el MAC

0:02:07.656,0:02:13.415
de ese texto plano m. De esta forma, se usa la clave MAC Ki, para calcular la etiqueta de este mensaje

0:02:13.415,0:02:17.787
m. Y, a continuación, se anexa la etiqueta al mensaje y se cifra la

0:02:17.787,0:02:22.580
combinación de mensaje y etiqueta, obteniendo el texto cifrado final.

0:02:22.580,0:02:26.710
Esta es la opción número uno. La segunda opción es lo que hace IPsec.

0:02:26.710,0:02:31.160
Aquí, tomamos el mensaje, y lo primero que se hace es cifrar el mensaje.

0:02:31.160,0:02:35.692
Y, a continuación, calcular una etiqueta a partir del texto cifrado resultante. Obsérvese que la

0:02:35.692,0:02:40.238
etiqueta se calcula sobre el texto cifrado resultante. Una tercera opción es lo que hace

0:02:40.238,0:02:45.429
el protocolo SSH. Aquí, el SSH toma el mensaje y lo cifra utilizando un

0:02:45.429,0:02:50.944
esquema de cifrado seguro CPA. Y a continuación se agrega una etiqueta al mensaje. La

0:02:50.944,0:02:55.567
diferencia entre IPsec y SSH, es que en IPsec la etiqueta es calculada a partir del

0:02:55.567,0:02:59.988
texto cifrado, mientras que en SSH la etiqueta se calcula a partir del mensaje. Por tanto, estas

0:02:59.988,0:03:04.536
son tres formas completamente diferentes de combinar cifrado y MAC. Y la

0:03:04.536,0:03:09.090
cuestión es cual de ellos es seguro.[br]Por tanto, le permitiré pensar en esto un

0:03:09.090,0:03:12.105
segundo y luego seguiremos y juntos haremos el análisis. Muy bien. Vamos a

0:03:13.197,0:03:17.164
comenzar con el método SSH. En el método SSH observará que la etiqueta se calcula

0:03:17.164,0:03:21.629
en el mensaje y, a continuación se concatena en claro en el texto cifrado. Esto es

0:03:21.629,0:03:26.407
realmente un problema porque MAC por sí mismo no está diseñado para proporcionar

0:03:26.407,0:03:30.784
confidencialidad. MAC sólo está diseñado para integridad. Y de hecho, no hay

0:03:30.784,0: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

0:03:36.008,0:03:41.458
texto. Salidas de unos bits del mensaje M.[br]Eso sería una etiqueta perfectamente bien. Y si

0:03:41.458,0:03:46.667
hicimos que rompería completamente seguridad CPA aquí, porque algunos bits de

0:03:46.667,0:03:51.815
el mensaje se filtró en el texto cifrado.[br]Y así el SSH enfoque, aunque el

0:03:51.815,0:03:56.595
características de SSH son finos y el periódico propio no se vea comprometido por

0:03:56.595,0:04:00.818
Esta combinación específica, generalmente es recomendable no utilizar este enfoque. Simplemente

0:04:00.818,0:04:05.928
debido a la salida de la max firma de ritmo posible fuga bits del mensaje. Por lo tanto

0:04:05.928,0:04:11.481
Ahora analicemos SSL y IBSEC. Según parece, el método recomendado en realidad

0:04:11.481,0:04:16.556
es el método IBSEC. Porque resulta que no importa qué sistema seguro de CPA y mac

0:04:16.556,0:04:21.134
clave que se utiliza la combinación siempre es va a proporcionar encriptación autenticada.

0:04:21.134,0:04:26.070
Permítanme explicar muy brevemente por qué.[br]Básicamente lo que sucede es que una vez que ciframos

0:04:26.070,0:04:31.005
el mensaje bien el mensaje de contenido ahora está oculto dentro del texto de cypher y ahora

0:04:31.005,0:04:35.761
cuando nos calcular una etiqueta de texto cypher básicamente nos estamos bloqueo, los bloqueos de esta etiqueta

0:04:35.761,0:04:40.815
el texto de cypher y hace que nadie puede producir un texto de cypher diferentes que

0:04:40.815,0:04:45.314
aspecto válido. Y como resultado este enfoque asegura que cualquier modificación a la

0:04:45.314,0:04:49.555
Cypher texto será detectado por el decrypter simplemente porque no la mac

0:04:49.555,0:04:54.026
va a comprobar. Pues resulta que, por el enfoque SSL, realmente hay tipo de

0:04:54.026,0:04:59.348
ejemplos patológicos, donde se combina CPA sistema de cifrado seguro con un seguro

0:04:59.348,0:05:03.542
MAC. Y el resultado es vulnerable a un ataque de texto cifrado elegido, por lo que lo hace

0:05:03.542,0:05:07.978
en realidad no proporcionan cifrado autenticado. Básicamente, la razón y que

0:05:07.978,0:05:12.824
podría suceder, es que hay algún tipo de una mala interacción entre el cifrado

0:05:12.824,0:05:17.319
esquema y el algoritmo de MAC. Tal que, de hecho, habrá un cifrado elegido

0:05:17.319,0:05:21.752
ataque de texto. Así que si va a diseñar un nuevo proyecto ahora la recomendación es

0:05:21.752,0:05:26.162
siempre uso entonces cifrar Mac debido a que es seguro no importa qué CPA segura

0:05:26.162,0:05:30.607
cifrado y el algoritmo seguro de Mac que está combinando. Ahora, sólo para establecer la

0:05:30.607,0:05:37.995
terminología, el método SSL se denomina Mac. Y, a continuación, cifrar. Y el

0:05:37.995,0:05:45.039
Se llama al método de IP-SEC cifrar luego Mac[br]El método [inaudible] a pesar de su

0:05:45.039,0:05:51.898
no supone que para usarlo, se llama cifrar y Mac. Muy bien, por lo que a menudo va a:

0:05:51.898,0:05:57.002
cifrar y MAC y MAC y cifrar para diferenciar SSL y IP sec. Okay, tan

0:05:57.002,0:06:02.112
sólo para repetir lo que he de acaba. El método [inaudible] ip cifrar siempre en mac

0:06:02.112,0:06:07.160
nos proporcionan un cifrado indicado. Si inicia desde [inaudible] y un mac seguro.

0:06:07.160,0:06:11.110
Siempre obtendrá cifrado autenticado. Como dije, [inaudible] en

0:06:11.110,0:06:15.737
hecho, hay casos patológicos donde el resultado es vulnerable a hechos de ECP y

0:06:15.737,0:06:20.308
por lo tanto no proporciona cifrado autenticado. Sin embargo, la historia s un poco

0:06:20.308,0:06:24.653
poco más interesante que eso, que resulta que, si realmente está utilizando

0:06:24.653,0:06:29.224
aleatorios a modo de contador o CBC aleatorio, entonces resulta que, para los particulares

0:06:29.224,0:06:33.625
Esquemas de cifrado seguro de CPA, [inaudible] realmente proporcionar autenticado

0:06:33.625,0:06:38.028
cifrado y por lo tanto es seguro. De hecho, hay incluso una más interesante

0:06:38.028,0:06:42.334
Twist aquí que si utiliza el modo contador aleatorios. Entonces, es suficiente

0:06:42.334,0:06:46.804
que el algoritmo de Mac solo una vez segura. No tiene que ser un completo

0:06:46.804,0:06:51.561
Mac seguro. Sólo tiene que ser seguro cuando se utiliza una clave para cifrar un mensaje único,

0:06:51.561,0:06:56.088
¿bien? Y cuando hablamos de la integridad del mensaje, vimos que hay realmente

0:06:56.088,0:07:00.575
Macs mucho más rápidos que una vez seguro que Macs que son totalmente seguras. Como un

0:07:00.575,0:07:04.454
resultado, si está utilizando el modo de contador aleatorios MAC cifrar podría realmente

0:07:04.454,0:07:08.187
como resultado de un mecanismo de cifrado más eficaz. Sin embargo, voy a repetir

0:07:08.187,0:07:12.213
Esto otra vez. La recomendación es utilizar cifrar entonces MAC y nos vamos a ver un

0:07:12.213,0:07:16.093
número de ataques a sistemas que no utilizan entonces cifrar Mac Y así hacer

0:07:16.093,0:07:20.120
seguro cosas son seguras sin tener que pensar demasiado sobre ello. Una vez más, estoy

0:07:20.120,0:07:24.118
va a recomienda que siempre utilice luego cifrar Mac Ahora, una vez el concepto de

0:07:24.118,0:07:27.759
cifrado autenticado se hizo más popular, estandarizado de un número de

0:07:27.759,0:07:31.609
criterios para la combinación de cifrado y Mac activado. Y esos fueron incluso

0:07:31.609,0:07:35.978
estandarizado por el Instituto Nacional de estándares. Por lo que sólo me va a mencionar tres

0:07:35.978,0:07:41.031
de estas normas. Dos de ellos fueron estandarizados por el NIST. Y estos son

0:07:41.031,0:07:46.138
llamado Galois modo de contador y contador CBC. Y así que Permítanme explicar lo que hacen.

0:07:46.138,0:07:51.245
Modo de contador de Galois básicamente utiliza cifrado de modo de contador, por lo tanto un contador aleatorio

0:07:51.245,0:07:56.164
modo con una MAC Carter-Wagmon, por lo que un hecho Carter Wagmon Mac. Y la forma del

0:07:56.164,0:08:01.146
Carter Wagmon MAC funciona en GCM es básicamente es una función de hash del mensaje

0:08:01.146,0:08:06.311
está siendo MACed. Y, a continuación, el resultado se encriptan usando un PRF. Ahora esta hash

0:08:06.311,0:08:11.562
función de GCM ya es bastante rápido hasta el punto donde el grueso de la marcha

0:08:11.562,0:08:15.845
tiempo de GCM está dominada por el cifrado de modo de contador y incluso hizo más

0:08:15.845,0:08:22.371
en Intel introduce una instrucción especial PCLMULQDQ específicamente

0:08:22.371,0:08:27.432
diseñado para el propósito de hacer la función de hash en ejecución GCM tan rápido como

0:08:27.432,0:08:32.950
posible. Ahora CCM Com módem es otra perdida estándar utiliza un Mac de CBC. Y

0:08:32.950,0:08:37.276
a continuación, cifrado de modo de contador. Así que este mecanismo, usted sabe, esto utiliza MAC, entonces

0:08:37.276,0:08:40.906
cifrar, como SSL. Así que esto realmente no es la manera recomendada de hacerlo

0:08:40.906,0:08:44.023
las cosas, pero contador [inaudible] se utiliza el cifrado de modo. Esto es realmente un

0:08:44.023,0:08:47.945
mecanismo de cifrado perfectamente bien. Una cosa que me gustaría señalar sobre

0:08:47.945,0:08:53.799
MCC, es que todo se basa en AES.[br]Observará que está usando AES para el CBC

0:08:53.799,0:08:58.778
MAC y lo está usando AES para el cifrado de modo de contador. Y como resultado, puede CCM

0:08:58.778,0:09:03.084
aplicarse con relativamente poco código. ?Hacer todo lo que necesita es un motor AES

0:09:03.084,0:09:08.343
y nada más. Debido a esto, CCM realmente fue aprobado por la Wi-Fi

0:09:08.343,0:09:13.963
Alianza, y de hecho, probablemente utilizas CCM diariamente si utilizas

0:09:13.963,0:09:19.093
cifrado Wi-Fi, 80211I. A continuación, utiliza básicamente ccm cifrar el tráfico

0:09:19.093,0:09:23.450
entre el portátil y el punto de acceso.[br]Hay otro modo llamado un eax que

0:09:23.450,0:09:28.922
utiliza cifrado de modo de contador y, a continuación, cmac. Por lo tanto, otra vez notará cifrar y mac

0:09:28.922,0:09:31.906
y eso es una aleta, otro modo fino a utilizar. Haremos una comparación de todos estos

0:09:31.906,0:09:36.806
modos en tan sólo un minuto. Ahora quisiera mencionar que en primer lugar, todas estas son

0:09:36.806,0:09:41.190
basado en nonce. En otras palabras, no utilizan ningún aleatoriedad pero tienen como

0:09:41.190,0:09:46.360
entrada un nonce y el nonce tiene que ser único por clave. En otras palabras, como usted

0:09:46.360,0:09:50.600
Recuerde que debe repetir nunca, nunca la nonce común clave par. Pero el

0:09:50.600,0:09:53.851
nonce sí necesitan no ser aleatorio, por lo que es perfectamente bien para utilizar un contador, para

0:09:53.851,0:09:57.520
ejemplo, como un [inaudible]. Y el otro punto importante es que, en realidad, todos

0:09:57.520,0:10:01.384
Estos modos son lo que denomina cifrado autenticado con asociados

0:10:01.384,0:10:04.936
datos. Se trata de una extensión de cifrado autenticado, pero que viene

0:10:04.936,0:10:10.884
hasta muy a menudo en protocolos de red. Así que la idea entre AEAD. Es que, de hecho,

0:10:10.884,0:10:15.223
el mensaje siempre es que el modo de cifrado no está pensado para ser plenamente

0:10:15.223,0:10:19.924
cifrado. Sólo una parte del mensaje pretende ser cifrada, pero todos los

0:10:19.924,0:10:24.157
mensaje pretende ser autenticado. Un buen ejemplo de esto es un paquete de red.

0:10:24.157,0:10:29.408
Piensa como un paquete ip donde hay un encabezado. Y, a continuación, hay una carga y

0:10:29.408,0:10:33.157
normalmente es el encabezado no va a ser codificado. Por ejemplo, podría el encabezado

0:10:33.157,0:10:36.905
contener el destino del paquete, pero entonces el encabezado había mejor no

0:10:36.905,0:10:40.950
enrutadores cifrados del camino no saben dónde enrutar el paquete.

0:10:40.950,0:10:45.225
Y por lo tanto, normalmente se envía el encabezado de la clara, que la carga, por supuesto, es

0:10:45.225,0:10:49.500
siempre cifrada, pero qué gustaría hacer es tener el encabezado de ser autenticado.

0:10:49.500,0:10:55.907
No cifrados por autenticado. Esto es exactamente lo que estos modos AEAD, do. Ellos

0:10:55.907,0:11:00.033
será autenticar el encabezado y, a continuación, cifre la carga. Pero el encabezado y

0:11:00.033,0:11:04.177
la carga están enlazados juntos en la autenticación para que la autenticación no se puede

0:11:04.177,0:11:07.803
realmente estar separados. Así que esto no es difícil de hacer. Lo que sucede en estos

0:11:07.803,0:11:14.170
tres modos de GCM, CCM y EAX, básicamente el MAC se aplica a los datos de todos. Pero

0:11:14.170,0:11:18.852
el cifrado se aplica solamente a la parte de los datos que necesita ser codificado. Por lo tanto

0:11:18.852,0:11:22.983
Quería mostrarles lo que un cifrado de API [inaudible] autenticado con

0:11:22.983,0:11:28.716
asociados parecen esquemas de cifrado de datos. Así que aquí es lo que parece

0:11:28.716,0:11:33.609
[inaudible]. Por ejemplo, esto es, una API para GCM. Así que lo que haces es llamar a la

0:11:33.609,0:11:37.404
a mediados de función para inicializar el cifrado modo y le aviso le darle una clave y

0:11:37.404,0:11:40.609
nonce. El nonce nuevamente, no tiene que ser aleatorio, pero tiene que

0:11:40.609,0:11:44.402
ser único. Y después de la inicialización, sería llamar a esta función de cifrar, donde

0:11:44.402,0:11:48.169
ves que da los datos asociados que se va a ser autenticado, pero

0:11:48.169,0:11:51.794
no cifrada. Se le da los datos, y se va a ser tanto autentica y

0:11:51.794,0:11:55.752
cifrado. Y le da vuelta el texto cifrado completo, que es un cifrado de la

0:11:55.752,0:11:59.582
datos, pero por supuesto no incluye la AAD, porque la AAD es va a ser enviado

0:11:59.582,0:12:04.535
[inaudible]. Así que ahora que comprendemos este modo de cifrar luego MAC, podemos ir

0:12:04.535,0:12:09.951
volver a la definición de MAC seguridad y podemos explicarle algo que podría

0:12:09.951,0:12:13.970
han sido un poco oscuro cuando analizamos esa definición. Así que si te acuerdas,

0:12:13.970,0:12:18.570
uno de los requisitos que siguieron desde nuestra definición de MACs seguros significa que

0:12:18.570,0:12:25.689
dado un mensaje par MAC en un mensaje M, el atacante no puede producir otra etiqueta en

0:12:25.689,0:12:30.386
el mismo mensaje M. En otras palabras, aunque el atacante ya tiene una etiqueta para

0:12:30.386,0:12:34.771
el mensaje M, él shouldn? t ser capaz de producir una nueva etiqueta para el mismo mensaje M.

0:12:34.771,0:12:39.382
Y realmente no está claro, ¿por qué eso importa? A quién le importa si el adversario ya

0:12:39.382,0:12:44.038
¿tiene una etiqueta en el mensaje de M? ¿A quién le importa si él puede producir otra etiqueta? Así, resulta

0:12:44.038,0:12:48.828
que el MAC no tiene esta propiedad. En otras palabras, dado un mensaje

0:12:48.828,0:12:53.618
Par de MAC, puede producir otra MAC en el mismo mensaje y, a continuación, sería MAC

0:12:53.618,0:12:58.694
como resultado un modo inseguro de MAC cifrados.[br]Y por lo tanto, si queremos que nuestro MAC cifrado a

0:12:58.694,0:13:03.961
integridad self-adjust, es crucial que nuestra seguridad MAC implicaría una fuerte

0:13:03.961,0:13:08.910
noción de seguridad, que, por supuesto, no es porque hemos definido correctamente.

0:13:08.910,0:13:13.613
Así que vamos a ver lo que podría salir mal, si, de hecho, era fácil producir este tipo de

0:13:13.613,0:13:18.081
falsificación. Por lo tanto lo que haremos es te voy a mostrar un ataque de texto cifrado elegido en el

0:13:18.081,0:13:22.784
resultando cifrar, luego sistema Mac. Y dado que el sistema tiene un texto cifrado elegido

0:13:22.784,0:13:27.193
ataque, significa necesariamente que no proporciona un autenticado

0:13:27.193,0:13:31.458
cifrado. Así que vamos a ver. Así que empieza a gonnna del adversario mediante el envío de dos

0:13:31.458,0:13:35.861
mensajes, M0 y M1. Y él se va a recibir, como de costumbre, el cifrado de una

0:13:35.861,0:13:39.522
de ellos, el cifrado de M0 o el cifrado de M1. Y ya que estamos

0:13:39.522,0:13:44.907
uso de cifrar, el Mac, el adversario recibe un texto cifrado llamaremos a una c

0:13:44.907,0:13:49.883
cero y Mac en el texto cifrado c cero.[br]Pues ahora hemos dicho que el mac de

0:13:49.883,0:13:53.827
un mensaje el adversario puede producir otro mac en el mismo mensaje. Y qué

0:13:53.827,0:13:57.994
él es va a hacer es que se va a producir otro mac en el mensaje de CO. Ahora él tiene

0:13:57.994,0:14:03.532
un nuevo cypher texto, CO, T prime, que es un texto de cypher perfectamente válida. Primo de t es un

0:14:03.532,0:14:09.558
mac válida de CO. Por lo tanto, el adversario ahora puede enviar una consulta de texto elegido cypher

0:14:09.558,0:14:14.492
C prime y esto es un texto válido cypher elegido consulta porque es diferente

0:14:14.492,0:14:19.288
de C. Es un nuevo texto de cifrado. El challenger pobre ahora se ve obligado a descifrar esto

0:14:19.288,0:14:23.278
primer texto c de cifrado por lo que él va a volver a enviar el descifrado de c prime. Es un

0:14:23.278,0:14:29.093
el texto cifrado válidos, por tanto, el descifrado de prime c es el mensaje MB pero ahora el

0:14:29.093,0:14:32.318
atacante sólo aprendió el valor de b porque él puede probar si MB es igual a

0:14:32.318,0:14:37.371
M0 o MB es igual al M1. Como resultado de él sólo puede salida b y saca ventaja

0:14:37.371,0:14:43.468
uno. En la alimentación del sistema. Y así otra vez si no implica nuestra seguridad mac

0:14:43.468,0:14:48.471
Esta propiedad aquí. Entonces, habrá un elegido [inaudible] un cifrar en mac. Y

0:14:48.471,0:14:53.181
por lo tanto, no sería seguro. Por lo tanto el hecho de que definimos seguridad Mac correctamente

0:14:53.181,0:14:57.241
significa que cifrar y Mac realmente proporcionan cifrado autenticado. Y

0:14:57.241,0:15:01.728
a lo largo de todas las Macs que hablamos realmente satisfacer esta noción fuerte de

0:15:01.728,0:15:06.146
unforgeability. Así, curiosamente, esto no es el final de la historia. Por lo tanto, como dijimos

0:15:06.146,0:15:10.385
antes de que se introdujo el concepto de cifrado autenticado todos era

0:15:10.385,0:15:15.295
sólo la combinación de macs y cifrado de diversas maneras con la esperanza de lograr

0:15:15.295,0:15:19.201
algunos, algunos cifrado autenticado. Después de la noción de cifrado autenticado

0:15:19.201,0:15:23.553
fue formalizado y rigurosa un poco comenzó arañando sus cabezas y dijo:

0:15:23.553,0:15:28.130
bueno, espere un minuto. Quizás logremos cifrado autenticado más eficiente

0:15:28.130,0:15:32.722
que mediante la combinación de un mac y un esquema de cifrado. De hecho, si uno piensa en cómo

0:15:32.722,0:15:37.366
Esta combinación de MAC y encriptación funciona, digamos que combinamos a modo de contador

0:15:37.366,0:15:42.134
con CMAC, entonces para cada bloque de texto, en primer lugar tiene que utilizar

0:15:42.134,0:15:46.419
el cifrado por bloques a modo de contador y, a continuación, tiene que utilizar para el cifrado por bloques

0:15:46.419,0:15:51.357
una vez más, para el CBC-MAC. Esto significa que si usted combina CPA seguro cifrado con una

0:15:51.357,0:15:55.943
MAC, para cada bloque de texto, tienes que evaluar dos veces, el cifrado por bloques

0:15:55.943,0:16:00.535
una vez para MAC y una vez en el esquema de cifrado. Así que la pregunta natural

0:16:00.535,0:16:05.396
fue, nosotros podemos construir un esquema de cifrado autenticado directamente desde un PRP

0:16:05.396,0:16:10.345
tal que tendríamos que evaluar sólo el PRP una vez por bloque. Y resulta

0:16:10.345,0:16:14.117
la respuesta es sí y hay estas hermosa construcción llamada TOC, que

0:16:14.117,0:16:18.343
muy bonita hace todo lo que desee y es mucho más rápido que las construcciones que son

0:16:18.343,0:16:22.467
construido por separado a partir de un cifrado y un Mac. Así que escribí abajo, tipo de un esquema

0:16:22.467,0:16:26.290
de OCD. No quiero explicar en detalle. Sólo un poco a explicarlo en un

0:16:26.290,0:16:30.025
alto nivel. Así que aquí tenemos a la entrada de texto, aquí en la parte superior. Y usted

0:16:30.025,0:16:34.540
Observe que, en primer lugar, TOC es paralyzable, completamente paralyzable. Por lo tanto

0:16:34.540,0:16:39.700
cada bloque puede cifrarse por separado de cada otro bloque. La otra cosa que

0:16:39.700,0:16:44.338
aviso es que como lo prometido es deuda, sólo evaluar su cifrado en bloque una vez por la llanura

0:16:44.338,0:16:49.318
bloque de texto. Y, a continuación, se evalúa una vez más al final para construir su

0:16:49.318,0: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

0:16:53.887,0:16:58.749
mínima. Todo lo que tienes que hacer es evaluar una determinada función muy simple clave que la

0:16:58.749,0:17:02.844
no [inaudible] en el p observará, la clave entra en esta p y, a continuación, hay una

0:17:02.844,0:17:08.238
contador de bloque que va en este p. Tan sólo evaluar esta función P, dos veces

0:17:08.238,0:17:12.748
para cada bloque y el resultado antes y después de utilizar cifrado XOR el

0:17:12.748,0: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

0:17:17.553,0:17:22.241
y eficiente esquema de cifrado autentica construido a partir de una cifra de bloque. Así OCB

0:17:22.241,0:17:26.065
realmente tiene un teorema de seguridad agradable asociado y voy a punto

0:17:26.065,0:17:29.567
un libro sobre OCB cuando lleguemos al final de este módulo donde te enumero algunas más

0:17:29.567,0:17:34.457
lectura de documentos que pueden echar un vistazo. Por lo que podría estar preguntándose si la OCB es así

0:17:34.457,0:17:40.168
mucho mejor que todo lo que has visto hasta ahora todas estas tres normas MCC, GCM y

0:17:40.168,0:17:46.037
EAX ¿por qué no utilizan OCB o por qué no OCB el estándar? Y la respuesta es un

0:17:46.037,0:17:50.729
poco triste. La CBC de respuesta primaria [inaudible] no está siendo utilizada es realmente porque

0:17:50.729,0:17:54.567
de varias patentes. Y sólo podrá dejarlo en ese. Para concluir esta sección I

0:17:54.567,0:17:58.216
quería mostrarle algunos números de rendimiento. Así que aquí a la derecha aparece

0:17:58.216,0:18:02.368
números de rendimiento de modos que no debería estar utilizando. Así que esto es para

0:18:02.368,0:18:07.879
modo de contador aleatorios y esto es para CBC aleatorio. Y se puede ver también el

0:18:07.879,0:18:12.460
rendimiento de CBC MAC es básicamente el mismo que el rendimiento de cifrado CBC.

0:18:12.460,0:18:16.221
Muy bien. Y aquí están los modos de cifrado autenticado, por lo que estos son los

0:18:16.221,0:18:20.083
que se supone que utilizando, estos se supone no estar usando en su

0:18:20.083,0:18:23.795
derecho propio. Estos dos nunca debe utilizar estos dos porque ellos sólo

0:18:23.795,0:18:27.858
proporcionar seguridad habilitados en la CPA, realmente no proporcionan seguridad contra activo

0:18:27.858,0:18:31.669
ataques. Sólo se supone utilizar cifrado autenticado para el cifrado.

0:18:31.669,0:18:35.509
Y así se trata de sus números de rendimiento para las tres normas. Y me permito recordar

0:18:35.509,0:18:40.109
básicamente lo GCM utiliza un hash muy rápido. Y, a continuación, utiliza el modo de contador para

0:18:40.109,0:18:43.770
cifrado real. Y se puede ver que es la sobrecarga de GCM a modo de contador

0:18:43.770,0:18:49.554
relativamente pequeño. CCM y EAX usan un sitio de bloque para una codificación base y una

0:18:49.554,0:18:54.627
sitio de bloque para mac base. Y como resultado su sobre dos veces como lento como contador

0:18:54.627,0:18:59.196
modos. Se ve que la OCB es realmente el más rápido de estos, principalmente porque se

0:18:59.196,0:19:03.820
sólo utilice el cifrado de bloque por bloque de mensaje. Por lo tanto basado en estas rendimiento

0:19:03.820,0:19:08.328
números, uno pensaría que el GCM es exactamente el modo correcto para usar siempre. Pero

0:19:08.328,0:19:12.659
resulta que si estás en el hardware de espacio limitado, GCM no es ideal.

0:19:12.659,0:19:16.709
Sobre todo porque su aplicación requiere código mayor que los otros dos

0:19:16.709,0:19:21.323
modos. Sin embargo, como ya he dicho, Intel específicamente agrega instrucciones para acelerar

0:19:21.323,0:19:26.064
modo de GCM. Y como resultado, aplicación de GCM sobre una arquitectura [inaudible] toma

0:19:26.064,0:19:30.315
muy poco código. Pero en otras plataformas de hardware, visto en tarjetas inteligentes u otros

0:19:30.315,0:19:34.745
entornos limitados, los sitios de código para implementar GCM sería considerablemente

0:19:34.745,0: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

0:19:39.387,0:19:43.928
es el modo correcto de utilizar. Para resumir este segmento quiere decir que uno más

0:19:43.928,0:19:48.267
tiempo cuando desea cifrar mensajes que tienes que utilizar una autenticación

0:19:48.267,0:19:52.716
modo de cifrado y la manera recomendada de hacerlo es utilizar uno de los estándares,

0:19:52.716,0:19:57.037
principalmente uno de estos tres modos para proporcionar autenticación cifrado. No

0:19:57.037,0:19:59.846
aplicar el esquema de cifrado, en otra palabras generar, implementar cifrar

0:19:59.846,0:20:05.842
y mac usted mismo. Sólo tiene que utilizar uno de estos tres estándares. Muchos cifrar las bibliotecas

0:20:05.842,0:20:10.513
ahora prever estos tres modos de ABI estándar y estos son los de uno que debe

0:20:10.513,0:20:14.347
estar utilizando y nada más. En el siguiente segmento vamos a ver qué otra cosa puede

0:20:14.347,0:20:17.500
salir mal cuando se intenta implementar un cifrado sonicated.