AES, por sí mismo, es un cifrado de bloque : acepta como entrada un "bloque" de 16 bytes, y Produce un bloque de 16 bytes. Pero queremos usarlo para cifrar "datos", generalmente secuencias largas de bytes, mucho más largas que 16 bytes, por lo que se necesita algo más; este es el modo de operación . El modo de operación define cómo se procesan los datos de entrada y, en particular, qué es exactamente lo que entra en el cifrado de bloque propiamente dicho.
El método más simple es dividir los datos en bloques de 16 bytes y procesarlos de forma independiente. Esto se llama BCE. La imagen habitual del pingüino (ver la respuesta de @ drjimbob) es una clara demostración de que hay algo mal con el BCE al procesar "datos normales". Se necesita un mejor modo de cifrado. Históricamente, OFB, CFB y CBC ganaron popularidad, luego se definió el CTR. Todos estos modos hacen cosas diferentes con los datos e invocan el cifrado de bloque en bloques diferentes. En CBC y CFB, AES se invoca de bloques que son un XOR de un bloque de datos con algún producto del procesamiento anterior; con OFB y CTR, AES se invoca en algo que depende de la IV, la clave y la posición del bloque, pero no en los datos en sí.
Con una gran cantidad de movimientos con la mano, podemos afirmar que en un buen modo de operación, los datos sin procesar no deben ingresar el cifrado de bloque "como está" . El motivo es el siguiente: los datos normales tienen redundancia, por lo que puede esperar que los bloques de origen tengan repeticiones (por ejemplo, piense en XML). Sin embargo, el cifrado de bloque en sí es determinista, por lo que si lo llama dos veces en la misma salida, obtendrá el doble de la misma salida. Este es el tipo de fuga de información que un buen sistema de cifrado debería ocultar. En un modo de operación, el "poder de ocultación" se encuentra en el cifrado de bloque; el resto es mero enrutamiento de datos; por lo tanto, para ocultar las repeticiones y otros elementos estructurales de los datos de origen, el modo debe ser tal que no haya dos invocaciones del cifrado de bloque que envíen el mismo bloque al cifrado de bloque. Y esto implica, al menos, algún procesamiento de cifrado previo.
Ahora, CFB y CBC aún "combinan" el bloque de datos con la entrada de cifrado de bloque, mientras que OFB y CTR hacen esta combinación solo en la salida. Podríamos argumentar que el último método es superior porque permite precomputaciones: con OFB y CTR, uno puede "preparar" la cadena pseudoaleatoria antes de tener acceso a los datos reales. Sin embargo, esto rara vez se hace, porque el almacenamiento en búfer tiene sus propios costos. Una característica mucho más importante de CTR, que CFB, OFB y CBC no tienen, es paralelización : dado, por ejemplo, un mensaje de 160 bytes para cifrar, las 10 invocaciones AES subyacentes se pueden hacer simultáneamente. siempre que tengas suficientes circuitos para eso. No puede hacer eso con CBC, porque tiene que esperar el resultado del cifrado de un bloque para comenzar a procesar el siguiente bloque (aunque puede tener un descifrado de CBC paralelo). A los fabricantes de circuitos de alto ancho de banda les encanta el modo CTR (se mapea bien en implementaciones AES desenrolladas y revestidas).
Para resumir:
- Es necesario un modo de operación más complejo que el BCE.
- El modo debe incluir algunos datos de preprocesamiento para que los datos sin procesar no entren "como están" en el cifrado de bloque. Si el modo "encripta directamente el texto sin formato" (es decir, aplica el cifrado de bloque en bloques de datos fuente no modificados), entonces tendrá problemas para ocultar las repeticiones, y eso es un problema con los datos estructurados normales.
- No existe una necesidad formal de que los datos de origen entren en el cifrado de bloque; los datos de origen pueden entrar en la mezcla como un paso de post-procesamiento. Esto le da algunas ventajas menores, por ejemplo. la posibilidad de calcular previamente la mayor parte de las operaciones; Si el post-procesamiento es un XOR simple, también hace que el descifrado sea idéntico al cifrado, lo cual es bueno cuando un sistema debe hacer ambas cosas (ahorra espacio de código y / o área de silicio).
- Una característica importante de los buenos modos es la posibilidad de acelerar las cosas con la paralelización. Sucede que el único modo popular que es susceptible de paralelismo tanto para el cifrado como para el descifrado (que es CTR) también es un modo "solo de post-procesamiento". Eso es una coincidencia; que yo sepa, no hay una razón fuerte por la que debería ser así. Pero no obstante, es agradable (como se dijo anteriormente), así que no nos quejaremos.