¿Cómo elegir un modo de cifrado AES (CBC ECB CTR OCB CFB)?

Solución:

Considere mucho si no puede 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ítanme ilustrar mi punto: Imagine que está creando 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 la sesión en el servidor en un ID de sesión de mapeo de mapa hash a los datos de la sesión. Pero luego tienes que lidiar con este estado molesto en el servidor y si en algún momento necesitas 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í, leíste la respuesta principal (perdón por destacarte 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, así que no XTS y las patentes son un PITA, por lo que no OCB. Al usar su biblioteca de criptografía, se da cuenta de que necesita algo de relleno porque solo puede cifrar múltiplos del tamaño del bloque. Elija PKCS7 porque se definió en algunos estándares de criptografía serios. Después de leer en alguna parte que CBC es demostrablemente seguro si se usa con un IV aleatorio y un cifrado de bloque seguro, puede estar tranquilo a pesar de que está 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 comunica con usted en una divulgación responsable. Ella le está diciendo que puede descifrar todas sus cookies usando un ataque de oráculo de relleno, porque su 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 profano pero que sea trivial de romper para un atacante informado.

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 Jugar ofrece facilidades 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 usted se dé cuenta.

Si no hay una abstracción de alto nivel disponible, utilice una biblioteca de cifrado 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. Para la creación de protocolos personalizados (digamos que desea algo como TLS, pero no sobre TCP o UDP), existen marcos como Noise e implementaciones asociadas que hacen la mayor parte del trabajo pesado por usted, pero su flexibilidad también significa que hay mucho margen de error. , si no comprende en profundidad lo que hacen todos los componentes.

Si por alguna razón no puede usar una biblioteca de cifrado de alto nivel, por ejemplo, porque necesita interactuar con el sistema existente de una manera específica, no hay forma de evitar educarse a fondo. Recomiendo leer Ingeniería en criptografía de Ferguson, Kohno y Schneier. No se engañe creyendo que puede crear 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 relleno de Oracle. La defensa más sencilla es autenticar cada mensaje antes de descifrarlo. Vea abajo.
  • ECB 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 de Tux encriptada por ECB en la página de Wikipedia de ECB para ver por qué esto es un problema grave. No conozco ningún caso de uso en el que ECB 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 por completo 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 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 desee, como para un texto plano p1, un texto cifrado c1 y un flujo pseudoaleatorio r y el atacante puede elegir una diferencia d tal que el descifrado de un texto cifrado c2 = c1⊕d es p2 = p1⊕d, ya que p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Además, el mismo flujo pseudoaleatorio 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 planos como c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Eso también significa que cambiar el mensaje requiere un reencriptado completo, si el mensaje original pudo haber sido obtenido por un atacante. 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.
  • CTR es simple, crea una secuencia pseudoaleatoria que es independiente del texto plano, se obtienen diferentes secuencias pseudoaleatorias contando desde diferentes nonces / IVs que se multiplican por una longitud máxima de mensaje para evitar la superposición, el uso de cifrado de mensajes nonces es posible sin aleatoriedad por mensaje, el descifrado y el cifrado se completan en paralelo, los errores de transmisión solo afectan a los bits incorrectos y nada más
  • DE B también crea una secuencia pseudoaleatoria independiente del texto plano, se obtienen diferentes secuencias pseudoaleatorias comenzando con un nonce diferente o un IV aleatorio para cada mensaje, ni el cifrado ni el descifrado son paralelizables, ya que con CTR usando nonces el cifrado de mensajes es posible sin aleatoriedad por mensaje , como con CTR, los errores de transmisión solo afectan los bits incorrectos y nada más.
  • CFBEl flujo pseudoaleatorio depende del texto plano, se necesita un nonce diferente o IV aleatorio para cada mensaje, como con CTR y OFB, el cifrado de mensajes nonces es posible sin aleatoriedad por mensaje, el descifrado es paralelizable / el cifrado no lo es, los errores de transmisión destruyen por completo el siguiente bloque, pero solo afectan los bits incorrectos en el bloque actual
• Modos de cifrado de disco: Estos modos están especializados para cifrar datos por 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 un bloque de disco como máximo (512 bytes o 4kib). Están fuera del alcance de esta respuesta, ya que tienen escenarios de uso muy diferentes al otro. No los use para nada que no sea el cifrado de disco a nivel de bloque. 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 encriptar-luego-mac y debe preferirse a cualquier otro orden. Excepto en muy pocos casos de uso, la autenticidad es tan importante como la confidencialidad (el último de los cuales es el objetivo del cifrado). Los esquemas de cifrado autenticado (con datos asociados (AEAD)) combinan el proceso de cifrado y autenticación de dos partes en un modo de cifrado de un bloque 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 combinación simple de modo CTR y CBC-MAC. El uso de cifrados de cifrado de dos bloques por bloque es muy lento.
• OCB es más rápido pero está gravado por patentes. Sin embargo, para software gratuito (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 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:

Teniendo en cuenta la importancia de la autenticación, recomendaría los siguientes dos modos de cifrado de bloques 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, utilice CBC; de lo contrario, utilice GCM.

• ECB no debe utilizarse si se cifra 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 aleatoriamente (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, existen patentes en EE. UU.

Lo único que realmente debe saber es que ECB no debe usarse a menos que solo esté encriptando 1 bloque. Se debe usar XTS si está encriptando datos a los que se accede aleatoriamente y no una transmisión.

• SIEMPRE debe usar IV únicos cada vez que encripta, 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 diferencia clara. Un nonce no pierde seguridad si la gente puede adivinar el siguiente, un IV puede causar este problema.

A Phil Rogaway realizó un análisis formal en 2011, aquí. La sección 1.6 brinda un resumen que transcribo aquí, agregando mi propio énfasis en negrita (si está impaciente, entonces su recomendación es usar el modo CTR, pero le 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 solo requieren un “nonce”, que no exige esa propiedad, sino que solo requiere que no se reutilice. Por lo tanto, los diseños que se basan en 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 de IV adecuada). Entonces verá que agregué 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, está perdiendo las buenas propiedades de seguridad. Nunca reutilice una vía intravenosa para cualquiera de estos modos.

Además, es importante comprender la diferencia entre la integridad y el cifrado de los mensajes. El cifrado oculta los datos, pero es posible que un atacante pueda modificar los datos cifrados, y el software puede potencialmente 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 provoque 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ó cifrado, pero la integridad de los mensajes se necesitaba más que el cifrado. Comprenda lo que necesita.

Debo decir que aunque GCM tiene tanto cifrado como 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 tengo miedo de recomendar GCM en función de la cantidad de código de cifrado deficiente que he visto en la práctica.

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

No tengo conocimiento de problemas de propiedad intelectual.

Ahora a las cosas buenas del profesor Rogaway:

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

ECB: Un cifrado en bloque, el modo cifra los 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 que filtra la igualdad de bloques en las posiciones y el tiempo de los bloques. De considerable valor heredado y de valor como componente básico para otros esquemas, pero el modo no logra ningún objetivo de seguridad generalmente deseable por derecho propio y debe usarse con considerable precaución; El BCE no debe considerarse 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 la indistinguibilidad de los bits aleatorios, asumiendo 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 muy maleables. Sin seguridad de ataque de texto cifrado (CCA) elegido. La confidencialidad se pierde en presencia de un oráculo de relleno correcto para muchos métodos de relleno. El cifrado es ineficaz por ser intrínsecamente serial. Ampliamente utilizado, las propiedades de seguridad de solo privacidad del modo dan como resultado un uso indebido frecuente. Puede usarse 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 la indistinguibilidad de los bits aleatorios, asumiendo un IV aleatorio. La confidencialidad no se logra si la vía intravenosa es predecible, ni si está hecho por 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. El cifrado es ineficaz por ser intrínsecamente serial. El esquema depende de un parámetro s, 1 ≤ s ≤ n, típicamente s = 1 os = 8. Ineficiente para necesitar una llamada de 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.

DE B: Un esquema de cifrado basado en IV, el modo es seguro como un esquema de cifrado probabilístico, logrando la indistinguibilidad de los 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 muy maleables. Sin seguridad CCA. El cifrado y el descifrado son ineficaces por ser intrínsecamente en serie. Cifra 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 la indistinguibilidad de los bits aleatorios asumiendo un IV nonce. Como esquema seguro basado en nonce, el modo también se puede utilizar como esquema de cifrado probabilístico, con un IV aleatorio. Fallo total de la privacidad si un nonce se reutiliza en el cifrado o descifrado. La capacidad de paralelizar el modo a menudo lo hace más rápido, en algunos entornos, mucho más rápido que otros modos de confidencialidad. Un componente importante para los esquemas de cifrado autenticado. En general, suele ser la mejor y más moderna forma de lograr el cifrado solo para la privacidad.

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

MAC (integridad del mensaje pero no cifrado)

ALG1–6: Una colección de MAC, todos ellos basados ​​en CBC-MAC. Demasiados esquemas. Algunos son demostrablemente seguros como VIL PRF, algunos como FIL PRF y algunos no tienen seguridad demostrable. Algunos de los esquemas admiten ataques dañinos. Algunos de los modos están anticuados. La separación de claves 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 se utilizan, 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 CBC-MAC, el modo es demostrablemente seguro (hasta el límite de cumpleaños) como un (VIL) PRF (asumiendo que el blockcipher subyacente es un buen PRP). Sobrecarga esencialmente mínima para un esquema basado en CBCMAC. La naturaleza intrínsecamente serial es un problema en algunos dominios de aplicación, y el uso con un cifrador de bloques de 64 bits requeriría un cambio de clave ocasional. Más limpio que la colección de MAC ISO 9797-1.

HMAC: Un MAC basado en una función hash criptográfica en lugar de un cifrado en bloque (aunque la mayoría de las funciones hash criptográficas se basan en sí mismas en cifrados en bloque). El mecanismo disfruta de fuertes límites de seguridad demostrable, aunque no a partir de supuestos preferidos. Varias 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 usado.

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 requisito de nonce es innecesario para un MAC, y aquí ofrece pocos beneficios. Ataques prácticos si las etiquetas se truncan a ≤ 64 bits y el grado de descifrado no se supervisa ni se reduce. Fallo total en la no reutilización. El uso es 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 CBC-MAC sin procesar. Inherentemente serial, velocidad limitante en algunos contextos. Probablemente seguro, con buenos límites, asumiendo que el cifrado de bloques subyacente es un buen PRP. Construcción desgarbada que demuestra que hace el trabajo. Más sencillo de implementar que GCM. Se puede utilizar como MAC basado en nonce. Ampliamente estandarizado y usado.

GCM: Un esquema AEAD basado en nonce 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 un importante truncamiento de etiquetas. Se puede utilizar como MAC basado en nonce, que luego se llama GMAC. Elección cuestionable para permitir nonces distintos de 96 bits. Se recomienda restringir los nonces a 96 bits y las etiquetas a al menos 96 bits. Ampliamente estandarizado y usado.

Valoraciones y comentarios

Si eres capaz, puedes dejar un enunciado acerca de qué te ha parecido este post.

---

---

Utiliza Nuestro Buscador