Modos de operación: Un bloque no basta: ECB, CBC, CTR, GCM

Un cifrado en bloque es un objeto precioso con un trabajo pequeño: transforma 16 bytes en 16 bytes con una clave. Los mensajes reales son más largos, tienen longitudes arbitrarias y se envían muchos con la misma clave. Un modo de operación convierte el cifrado en bloque en un cifrado de mensajes. Elegirlo mal puede deshacer todo el trabajo del capítulo anterior: el AES más fuerte en un modo débil es un cifrado débil.

ECB: el libro de códigos

El modo ingenuo, electronic codebook (libro de códigos electrónico), corta el mensaje en bloques y cifra cada uno por separado: $c_{i} = E_{k} (m_{i})$ . Es un libro de códigos gigantesco con $2^{128}$ entradas, y tiene el defecto de todos los libros de códigos: bloques de texto en claro iguales dan bloques cifrados iguales. Lo que se repite en el texto en claro se repite en el cifrado.

El «pingüino ECB», con un candado en lugar de Tux. La imagen está guardada con un byte por píxel, así que sus zonas lisas son series de bloques de 16 bytes idénticos. Cifrada con AES real en modo ECB, cada bloque idéntico se convierte en el mismo bloque cifrado, y la forma sobrevive. CBC y CTR, con la misma clave, la convierten en ruido.

Proposición (el cifrado determinista revela igualdades)

Ningún esquema de cifrado determinista, en el que el mismo mensaje con la misma clave da siempre el mismo texto cifrado, puede ser semánticamente seguro frente a un adversario que ve varios textos cifrados: cifrar dos veces el mismo mensaje se nota. El cifrado seguro tiene que ser aleatorizado (un IV aleatorio nuevo) o con estado (un contador, un nonce que no se repite nunca).

ECB sigue apareciendo en la práctica. En 2013 se filtraron 153 millones de contraseñas de Adobe, cifradas con triple DES en modo ECB, y los investigadores encontraron las más comunes contando textos cifrados idénticos y leyendo las pistas de contraseña que los usuarios habían dejado al lado. La aplicación de escritorio ofrece ECB por compatibilidad con cryptoKit 1.0 y lo marca en rojo.

CBC: encadenar con un IV

El encadenamiento de bloques cifrados (CBC), patentado por Ehrsam, Meyer, Smith y Tuchman en IBM en 1976 y estandarizado junto con DES en 1980, combina cada bloque de texto en claro con el bloque cifrado anterior antes de cifrarlo; el primero se combina con un vector de inicialización:

c_{0} = IV, c_{i} = E_{k} (m_{i} \oplus c_{i - 1}), m_{i} = D_{k} (c_{i}) \oplus c_{i - 1} .

Ahora bloques iguales del texto en claro dan bloques cifrados distintos, porque lo que entra en $E_{k}$ es diferente cada vez. El IV debe ser impredecible: TLS 1.0 usaba como IV el último bloque cifrado del mensaje anterior, y en 2011 el ataque BEAST aprovechó esa previsibilidad para descifrar cookies. El IV no es secreto: viaja delante del texto cifrado, que es lo que hace la aplicación de escritorio cuando dejas vacío el campo IV.

Relleno

CBC cifra bloques completos, así que el mensaje se rellena. El esquema estándar, PKCS#7, añade $n$ bytes de valor $n$ , de 1 a 16; un mensaje que ya llena su último bloque recibe un bloque extra entero de dieciséis bytes de valor 16, para que el relleno siempre se pueda quitar sin ambigüedad.

El relleno PKCS#7. El mensaje se corta en bloques de 16 bytes; los bytes resaltados son el relleno. Escribe un mensaje de exactamente 16 caracteres para ver el bloque extra.

El relleno se convirtió en un arma. En 2002 Serge Vaudenay mostró que si un servidor revela si el relleno de un mensaje descifrado es válido (con un mensaje de error, o simplemente tardando más), un atacante puede descifrar cualquier texto cifrado, byte a byte, enviando versiones modificadas: un oráculo de relleno. Sus variantes rompieron ASP.NET en 2010, TLS en 2013 (Lucky Thirteen) y SSL 3.0 en 2014 (POODLE). CBC no está roto, pero es muy fácil usarlo de forma insegura.

CTR: un cifrado en bloque se vuelve de flujo

El modo contador, propuesto por Diffie y Hellman en 1979, cifra valores sucesivos de un contador y combina los resultados con el mensaje mediante XOR:

c_{i} = m_{i} \oplus E_{k} (nonce ‖ i) .

No necesita relleno, es paralelo (cada bloque se calcula por separado, en todos los núcleos) y solo usa el sentido de cifrado del cifrado en bloque. Es un cifrado de flujo: un flujo de clave pseudoaleatorio combinado con los datos, la versión computacional de la libreta de un solo uso. Y hereda su única regla.

Proposición (repetir el nonce)

Si dos mensajes se cifran en modo CTR con la misma clave y el mismo nonce, entonces $c_{1} \oplus c_{2} = m_{1} \oplus m_{2}$ : el flujo de clave se cancela y el atacante vuelve a tener la libreta de dos usos.

Cifrar no es proteger la integridad

CTR tiene una segunda propiedad que sorprende a mucha gente: es maleable. Invertir un bit del texto cifrado invierte exactamente el mismo bit del texto descifrado. Un atacante que conozca (o adivine) parte de un mensaje puede convertirlo en cualquier otro de la misma longitud sin conocer la clave: $c^{'} = c \oplus (m \oplus m^{'})$ se descifra como $m^{'}$ . CBC también es maleable, de una forma algo más enrevesada.

Editar un texto cifrado sin la clave. Una orden de pago se cifra con AES; el atacante conoce su formato y quiere cambiar el importe y el beneficiario. En modo CTR, el texto cifrado falsificado se descifra exactamente como el texto del atacante. En GCM (AES-GCM real del WebCrypto de tu navegador), la misma edición se detecta: la etiqueta de autenticación ya no coincide y el descifrado falla.

La confidencialidad no basta: los sistemas reales necesitan cifrado autenticado. Una forma es añadir un código de autenticación de mensajes. El orden importa.

Teorema (Bellare y Namprempre, 2000)

Si el esquema de cifrado es seguro frente a ataques de texto en claro elegido y el MAC es fuertemente infalsificable, entonces cifrar y luego autenticar (cifrar y después autenticar el texto cifrado) da cifrado autenticado, seguro frente a ataques de texto cifrado elegido. Autenticar y luego cifrar, o cifrar y autenticar por separado, no lo dan en general.

SSH usaba cifrar-y-autenticar, TLS autenticar-y-luego-cifrar (de ahí los oráculos de relleno), IPsec cifrar-y-luego-autenticar. En lugar de dejar la composición a cada protocolo, los criptógrafos diseñaron modos que hacen las dos cosas a la vez: AEAD, cifrado autenticado con datos asociados.

GCM: modo contador con un polinomio

El modo Galois/Counter, de David McGrew y John Viega (2004, NIST SP 800-38D en 2007), cifra con CTR y autentica con GHASH, un polinomio evaluado en el cuerpo $GF (2^{128})$ . Con la clave de hash $H = E_{k} (0^{128})$ y los bloques del texto cifrado (y de los datos asociados) $X_{1}, \dots, X_{n}$ ,

{GHASH}_{H} (X) = X_{1} H^{n} \oplus X_{2} H^{n - 1} \oplus \dots \oplus X_{n} H,

y la etiqueta de 16 bytes es $T = {GHASH}_{H} (X) \oplus E_{k} (J_{0})$ , donde $J_{0}$ se deriva del nonce. Dos mensajes distintos dan dos polinomios distintos, y un polinomio de grado $n$ tiene como mucho $n$ raíces, así que una falsificación tiene éxito con probabilidad como mucho de unos $n / 2^{128}$ . Los datos asociados (una cabecera, un número de paquete, el identificador de una fila de la base de datos) se autentican pero no se cifran: no se pueden cambiar sin que se detecte.

GCM es rápido (los procesadores tienen instrucciones de multiplicación sin acarreo para GHASH), paralelo y el modo por defecto de TLS 1.3. También es implacable: si alguna vez se repite un nonce, el atacante puede despejar $H$ (el «ataque prohibido» de Antoine Joux, 2006) y falsificar cualquier mensaje. Un rastreo de Internet de 2016 encontró 184 servidores HTTPS que repetían nonces de GCM. Con nonces aleatorios de 96 bits, el NIST limita una clave a $2^{32}$ mensajes. La aplicación de escritorio genera un nonce aleatorio salvo que escribas uno, y te avisa si lo haces.

ChaCha20-Poly1305

No todos los procesadores tienen instrucciones AES; los móviles de principios de la década de 2010 no las tenían, y el AES por software es lento y filtra información por los tiempos de la caché. ChaCha20 (2008), de Daniel J. Bernstein, es un cifrado de flujo construido solo con sumas de 32 bits, rotaciones y XOR («ARX»), rápido y de tiempo constante por naturaleza en software; Poly1305 (2005) es un autenticador de un solo uso que evalúa un polinomio módulo el primo $2^{130} - 5$ . Juntos, tal como los estandarizan la RFC 7539 (2015) y la RFC 8439, forman un AEAD que usan TLS 1.3, SSH, WireGuard y el QUIC de Google. AES-GCM y ChaCha20-Poly1305 aparecen como recomendados en la aplicación de escritorio.

¿Qué modo elegir?

Modo	Qué da	Qué vigilar
ECB	nada más allá de un bloque	nunca para datos: se ven los patrones
CBC	confidencialidad	IV impredecible; oráculos de relleno; añadir un MAC
CTR	confidencialidad, en paralelo	no repetir nunca el nonce; maleable; añadir un MAC
GCM	cifrado autenticado	no repetir nunca el nonce
ChaCha20-Poly1305	cifrado autenticado	no repetir nunca el nonce

Para saber más

Serge Vaudenay, «Security Flaws Induced by CBC Padding», EUROCRYPT 2002.
Mihir Bellare y Chanathip Namprempre, «Authenticated Encryption: Relations among Notions and Analysis of the Generic Composition Paradigm», ASIACRYPT 2000.
David McGrew y John Viega, «The Galois/Counter Mode of Operation (GCM)» (2004); NIST SP 800-38D (2007).
Yoav Nir y Adam Langley, RFC 8439, ChaCha20 and Poly1305 for IETF Protocols (2018).

§ECB: el libro de códigos

§CBC: encadenar con un IV

Relleno

§CTR: un cifrado en bloque se vuelve de flujo

§Cifrar no es proteger la integridad

§GCM: modo contador con un polinomio

§ChaCha20-Poly1305

§¿Qué modo elegir?

§Para saber más