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


480

¿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.


22
"Esto no está realmente relacionado con la programación, pero está relacionado con el algoritmo". ∵ los algoritmos se pueden representar con matemáticas. ∵ la programación de computadoras puede ser presentada por matemática. ∴ su pregunta es sobre programación de computadoras.
Tyler Gillies

41
"Esto no está realmente relacionado con la programación, pero está relacionado con el algoritmo". ∵ los algoritmos pueden ser representados por las matemáticas, y los mercados de valores pueden representarse por las matemáticas, su pregunta es sobre los mercados de valores. / Perdón por el sarcasmo, pero si bien la conclusión era muy obvia, el argumento era muy obvio
Shien

Depende de la comprensión de las relaciones a las que se suscribe. Algo no necesariamente tiene que estar relacionado solo con un concepto u otro.
Bryan Grace

Respuestas:


326
  • 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.

65
CBC, OFB y CFB están lejos de ser idénticos.
Jonathan Leffler

22
CTR es susceptible de paralelización porque puede dividir el mensaje en fragmentos, cada fragmento tiene un rango de valores de contador asociados y encriptar (o descifrar) cada fragmento de forma independiente. Por el contrario, CFB se basa en la salida del bloque anterior como una de las entradas al siguiente, por lo que es rigurosamente secuencial e inherentemente no paralelizable. Similar para los otros modos mencionados.
Jonathan Leffler

99
Incluso si está encriptando solo un bloque, el BCE no debe usarse si está encriptando ese bloque más de una vez (incluso posiblemente más de una vez) con la misma clave.
yfeldblum

23
... ¿cómo una respuesta que dice "CBC, OFB y CFB son idénticos" no tiene un solo voto negativo?
Michael Mrozek

30
GCM es muy similar a OCB (rendimiento y otras propiedades), pero no está sujeto a ninguna patente, por lo que es la mejor opción. El único inconveniente es el hecho de que la implementación es muy compleja, pero no tiene que preocuparse por eso si usa una biblioteca.
ntoskrnl

409

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.


214
"Si necesita hacer esta pregunta, probablemente no sepa lo suficiente sobre criptografía para implementar un sistema seguro". - Tienes razón, pero ¿te das cuenta de que hacer preguntas es cómo aprende la gente? Así que quizás relájate un poco.
Robert MacLean

70
@RobertMacLean Verdadero, pero a diferencia de muchos otros campos en TI, no obtendrá la seguridad correcta por prueba y error. Mientras que con el diseño web, la escalabilidad de la aplicación, etc., puede verificar activamente sus requisitos, probar aspectos de seguridad varía de difícil a imposible. Lamentablemente, esa es una lección que rara vez se enseña. La mayoría de los recursos le dicen cómo funciona la criptografía y no las innumerables formas en que falla en la práctica sin que usted sea consciente de ello. La única salida es saber mucho sobre el tema. Y esa es la moral de la publicación:
Perseidas

8
Invierta suficiente tiempo para conocer a fondo la criptografía o evítela en la medida de lo posible y utilice fuertes abstracciones. Y en el tema de aprender cómo la criptografía rompe el primer párrafo es mucho más sobre el tema que la descripción de los modos.
Perseidas

33
Menos uno: el titular inicial es incorrecto; debería decir "Si haces esta pregunta, vas en la dirección correcta, ¡sigue así y sobresaldrás!"
Henrik

11
@FerminSilva: Cierto, pero otro aspecto del argumento es que a menudo es más fácil usar soluciones verdaderas y probadas que copiar y pegar código criptográfico. Por ejemplo, cuando todo lo que quiere hacer es hablar con su servidor desde una aplicación de teléfono inteligente, es mucho más simple configurar un proxy inverso de Apache con un certificado Let's Encrypt TLS y escribir https://your.serveren todas partes en su aplicación, que inventar algún protocolo de intercambio de claves y haga que las bibliotecas de criptografía de ambos lados trabajen juntas sin problemas.
Perseidas

36

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
Modo GCM: dado que la mayoría de los SO tienen poco o ningún conocimiento del cifrado, no usarán ningún modo correctamente, generalmente no usan autenticación y, a menudo, usan el modo ECB El modo GCM es probablemente la mejor opción aquí . Desafortunadamente, la falta de implementaciones de la plataforma, en algunos casos (iOS), no hay soporte del proveedor, la investigación deficiente en muchos casos, la falta de soporte de hardware es actualmente problemática. De lo contrario, es bueno para los no iniciados en el cifrado, ya que tiene autenticación incorporada y parece ser el futuro.
zaph

3
Modo CTR: no estoy de acuerdo con el modo CTR como la mejor opción debido a tantas fallas en la práctica, principalmente la reutilización IV. Incluso Microsoft lo ha estropeado al menos un par de veces.
zaph

1
Modo CBC: Probablemente, el modo más común y el modo más utilizado en SO, ECB (que no se debe usar) se exceptúan. Las principales fallas de uso son un IV no aleatorio, pero estamos viendo usos más correctos con un CSPRNG. Los oráculos de relleno, aunque son un problema, se remedia fácilmente al ignorar y no devolver los errores de relleno. Algunas implementaciones (por ejemplo, Common Crypto) no informan errores de relleno en una forma esencialmente exitosa de evitarlos a nivel API.
zaph

1
IMO CTR es peor porque es un simple xor donde CBC tiene propagación de bloque a bloque al igual que otros modos. Puede parecer fácil, pero ha habido fallas importantes en el código del mercado masivo.
zaph

1
Al leer el documento vinculado parece que solo se obtiene la clave de autenticación, no la clave de cifrado de la reutilización nonce. Esa no parece ser la afirmación en los comentarios aquí de que se obtiene la clave de cifrado. Si bien obtener la clave de autenticación permite alterar el mensaje, no permite recuperar el mensaje. Señale dónde puedo estar equivocado.
zaph

30
  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.

Para apoyar su Punto 1 (+1 para ese por cierto): codinghorror.com/blog/archives/001267.html
Michael Stum

1
No debe comenzar el CTR con un número aleatorio, ya que tiene una posibilidad pequeña pero creciente de colisionar con parte de un mensaje anterior. En lugar de eso, increméntelo monotónicamente (esto puede significar recordar dónde se encuentra en un almacenamiento persistente) y vuelva a teclear si (cuando) se quede sin contador.
caf

@Theran - punto 2 - ¿un número aleatorio diferente para cada mensaje? No, creo que eso no es correcto. Tengo la impresión de que comenzar el contador siempre a cero está bien. @caf, creo que cuando Theran dice "mensaje" no quiere decir "bloquear". Por supuesto, el contador se incrementa para cada bloque de un mensaje particular que se ejecuta a través del cifrado. Lo que parece estar diciendo Theran es que cada mensaje debe comenzar con un valor inicial diferente para el contador. Y creo que esto no es correcto.
Cheeso el

1
re: punto 3 - He leído documentos que dicen, por ejemplo, que el modo CTR es más pequeño de implementar porque el descifrado es la misma transformación que el cifrado. Por lo tanto, la mitad del código. Pero como digo, no es relevante en una máquina de clase de servidor.
Cheeso el

Sí, hablo mal. Es el IV / nonce lo que debería cambiar para el modo CTR, pero eso se combina con el contador antes del cifrado, por lo que tiendo a pensarlo como un punto de partida aleatorio para el contador. En cuanto a tener que usar el cifrado en la dirección de cifrado, ahorrando espacio, para muchos cifrados solo tiene que invertir las subclaves para descifrar. AES es un poco voluminoso para descifrar, pero de todos modos no es posible implementarlo en un uC con 128 bytes de RAM. ¡Las subclaves toman más RAM que eso!
Theran el

13

¿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 .


66
Esta respuesta no cumple con los estándares de calidad de Stackoverflow: suponga, en su respuesta, que todos los enlaces externos se habrán desactivado, y resuma, si no copia directa, la información relevante, idealmente de una manera diseñada para responder mejor a la pregunta original.
mirabilos

55
@mirabilos Viniendo casi 5 años después refiriéndome a normas y estándares que no existían en ese momento, ¿en serio? Especialmente me gusta hablar de enlaces muertos cuando ambos aquí todavía están en vivo, y dado que el sitio en cuestión probablemente lo seguirá siendo por otros 5 años. Oh bien.
KTC

3
@mirabilos Usted puede venir correcta sin duda , pero su queja contra una respuesta que parecía haber sido hecho hace 5 años donde las normas son diferentes no es aplicable. Deberías haber admitido tu error. Incluso si ese no es el caso y si en cambio estás insinuando que debe actualizarse o cambiarse, todavía no es obligatorio. La respuesta fue suficiente de cómo fue.
konsolebox

@KTC Excepto cuando el gobierno se cierra y el sitio está fuera de línea. Su respuesta podría haber sido información útil, pero por el momento, falta por completo. Entonces, el lector de esta pregunta y sus respuestas todavía se pregunta qué se actualizó en 2014 (debido a una respuesta incompleta) y el estado actual (debido a un cierre del gobierno del sitio web del NIST). Sin embargo, me encantaría agregar la información que falta ...
G DeMasters

11

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


1
ST Micro: EBC debe ser BCE; FYI: por ejemplo, STM32L4A6 admite AES de 128 y 256 bits, con ECB, CBC, CTR, GCM, así como el código de autenticación de mensajes de Galois (GMAC) o los algoritmos de encadenamiento CMAC de modo de código de autenticación de mensajes cifrados.
Tom Kuschel

-3

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.


Ah, claro, por supuesto. El CBC XORs el bloque de texto cifrado anterior con el bloque de texto sin formato antes del cifrado. El primer bloque usa el IV. Entonces, para descifrar cualquier bloque, debe haber descifrado con éxito todos los bloques anteriores. ok, esa es una buena idea.
Cheeso el

66
No, solo tiene que tener acceso al texto cifrado anterior , que no requiere descifrar ningún bloque anterior.
caf

Ah, bueno, eso significa que CBC está bien con acceso aleatorio, ¿no?
Cheeso

44
@Cheeso: CBC está bien para acceso de lectura aleatorio, pero no para acceso de escritura aleatorio. Use CTR allí.
Paŭlo Ebermann

3
@ PaŭloEbermann Para acceso aleatorio, CTR no es una buena idea, ya que permite ataques severos si un atacante observa dos versiones del texto cifrado. Use XTS o un blockcipher modificable en su lugar.
CodesInChaos
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.