¿Cuáles de ellos son preferidos en qué circunstancias?

Me gustaría ver la lista de criterios de evaluación para los distintos modos, y tal vez una discusión sobre la aplicabilidad de cada criterio.

Por ejemplo, creo que uno de los criterios es el "tamaño del código" para el cifrado y descifrado, que es importante para los sistemas integrados de microcódigo, como los adaptadores de red 802.11. SI el código requerido para implementar CBC es mucho más pequeño que el requerido para CTR (no sé si esto es cierto, es solo un ejemplo), entonces podría entender por qué sería preferible el modo con el código más pequeño. Pero si estoy escribiendo una aplicación que se ejecuta en un servidor, y la biblioteca AES que estoy utilizando implementa CBC y CTR de todos modos, entonces este criterio es irrelevante.

¿Ves lo que quiero decir con "lista de criterios de evaluación y aplicabilidad de cada criterio"?

Esto no está realmente relacionado con la programación, pero está relacionado con el algoritmo.

• El BCE no debe usarse si se encripta más de un bloque de datos con la misma clave.

• CBC, OFB y CFB son similares, sin embargo, OFB / CFB es mejor porque solo necesita cifrado y no descifrado, lo que puede ahorrar espacio en el código.

• CTR se utiliza si desea una buena paralelización (es decir, velocidad), en lugar de CBC / OFB / CFB.

• El modo XTS es el más común si está codificando datos accesibles al azar (como un disco duro o RAM).

• OCB es, con mucho, el mejor modo, ya que permite el cifrado y la autenticación en una sola pasada. Sin embargo, hay patentes sobre ello en EE. UU.

Lo único que realmente debe saber es que el BCE no se debe utilizar a menos que solo esté encriptando 1 bloque. Se debe usar XTS si está encriptando datos de acceso aleatorio y no una secuencia.

• SIEMPRE debe usar IV 's únicos cada vez que encripte, y deben ser aleatorios . Si no puede garantizar que sean aleatorios , use OCB ya que solo requiere un nonce , no un IV , y hay una clara diferencia. Un nonce no elimina la seguridad si las personas pueden adivinar el siguiente, un IV puede causar este problema.

Considere mucho si no puede evitar implementar su propia criptografía

La fea verdad del asunto es que si hace esta pregunta, probablemente no podrá diseñar e implementar un sistema seguro.

Permítame ilustrar mi punto: imagine que está creando una aplicación web y necesita almacenar algunos datos de sesión. Puede asignar a cada usuario una ID de sesión y almacenar los datos de la sesión en el servidor en un mapa hash que asigna la ID de la sesión a los datos de la sesión. Pero luego tiene que lidiar con este molesto estado en el servidor y si en algún momento necesita más de un servidor, las cosas se complicarán. Entonces, en su lugar, tiene la idea de almacenar los datos de la sesión en una cookie en el lado del cliente. Por supuesto, lo cifrará para que el usuario no pueda leer y manipular los datos. Entonces, ¿qué modo deberías usar? Viniendo aquí, lees la respuesta principal (perdón por destacarte myforwik). El primero cubierto, BCE, no es para usted, desea cifrar más de un bloque, el siguiente, CBC, suena bien y no necesita el paralelismo de CTR, no necesita acceso aleatorio, así que no hay XTS y las patentes son una PITA, así que no hay OCB Al usar su biblioteca de cifrado, se da cuenta de que necesita algo de relleno porque solo puede cifrar múltiplos del tamaño del bloque. Tu eligesPKCS7 porque se definió en algunos estándares de criptografía serios. Después de leer en algún lugar que CBC es demostrablemente seguro si se usa con un IV aleatorio y un cifrado de bloque seguro, descansa tranquilo a pesar de que está almacenando sus datos confidenciales en el lado del cliente.

Años después de que su servicio haya crecido significativamente, un especialista en seguridad de TI se comunica con usted en una divulgación responsable. Te está diciendo que puede descifrar todas tus cookies usando un ataque de oráculo de relleno , porque tu código produce una página de error si el relleno está roto de alguna manera.

Este no es un escenario hipotético: Microsoft tenía este defecto exacto en ASP.NET hasta hace unos años.

El problema es que hay muchas trampas con respecto a la criptografía y es extremadamente fácil construir un sistema que parezca seguro para el lego pero que sea trivial para un atacante conocedor.

Qué hacer si necesita cifrar datos

Para conexiones en vivo, use TLS (asegúrese de verificar el nombre de host del certificado y la cadena del emisor). Si no puede usar TLS, busque la API de más alto nivel que su sistema tiene para ofrecer para su tarea y asegúrese de comprender las garantías que ofrece y, lo que es más importante, lo que no garantiza. Para el ejemplo anterior, un marco como Play ofrece instalaciones de almacenamiento del lado del cliente , sin embargo, no invalida los datos almacenados después de un tiempo, y si cambia el estado del lado del cliente, un atacante puede restaurar un estado anterior sin que lo note.

Si no hay una abstracción de alto nivel disponible, use una biblioteca criptográfica de alto nivel. Un ejemplo destacado es NaCl y una implementación portátil con muchos enlaces de idiomas es Sodium . Al usar una biblioteca de este tipo, no tiene que preocuparse por los modos de cifrado, etc., pero debe tener aún más cuidado con los detalles de uso que con una abstracción de nivel superior, como nunca usar un nonce dos veces.

Si por alguna razón no puede usar una biblioteca criptográfica de alto nivel, por ejemplo, porque necesita interactuar con el sistema existente de una manera específica, no hay forma de educarse a fondo. Recomiendo leer Cryptography Engineering por Ferguson, Kohno y Schneier . No se engañe creyendo que puede construir un sistema seguro sin los antecedentes necesarios. La criptografía es extremadamente sutil y es casi imposible probar la seguridad de un sistema.

Comparación de los modos

Solo cifrado:

• Modos que requieren relleno : como en el ejemplo, el relleno generalmente puede ser peligroso porque abre la posibilidad de ataques de oráculo de relleno. La defensa más fácil es autenticar cada mensaje antes del descifrado. Vea abajo.
  • El BCE cifra cada bloque de datos de forma independiente y el mismo bloque de texto sin formato dará como resultado el mismo bloque de texto cifrado. Eche un vistazo a la imagen Tux encriptada del BCE en la página de Wikipedia del BCE para ver por qué este es un problema grave. No conozco ningún caso de uso en el que el BCE sea aceptable.
  • CBC tiene un IV y, por lo tanto, necesita aleatoriedad cada vez que se encripta un mensaje, cambiar una parte del mensaje requiere volver a encriptar todo después del cambio, los errores de transmisión en un bloque de texto cifrado destruyen completamente el texto sin formato y cambian el descifrado del siguiente bloque, descifrado puede ser paralelizado / el cifrado no puede, el texto plano es maleable hasta cierto punto, esto puede ser un problema .
• Modos de cifrado de flujo : estos modos generan un flujo de datos pseudoaleatorio que puede o no depender del texto sin formato. De manera similar a los cifrados de flujo en general, el flujo pseudoaleatorio generado se XOR con el texto sin formato para generar el texto cifrado. Como puede usar tantos bits de la secuencia aleatoria como desee, no necesita relleno en absoluto. La desventaja de esta simplicidad es que el cifrado es completamente maleable, lo que significa que un atacante puede cambiar el descifrado de la forma que prefiera, como un texto sin formato p1, un texto cifrado c1 y una secuencia pseudoaleatoria r y el atacante puede elegir una diferencia d tal que el descifrado de un texto cifrado c2 = c1⊕d es p2 = p1⊕d, como p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Además, la misma secuencia pseudoaleatoria nunca debe usarse dos veces como para dos textos cifrados c1 = p1⊕r y c2 = p2⊕r, un atacante puede calcular el xor de los dos textos claros como c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Eso también significa que cambiar el mensaje requiere una encriptación completa, si el atacante pudo haber obtenido el mensaje original. Todos los siguientes modos de cifrado de vapor solo necesitan la operación de cifrado del cifrado de bloque, por lo que, dependiendo del cifrado, esto podría ahorrar algo de espacio (silicio o código de máquina) en entornos extremadamente restringidos.
  • El CTR es simple, crea una secuencia pseudoaleatoria que es independiente del texto sin formato, se obtienen diferentes secuencias pseudoaleatorias contando desde diferentes nonces / IV que se multiplican por una longitud máxima de mensaje para evitar la superposición, utilizando el cifrado de mensajes nonces. posible sin aleatoriedad por mensaje, el descifrado y el cifrado se completan en paralelo, los errores de transmisión solo afectan los bits incorrectos y nada más
  • OFB también crea una secuencia pseudoaleatoria independiente del texto sin formato, se obtienen diferentes secuencias pseudoaleatorias comenzando con un IV distinto o aleatorio diferente para cada mensaje, ni el cifrado ni el descifrado son paralelizables, ya que con CTR usando el cifrado de mensajes nonces es posible sin mensaje aleatoriedad, como con los errores de transmisión CTR solo afectan los bits incorrectos y nada más
  • El flujo pseudoaleatorio de CFB depende del texto sin formato, se necesita un IV distinto o aleatorio diferente para cada mensaje, como con CTR y OFB utilizando el cifrado de mensajes nonces posible sin aleatoriedad por mensaje, el descifrado es paralelizable / no es cifrado, los errores de transmisión son completamente destruye el siguiente bloque, pero solo efectúa los bits incorrectos en el bloque actual
• Modos de cifrado de disco : estos modos están especializados para cifrar datos debajo de la abstracción del sistema de archivos. Por razones de eficiencia, el cambio de algunos datos en el disco solo debe requerir la reescritura de, como máximo, un bloque de disco (512 bytes o 4kib). Están fuera del alcance de esta respuesta, ya que tienen escenarios de uso muy diferentes a los demás. No los use para nada excepto el cifrado de disco a nivel de bloque . Algunos miembros: XEX, XTS, LRW.

Cifrado autenticado:

Para evitar ataques de oráculo de relleno y cambios en el texto cifrado, uno puede calcular un código de autenticación de mensaje (MAC) en el texto cifrado y solo descifrarlo si no ha sido manipulado. Esto se llama encrypt-then-mac y debería preferirse a cualquier otro orden . Excepto en muy pocos casos de uso, la autenticidad es tan importante como la confidencialidad (la última de las cuales es el objetivo del cifrado). Los esquemas de cifrado autenticado (con datos asociados (AEAD)) combinan el proceso de dos partes de cifrado y autenticación en un modo de cifrado de bloque que también produce una etiqueta de autenticación en el proceso. En la mayoría de los casos, esto mejora la velocidad.

• CCM es una combinación simple de modo CTR y CBC-MAC. Usar dos cifrados de cifrado de bloque por bloque es muy lento.
• OCB es más rápido pero gravado por patentes. Sin embargo, para el software libre (como en libertad) o no militar, el titular de la patente ha otorgado una licencia gratuita .
• GCM es una combinación muy rápida pero posiblemente compleja de modo CTR y GHASH, un MAC sobre el campo de Galois con 2 ^ 128 elementos. Su amplio uso en importantes estándares de red como TLS 1.2 se refleja en una instrucción especial que Intel ha introducido para acelerar el cálculo de GHASH.

Recomendación:

Teniendo en cuenta la importancia de la autenticación, recomendaría los siguientes dos modos de cifrado de bloque para la mayoría de los casos de uso (excepto para fines de cifrado de disco): si los datos se autentican mediante una firma asimétrica, use CBC; de lo contrario, use GCM.

Phil Rogaway ha realizado un análisis formal en 2011, aquí . La Sección 1.6 ofrece un resumen que transcribo aquí, agregando mi propio énfasis en negrita (si eres impaciente, entonces su recomendación es usar el modo CTR, pero te sugiero que leas mis párrafos sobre la integridad del mensaje versus el cifrado a continuación).

Tenga en cuenta que la mayoría de estos requieren que el IV sea aleatorio, lo que significa que no es predecible y, por lo tanto, debe generarse con seguridad criptográfica. Sin embargo, algunos requieren solo un "nonce", que no exige esa propiedad sino que solo requiere que no se reutilice. Por lo tanto, los diseños que dependen de un nonce son menos propensos a errores que los diseños que no lo hacen (y créanme, he visto muchos casos en los que CBC no se implementa con la selección IV adecuada). Entonces verá que he agregado negrita cuando Rogaway dice algo como "no se logra la confidencialidad cuando el IV es un nonce", significa que si elige su IV criptográficamente seguro (impredecible), entonces no hay problema. Pero si no lo hace, está perdiendo las buenas propiedades de seguridad. Nunca reutilice un IV para ninguno de estos modos.

Además, es importante comprender la diferencia entre la integridad del mensaje y el cifrado. El cifrado oculta los datos, pero un atacante podría modificarlos, y su software podría aceptar los resultados si no verifica la integridad del mensaje. Mientras que el desarrollador dirá "pero los datos modificados volverán como basura después del descifrado", un buen ingeniero de seguridad encontrará la probabilidad de que la basura cause un comportamiento adverso en el software, y luego convertirá ese análisis en un ataque real. He visto muchos casos en los que se utilizó el cifrado, pero la integridad del mensaje era realmente más necesaria que el cifrado. Entiende lo que necesitas.

Debo decir que, aunque GCM tiene cifrado e integridad de mensajes, es un diseño muy frágil: si reutilizas un IV, estás jodido: el atacante puede recuperar tu clave. Otros diseños son menos frágiles, por lo que personalmente temo recomendar GCM en función de la cantidad de código de cifrado deficiente que he visto en la práctica.

Si necesita ambos, integridad del mensaje y cifrado, puede combinar dos algoritmos: generalmente vemos CBC con HMAC, pero no hay razón para vincularse a CBC. Lo importante es saber primero cifrar, luego MAC el contenido cifrado , no al revés. Además, el IV debe ser parte del cálculo de MAC.

No estoy al tanto de los problemas de IP.

Ahora a las cosas buenas del profesor Rogaway:

Bloquear modos de cifrado, cifrado pero no integridad del mensaje

BCE : Un blockcipher, el modo cifra mensajes que son múltiplos de n bits cifrando por separado cada pieza de n bits. Las propiedades de seguridad son débiles , el método pierde la igualdad de bloques a través de las posiciones de bloque y el tiempo. De considerable valor heredado, y de valor como bloque de construcción para otros esquemas, pero el modo no logra ningún objetivo de seguridad generalmente deseable por sí mismo y debe usarse con considerable precaución; El BCE no debe considerarse como un modo de confidencialidad de "propósito general" .

CBC : un esquema de cifrado basado en IV, el modo es seguro como un esquema de cifrado probabilístico, logrando indistinguibilidad de bits aleatorios, suponiendo un IV aleatorio. La confidencialidad no se logra si el IV es simplemente un nonce , ni si es un nonce cifrado bajo la misma clave utilizada por el esquema, como sugiere incorrectamente el estándar. Los textos cifrados son altamente maleables. No se ha elegido la seguridad de ataque de texto cifrado (CCA). La confidencialidad se pierde en presencia de un oráculo de relleno correcto para muchos métodos de relleno. Cifrado ineficiente por ser inherentemente serial. Ampliamente utilizado, las propiedades de seguridad solo de privacidad del modo resultan en mal uso frecuente. Se puede utilizar como un bloque de construcción para algoritmos CBC-MAC. No puedo identificar ventajas importantes sobre el modo CTR.

CFB : un esquema de cifrado basado en IV, el modo es seguro como un esquema de cifrado probabilístico, logrando indistinguibilidad de bits aleatorios, suponiendo un IV aleatorio. La confidencialidad no se logra si el IV es predecible , ni si lo hace un nonce cifrado bajo la misma clave utilizada por el esquema, como sugiere incorrectamente el estándar. Los textos cifrados son maleables. Sin seguridad CCA. Cifrado ineficiente por ser inherentemente serial. El esquema depende de un parámetro s, 1 ≤ s ≤ n, típicamente s = 1 o s = 8. Ineficiente para necesitar una llamada blockcipher para procesar solo s bits. El modo logra una propiedad interesante de "auto-sincronización"; La inserción o eliminación de cualquier número de caracteres s-bit en el texto cifrado solo interrumpe temporalmente el descifrado correcto.

OFB : un esquema de cifrado basado en IV, el modo es seguro como un esquema de cifrado probabilístico, logrando la indistinguibilidad de bits aleatorios, suponiendo un IV aleatorio. La confidencialidad no se logra si el IV es un nonce, aunque una secuencia fija de IV (por ejemplo, un contador) funciona bien. Los textos cifrados son altamente maleables. No hay seguridad CCA. El cifrado y el descifrado son ineficientes por ser inherentemente seriales. Encripta de forma nativa cadenas de cualquier longitud de bit (no se necesita relleno). No puedo identificar ventajas importantes sobre el modo CTR.

CTR : un esquema de encriptación basado en IV, el modo logra la indistinguibilidad de bits aleatorios asumiendo un IV distinto. Como un esquema seguro sin base, el modo también se puede usar como un esquema de cifrado probabilístico, con un IV aleatorio. Falla completa de privacidad si un nonce se reutiliza en el cifrado o descifrado. La paralelización del modo a menudo lo hace más rápido, en algunas configuraciones mucho más rápido, que otros modos de confidencialidad. Un bloque de construcción importante para los esquemas de cifrado autenticado. En general, generalmente la mejor y más moderna forma de lograr un cifrado solo de privacidad.

XTS : un esquema de cifrado basado en IV, el modo funciona mediante la aplicación de un blockcipher modificable (seguro como un PRP fuerte) a cada fragmento de n bits. Para mensajes con longitudes no divisibles por n, los dos últimos bloques se tratan especialmente. El único uso permitido del modo es para encriptar datos en un dispositivo de almacenamiento con estructura de bloque. El ancho estrecho del PRP subyacente y el mal tratamiento de los bloques finales fraccionados son problemas. Más eficiente pero menos deseable que lo sería un blockcipher seguro para PRP (bloque ancho).

MAC (integridad del mensaje pero no cifrado)

ALG1–6 : Una colección de MAC, todos ellos basados ​​en el CBC-MAC. Demasiados esquemas. Algunos son demostrablemente seguros como VIL PRF, algunos como FIL PRF y otros no tienen seguridad demostrable. Algunos de los esquemas admiten ataques dañinos. Algunos de los modos están anticuados. La separación de teclas no se atiende adecuadamente para los modos que la tienen. No debe adoptarse en masa, pero es posible elegir selectivamente los "mejores" esquemas. También estaría bien no adoptar ninguno de estos modos, a favor de CMAC. Algunos de los MAC ISO 9797-1 están ampliamente estandarizados y utilizados, especialmente en la banca. Pronto se lanzará una versión revisada de la norma (ISO / IEC FDIS 9797-1: 2010) [93].

CMAC : un MAC basado en el CBC-MAC, el modo es demostrablemente seguro (hasta el cumpleaños) como un PRF (VIL) (suponiendo que el blockcipher subyacente es un buen PRP). Sobrecarga mínima para un esquema basado en CBCMAC. La naturaleza inherentemente en serie es un problema en algunos dominios de aplicación, y el uso con un blockcipher de 64 bits requeriría una nueva modificación ocasional. Más limpio que la colección ISO 9797-1 de MAC.

HMAC : un MAC basado en una función hash criptográfica en lugar de un blockcipher (aunque la mayoría de las funciones hash criptográficas se basan en blockciphers). El mecanismo disfruta de fuertes límites de seguridad comprobables, aunque no de supuestos preferidos. Múltiples variantes estrechamente relacionadas en la literatura complican la comprensión de lo que se conoce. No se han sugerido ataques dañinos. Ampliamente estandarizado y usado.

GMAC : un MAC sin base que es un caso especial de GCM. Hereda muchas de las buenas y malas características de GCM. Pero el requisito de no necesidad es innecesario para un MAC, y aquí compra pocos beneficios. Ataques prácticos si las etiquetas se truncan a ≤ 64 bits y la extensión del descifrado no se supervisa ni se reduce. Fallo completo en la no reutilización. El uso está implícito de todos modos si se adopta GCM. No recomendado para estandarización separada.

cifrado autenticado (cifrado e integridad del mensaje)

CCM : Un esquema AEAD no basado en el que combina el cifrado en modo CTR y el CBC-MAC sin procesar. Inherentemente serial, limitando la velocidad en algunos contextos. Probablemente seguro, con buenos límites, suponiendo que el blockcipher subyacente es un buen PRP. Construcción desgarbada que demostrablemente hace el trabajo. Más simple de implementar que GCM. Se puede usar como un MAC no basado en MAC. Ampliamente estandarizado y usado.

GCM : un esquema AEAD sin base que combina el cifrado en modo CTR y una función hash universal basada en GF (2128). Buenas características de eficiencia para algunos entornos de implementación. Buenos resultados demostrablemente seguros asumiendo un truncamiento mínimo de etiquetas. Ataques y límites de seguridad demostrables deficientes en presencia de truncamiento sustancial de etiquetas. Se puede usar como un MAC no basado en CA, que luego se llama GMAC. Opción cuestionable para permitir nonces que no sean 96 bits. Se recomienda restringir nonces a 96 bits y etiquetas a al menos 96 bits. Ampliamente estandarizado y usado.

1. Cualquier cosa menos el BCE.
2. Si usa CTR, es imperativo que use un IV diferente para cada mensaje; de ​​lo contrario, el atacante puede tomar dos textos cifrados y derivar un texto sin cifrar combinado. La razón es que el modo CTR esencialmente convierte un cifrado de bloque en un cifrado de flujo, y la primera regla de los cifrados de flujo es nunca usar la misma Clave + IV dos veces.
3. Realmente no hay mucha diferencia en la dificultad de implementar los modos. Algunos modos solo requieren que el cifrado de bloque funcione en la dirección de cifrado. Sin embargo, la mayoría de los cifrados de bloque, incluido AES, no requieren mucho más código para implementar el descifrado.
4. Para todos los modos de cifrado, es importante usar IV diferentes para cada mensaje si sus mensajes pueden ser idénticos en los primeros bytes, y no desea que un atacante lo sepa.

¿Has comenzado leyendo la información sobre esto en Wikipedia: modos de operación de cifrado de bloque ? Luego siga el enlace de referencia en Wikipedia a NIST: Recomendación para modos de operación de cifrado de bloque .

Es posible que desee elegir en función de lo que está ampliamente disponible. Tenía la misma pregunta y aquí están los resultados de mi investigación limitada.

Limitaciones de hardware

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM
CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Limitaciones de código abierto

Original rijndael-api source  - ECB, CBC, CFB1
OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB
OpenSSL - C/C++ API    CBC, CFB, CFB1, CFB8, ECB, OFB and CTR
EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled)  
OpenAES [2] - ECB, CBC 

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

Conozco un aspecto: aunque CBC brinda una mayor seguridad al cambiar el IV para cada bloque, no es aplicable al contenido cifrado al que se accede aleatoriamente (como un disco duro cifrado).

Por lo tanto, use CBC (y los otros modos secuenciales) para flujos secuenciales y ECB para acceso aleatorio.