Bloquee los modos de encadenamiento para evitar

OFB y CTR convierten el cifrado de bloque en un cifrado de flujo. Esto significa que se debe tener cuidado al usarlos, como para RC4 ; reutilizar el mismo flujo para cifrar dos mensajes distintos es un pecado mortal. OFB es más "delicado" en esa materia. Como OFB consiste en encriptar el mismo valor repetidamente, es, en la práctica, una exploración de un ciclo de permutación : la IV selecciona un punto y OFB recorre los ciclos que contienen este punto. Para un cifrado de bloque con tamaño de bloque n , el tamaño promedio de un ciclo debe estar alrededor de 2 ^{n / 2} , y si cifras más que eso, entonces comienzas a repetir un segmento anterior de la transmisión, y eso es malo. Esto puede ser un gran problema cuando n = 64 (por ejemplo, utiliza 3DES). Además, esto es un promedio: puedes, fuera de (mala) suerte, alcanzar un ciclo más pequeño; también, si cifras dos mensajes con la misma clave pero con un IV distinto, puedes (también si no tienes suerte) golpear el mismo ciclo que anteriormente (solo en un punto diferente).

El punto negativo de OFB es que es difícil probar estas ocurrencias (si la implementación incluye el código necesario, puede probar si ocurren estas situaciones no deseadas, pero esto no se puede hacer de antemano , solo cuando ya se ha realizado parte del cifrado). Para CTR, las cosas son más fáciles: CTR es el cifrado de valores de contador sucesivos; el problema comienza cuando se reutiliza un valor de contador . Pero un comportamiento de contador es fácil de predecir (después de todo, es un contador), por lo que es mucho más fácil garantizar que los mensajes sucesivos encriptados con la misma clave utilicen distintos rangos de valores de contador.

Además, cuando se encripta con CTR, la salida comienza a distinguirse del azar puro después de unos bloques 2^n/2 , pero eso rara vez es letal. Es una preocupación y es suficiente para justificar el uso de cifrados de bloque con bloques grandes (por ejemplo, AES con bloques de 128 bits en lugar de 3DES y sus bloques de 64 bits), pero eso es una degradación de la seguridad más elegante que la que ocurre con OFB.

Para resumir, no use OFB; usa CTR en su lugar . Esto no hace que el CTR sea fácil de usar de manera segura, sino más fácil. Para evitar el error, debe intentar usar uno si los modos de cifrado autenticados que hacen las cosas correctamente e incluyen una verificación de integridad, Un componente necesario pero a menudo pasado por alto. EAX y GCM son mis modos AE preferidos (EAX será más rápido en arquitecturas pequeñas con caché L1 limitado, GCM será más rápido en x86 moderno, especialmente aquellos con AES opcodes que se definieron solo para eso).

Que yo sepa, CFB no sufre tanto como OFB debido a los problemas de la duración del ciclo, pero cifrar una larga secuencia de ceros con CFB es equivalente a OFB; por lo tanto, parece más seguro preferir CTR sobre CFB también.

Casi todos los modos de operación de cifrado de bloque tienen problemas al alcanzar la barrera 2^n/2 , por lo tanto, es aconsejable utilizar bloques de 128 bits de todos modos.

Nota: CFB y OFB tienen una "longitud de realimentación" opcional. Por lo general, usamos retroalimentación de bloque completo, porque eso es lo que garantiza el máximo rendimiento (producción de n bits de texto cifrado por invocación del cifrado de bloque). Los modos con comentarios más pequeños también se han definido, por ejemplo, CFB-8 que encripta solo un byte a la vez (por lo que es 8 veces más lento que el CFB de bloque completo cuando se utiliza un cifrado de bloque de 64 bits). Tales modos no están tan bien soportados por las bibliotecas existentes; Además, los pequeños circuitos de retroalimentación empeoran los problemas de OFB. Por lo tanto, no recomiendo el uso de CFB o OFB será menor que la retroalimentación de bloque completo.

Como lo señaló @Rook: el modo CBC, como el BCE, pero a diferencia de CFB, OFB y CTR, procesa solo bloques completos, por lo tanto, necesita relleno . El relleno puede implicar ataques de oráculo de relleno , lo cual es malo (posiblemente, un ataque de oráculo de relleno es posible solo si no se usa MAC, o está mal aplicado; la forma correcta de cifrar y luego MAC). Por esta razón, los modos sin relleno son preferibles a CBC.

Esto nos lleva a una clara victoria de CTR sobre otros modos, siendo CFB segundo, luego CBC y OFB en un empate, luego ECB (esto es un poco subjetivo, por supuesto). Pero, en realidad, usa EAX o GCM.

El modo de operación depende completamente de cómo se utilizan los datos. Deja que tus amenazas definan la solución.

Por ejemplo, modos autenticados como GCM y CCM son realmente elegantes y los uso en mis diseños para evitar Oráculos criptográficos. Pero no siempre necesitas un modo autenticado. Por ejemplo, si necesita almacenar muchos registros pequeños en la base de datos, y la modificación del texto cifrado realmente no es una preocupación, entonces un modo autenticado no es la herramienta adecuada.

Muchas bases de datos se basan en el modo ECB, y esto no siempre es una vulnerabilidad. Por ejemplo, si está almacenando solo un único bloque, y ese bloque siempre contiene un valor aleatorio como un ID de sesión o un token de restablecimiento de contraseña, entonces los ataques en el modo ECB no entran en juego. Al usar el modo ECB, la base de datos puede hacer búsquedas mucho más rápido, porque sabe que siempre hay una relación 1: 1 entre texto sin formato y texto cifrado.

También tenga en cuenta que, al usar el modo ECB, ¡no es víctima de los ataques CBC-R y Padding Oracle que afectan el modo CBC! Al utilizar el modo CBC en ECB, puede hacer que un sistema sea menos seguro . Lo mismo sucede en muchos casos, el modo ECB es probablemente la elección equivocada.

Sí. La mejor respuesta a esta pregunta es responder la pregunta. Para la mayoría de las situaciones, no debe usar criptografía de una manera que lo obligue a elegir su propio modo de operación; si haces eso, hay demasiadas maneras en que puedes equivocar . Por ejemplo, muchas personas que hacen eso se olvidan de autenticar los datos correctamente, lo cual es un problema.

En cambio, generalmente es mejor usar una herramienta o biblioteca de alto nivel . Para citar de mi respuesta en otro lugar:

  

Su mejor caso es usar un esquema bien investigado de alto nivel: para la seguridad de la comunicación, use TLS (o SSL); para datos en reposo, utilice GPG (o PGP). Si no puede hacerlo, use una biblioteca criptográfica de alto nivel, como cryptlib, GPGME, Keyczar o NaCL, en lugar de una de bajo nivel, como OpenSSL, CryptoAPI, JCE, etc.