Una palabra de introducción: Esta respuesta fue en parte una respuesta a muchas preguntas que he visto bajo la etiqueta [encryption] que mostraba a las personas desplegando código totalmente inseguro. Dirigiéndome a estos programadores, escribí la siguiente oración inicial con la intención de sacudirlos lo suficiente como para repensar su enfoque de la criptografía, antes de que su aplicación sea atacada. Si usted está aquí en el proceso de aprendizaje, eso es genial! Necesitamos más programadores con conocimiento de fondo en criptografía. Sigue preguntando y añade un "todavía!"a mi apertura:

Si necesita hacer esta pregunta, probablemente no sepa lo suficiente sobre criptografía para implementar un sistema seguro.

Sé que esto suena duro, así que permítanme ilustrar mi punto: Imagine que está construyendo una aplicación web y necesita almacenar algunos datos de sesión. Puede asignar a cada usuario un ID de sesión y almacenar los datos de sesión en el servidor en el mapa hash asignando el ID de sesión a los datos de sesión. Pero entonces tienes para lidiar con este estado molesto en el servidor y si en algún momento necesita más de un servidor, las cosas se complicarán. Así que en su lugar tiene la idea de almacenar los datos de 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 debes usar? Al venir aquí lees la respuesta principal (perdón por singularizarte myforwik). El primero cubierto - ECB-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, por lo que no XTS y patentes son un PITA, por lo que no 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. Elige PKCS7 porque se definió en algunos estándares de criptografía serios. Después de leer en algún lugar que CBC es probablemente seguro si se usa con un IV aleatorio y un cifrado de bloque seguro, descansa a gusto a pesar de que almacenando sus datos confidenciales en el lado del cliente.

Años más tarde, después de que su servicio haya crecido a un tamaño significativo, un especialista en seguridad de TI se pone en contacto con usted en una divulgación responsable. Te está diciendo que puede descifrar todas tus cookies usando un relleno oracle attack, 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 error exacto en ASP.NET hasta unos años hace.

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 profano, pero es trivial romper 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 emisora). 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 entender las garantías que ofrece y más importante lo que no garantiza. Para el ejemplo anterior, un framework como Play ofrece instalaciones de almacenamiento del lado del cliente, no invalida los datos almacenados después de algún tiempo, sin embargo, y si cambia el estado del lado del cliente, un atacante puede restaurar un estado anterior sin que lo note.

Si no hay abstracción de alto nivel disponible, use una biblioteca de cifrado de alto nivel. Un ejemplo destacado es NaCl y un la implementación portable con muchos enlaces de lenguaje es Sodium . Al usar una biblioteca de este tipo, no tiene que preocuparse por los modos de cifrado, etc. pero tienes que ser aún más cuidadoso 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 utilizar una biblioteca de cifrado de alto nivel, por ejemplo, porque necesita interactuar con el sistema existente de una manera específica, no hay manera de educarse a fondo. Me recomiendo leer Ingeniería criptográfica de Ferguson, Kohno y Schneier . Por favor, no te engañes creyendo que puedes construir un sistema seguro sin los antecedentes necesarios. La criptografía es extremadamente sutil y es casi imposible probar la seguridad de un sistema.

Para fines educativos una 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 padding ataques oracle. La defensa más fácil es autenticar cada mensaje antes del descifrado. Véase más adelante.
  • ECB encripta cada bloque de datos de forma independiente y el mismo bloque de texto plano resultará en el mismo bloque de texto cifrado. Echa un vistazo a la imagen de Tux cifrada 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 cifrar 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, el descifrado puede ser paralelizado / el cifrado no puede, el texto sin formato es maleable hasta cierto punto-esto puede ser un problema.
• Modos de cifrado de flujo : Estos modos generan un seudo flujo aleatorio de datos que pueden o no depender del texto sin formato. De manera similar a los cifrados de flujo en general, el flujo pseudo aleatorio generado se XORea con el texto plano 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 el descifrado puede ser cambiado por un atacante de cualquier manera que le guste como para un texto plano p1, un texto cifrado c1 y un pseudo flujo aleatorio r y el atacante puede elegir una diferencia d tales que el descifrado de un texto cifrado c2=c1⊕d es p2 = p1⊕d, como p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). También el mismo pseudo-aleatorios corriente nunca debe ser usado dos veces para dos ciphertexts c1=p1⊕r y c2=p2⊕r, un atacante puede calcular el xor de los dos plaintexts como c1⊕c2=p1⊕r⊕p2⊕r=p1⊕p2. Eso también significa que cambiar el mensaje requiere de cifrado, si el mensaje original se podrían haber obtenido un atacante. Todos los siguientes modos de cifrado de steam solo necesitan la operación de cifrado del cifrado por bloques, por lo que dependiendo del cifrado esto podría ahorrar algo de espacio (silicio o código de máquina) en entornos extremadamente restringidos.
  • CTR es simple, crea un flujo pseudo aleatorio que es independiente del texto plano, se obtienen diferentes flujos pseudo aleatorios contando desde diferentes nonces / IVs que se multiplican por una longitud máxima de mensaje para que la superposición sea prevenido, el uso de cifrado de mensajes nonces es posible sin aleatoriedad por mensaje, el descifrado y el cifrado se completan paralelizables, los errores de transmisión solo afectan los bits incorrectos y nada más
  • OFB también crea un flujo pseudo aleatorio independiente del texto plano, se obtienen diferentes flujos pseudo aleatorios comenzando con un nonce o IV aleatorio diferente para cada mensaje, ni el cifrado ni el descifrado son paralelizables, como con CTR usando nonces el cifrado de mensajes es posible sin aleatoriedad por mensaje, ya que con los errores de transmisión CTR solo afectan los bits incorrectos y nada más
  • CFB's pseudo random stream depende del texto plano, un nonce diferente o IV aleatorio es necesario para cada mensaje, como con CTR y OFB usando nonces el cifrado de mensajes es posible sin aleatoriedad por mensaje, el descifrado es paralelizable / el cifrado no lo es, los errores de transmisión destruyen efecto de los bits incorrectos en el bloque actual
• Modos de cifrado de disco: Estos modos están especializados para cifrar los datos por debajo de la abstracción del sistema de archivos. Por razones de eficiencia, cambiar 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 otros. No los use para nada excepto para el disco de nivel de bloque cifrado. Algunos miembros: XEX, XTS, LRW.

Cifrado autenticado:

Para evitar ataques de relleno de oracle y cambios en el texto cifrado, se 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 debe ser preferido a cualquier otro orden. Excepto en muy pocos casos de uso, la autenticidad es tan importante como la confidencialidad (esta última 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 por bloques que también produce una etiqueta de autenticación en el proceso. En la mayoría de los casos, esto se traduce en una mejora de la velocidad.

• CCM es una simple combinación de modo CTR y un CBC-MAC. El uso de dos cifrados por bloque es muy lento.
• OCB es más rápido pero gravado por patentes. Para software libre (como en libertad) o no militar, el titular de la patente ha concedido una licencia libre, sin embargo.
• 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 estándares de red importantes como TLS 1.2 se refleja en una instrucción especial que Intel ha introducido para acelerar el cálculo de GHASH.

Recomendación:

Considerando la importancia de la autenticación Recomendaría los siguientes dos modos de cifrado por bloques para la mayoría de los casos de uso (excepto para fines de cifrado de disco): Si los datos están autenticados por una firma asimétrica, use CBC, de lo contrario, use GCM.

1. Cualquier cosa menos BCE.
2. Si usa CTR, es imperativo que use un IV diferente para cada mensaje, de lo contrario, terminará con el atacante siendo capaz de tomar dos textos cifrados y derivar un texto sin cifrar combinado. La razón es que el modo CTR esencialmente convierte un cifrado por bloques 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 lo difícil que son los modos de implementar. Algunos modos solo requiere que el cifrado por bloques opere en la dirección de cifrado. Sin embargo, la mayoría de los cifrados de bloque, incluido el AES, no necesitan mucho más código para implementar el descifrado.
4. Para todos los modos de cifrado, es importante usar IVs diferentes para cada mensaje si sus mensajes podrían ser idénticos en los primeros bytes, y no desea que un atacante lo sepa.

Un análisis formal ha sido realizado por Phil Rogaway en 2011, aquí. La sección 1.6 da un resumen que transcribo aquí, agregando mi propio énfasis en negrita (si está impaciente, entonces su recomendación es usar el modo CTR, pero sugiero que lea 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 el CBC no se implementa con una selección IV adecuada). Así que verá que he añadido negrita cuando Rogaway dice algo como "la confidencialidad no se logra 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, entonces está perdiendo las buenas propiedades de seguridad. Nunca reutilice un IV para ninguno de estos modos.

Además, es importante entender la diferencia entre la integridad del mensaje y el cifrado. El cifrado oculta los datos, pero un atacante podría ser capaz de modificar los datos cifrados, y los resultados pueden ser potencialmente aceptados por su software si no comprueba 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 necesaria más que el cifrado. Entiende lo que necesitas.

Debo decir que aunque GCM tiene tanto cifrado como integridad del mensaje, es un diseño muy frágil: si reutilizas una vía intravenosa, estás jodido the el atacante puede recuperar su clave. Otros diseños son menos frágiles, así que personalmente tengo miedo de recomendar GCM basado en la cantidad de código de cifrado pobre 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 atarse a CBC. Lo importante a saber es cifrar primero, luego MAC el contenido cifrado, no al revés. Además, el IV debe ser parte de el cálculo de MAC.

No tengo conocimiento de problemas de PI.

Ahora a las cosas buenas del profesor Rogaway:

Modos de cifrado de bloque, cifrado pero no integridad del mensaje

ECB : Un blockcipher, el modo de cifrar mensajes que son un múltiplo de n bits al cifrar por separado cada pieza de n bits. Las propiedades de seguridad son débiles, el método filtra la igualdad de bloques a través de las posiciones de bloque y el tiempo. De considerable valor heredado, y de valor como un bloque de construcción para otros sistemas, pero el modo de no lograr ningún generalmente deseable de seguridad objetivo en su propio derecho y debe utilizarse con gran precaución; BCE no debe ser considerado como un "propósito general" confidencialidad modo.

CBC : Un esquema de cifrado basado en IV, el modo es seguro como un esquema de cifrado probabilístico, logrando indistinguibilidad de bits aleatorios, asumiendo un IV aleatorio. La confidencialidad no se logra si el IV es meramente un nonce , ni si es un nonce cifrado bajo la misma clave utilizada por el esquema, como el estándar sugiere incorrectamente. Los textos cifrados son altamente maleables. Seguridad de ataque de texto cifrado (CCA) no elegida. La confidencialidad se pierde en presencia de un oráculo de relleno correcto para muchos métodos de relleno. El cifrado ineficiente por ser inherentemente serial. Ampliamente utilizado, las propiedades de seguridad de solo privacidad del modo resultan en un uso indebido 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, asumiendo un IV aleatorio. La confidencialidad no se logra si el IV es predecible, ni si se hace por un nonce cifrado bajo la misma clave utilizada por el esquema, como el estándar sugiere incorrectamente. Ciphertexts son maleables. No CCA-seguridad. Cifrado ineficiente por ser inherentemente serial. Scheme depende de un parámetro s, 1 ≤ s ≤ n, típicamente s = 1 o s = 8. Ineficiente para necesitar una llamada a blockcipher para procesar solo s bits . El modo logra una interesante propiedad 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 indistinguibilidad de bits aleatorios, asumiendo un IV aleatorio. La confidencialidad no se logra si el IV es un nonce, aunque una secuencia fija de IVs (por ejemplo, un contador) funciona bien. Los textos cifrados son altamente maleables. No hay seguridad CCA. Cifrado y descifrado ineficiente por ser inherentemente serial. Encripta de forma nativa cadenas de cualquier longitud de bits (no se necesita relleno). No puedo identificar ventajas importantes sobre el modo CTR.

CTR : Un esquema de cifrado basado en IV, el modo logra indistinguibilidad de bits aleatorios asumiendo un nonce IV. Como un esquema seguro basado en nonce, el modo también se puede usar como un esquema de cifrado probabilístico, con un IV aleatorio. Fallo completo de privacidad si un nonce se reutiliza en el cifrado o descifrado. La paralelizabilidad del modo a menudo lo hace más rápido, en algunos ajustes mucho más rápido, que otros modos de confidencialidad. Un componente importante para los esquemas de cifrado autenticado. En general, por lo general la mejor y más moderna manera de logre un cifrado solo de privacidad.

XTS : Un esquema de cifrado basado en IV, el modo funciona aplicando un blockcipher modificable (seguro como un strong-PRP) 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 cifrar datos en un dispositivo de almacenamiento estructurado en bloques. El ancho estrecho del PRP subyacente y el mal tratamiento de los bloques finales fraccionados son problemas. Más eficiente pero menos deseable de lo que sería un blockcipher PRP-secure de bloque ancho.

MACs (integridad del mensaje pero no cifrado)

ALG1-6: Una colección de MACs, todos ellos basados en el CBC-MAC. Demasiados esquemas. Algunos son probablemente seguros como VIL PRFs, algunos como FIL PRFs, y algunos no tienen seguridad demostrable. Algunos de los esquemas admiten ataques dañinos. Algunos de los modos están fechados. La separación de claves no es atendida adecuadamente para los modos que la tienen. No debe adoptarse en masa, pero elegir selectivamente los "mejores" esquemas es posible. También estaría bien no adoptar ninguno de estos modos, a favor de CMAC. Algunos de los MACs ISO 9797-1 están ampliamente estandarizados y utilizados, especialmente en la banca. Pronto se publicará 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 probablemente seguro (hasta el límite de cumpleaños) como un (VIL) PRF (asumiendo que el blockcipher subyacente es un buen PRP). Esencialmente mínimo gastos generales para un esquema basado en CBCMAC. Inherentemente la naturaleza serial es un problema en algunos dominios de aplicación, y su uso con un blockcipher de 64 bits requeriría una re-keying ocasional. Más limpio que la colección ISO 9797-1 de MACs.

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 blockcipher). El mecanismo goza de fuertes límites de seguridad demostrables, aunque no a partir de suposiciones preferidas. Múltiples variantes estrechamente relacionadas en la literatura complican la comprensión de lo que se conoce. Nunca se han sugerido ataques dañinos. Ampliamente estandarizado y utilizado.

GMAC : Un MAC basado en nonce que es un caso especial de GCM. Hereda muchas de las características buenas y malas de GCM. Pero el nonce-requisito es innecesario para una MAC, y aquí compra poco beneficio. Ataques prácticos si las etiquetas se truncan a ≤ 64 bits y el alcance del descifrado no se supervisa y reducido. Fallo completo en nonce-reuse. El uso está implícito de todos modos si se adopta GCM. No recomendado para estandarización separada.

Cifrado autenticado (tanto cifrado como integridad del mensaje)

CCM : Un esquema AEAD basado en nonce que combina el cifrado en modo CTR y el raw CBC-MAC. Inherentemente serial, limitando la velocidad en algunos contextos. Provably secure, with good bounds, assuming the underlying blockcipher is a good PRP. Construcción desgarbada que demostrablemente hace el trabajo. Más simple de implementar que GCM. Se puede utilizar como un MAC basado en nonce. Ampliamente estandarizado y utilizado.

GCM : Un esquema AEAD basado en nonce que combina 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 provably-secure asumiendo truncamiento mínimo de la etiqueta. Ataques y límites de seguridad demostrables pobres en presencia de truncamiento sustancial de la etiqueta. Se puede utilizar como un MAC basado en nonce, que luego se llama GMAC. Opción cuestionable para permitir nonces distintos de 96 bits. Recomendamos restringir los nonce a 96 bits y las etiquetas a al menos 96 bits. Ampliamente estandarizado y utilizado.

¿Ha comenzado leyendo la información sobre esto en Wikipedia - Modos de operación de cifrado por bloques? Luego siga el enlace de referencia en Wikipedia a NIST: Recommendation for Block Cipher Modes of Operation.

Es posible que desee elegir en función de lo que está ampliamente disponible. Tuve 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 da mejor seguridad al cambiar el IV para cada bloque, no es aplicable al contenido encriptado al azar (como un disco duro encriptado).

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