Combinando modos CTR y ECB para prevenir ataques
Al reutilizar claves AES-CTR e IV para cifrado de archivos , el OP estaba preguntando sobre un esquema de cifrado compuesto$$C_i = E_K\left(P_i \oplus E_K\left(IV + i\right)\right)$$ que es básicamente un CTR seguido de un BCE.
Ahora, si bien su intención era usar esto para el cifrado de disco (donde el IV es solo la ubicación única (pero conocida) de un bloque en el disco), este enfoque tenía ciertas debilidades debido a las capacidades de ataque de un atacante en la teoría del cifrado de disco. . Sin embargo, me preguntaba si hay ventajas significativas para este CTR-luego-ECB fuera de necesariamente un contexto de cifrado de disco, como cifrar datos en una base de datos, por ejemplo.
Específicamente, cualquier reutilización de (IV/nonce + counter)en CTR (para la misma clave) puede conducir trivialmente a un ataque de texto sin formato conocido si el atacante conoce el texto sin formato de cualquier otro bloque también cifrado con eso (IV/nonce + counter). Y no solo un (IV/nonce + counter)bloque, sino también cualquier bloque "cercano" que pertenezca a esos mensajes (¡debido a la superposición del contador!).
Sin embargo, si encriptamos con CTR-then-ECB, entonces el atacante solo sabrá el texto sin formato de los bloques si están encriptados con el mismo IV+counter y también contienen el mismo texto cifrado. Por el contrario, un atacante de un esquema de cifrado solo CTR requiere solo la coincidencia IV + counter(con un bloque conocido), y un atacante de un esquema de cifrado solo CBC requiere solo textos cifrados coincidentes (con un bloque conocido).
Pero, ¿es esto una ventaja significativa, o las probabilidades involucradas aquí son tan mínimas, especialmente si se usan IV aleatorios , que CTR-luego-ECB no proporciona ningún beneficio real? (por ejemplo, con AES)
Respuestas
Hay algunos problemas que me vienen a la mente:
- este es un esquema de doble paso, que es computacionalmente costoso;
- la fuga de bloques que son idénticos es innecesaria, hay esquemas que solo filtran texto plano completamente idéntico;
- El modo ECB requiere relleno, por lo que crearía algunos gastos generales.
Ahora podría argumentar que 1. no es un problema en las computadoras actuales. Sin embargo, ese solo sería un buen argumento si no hubiera ningún esquema que presentara las mismas propiedades sin requerir un doble pase.
En cuanto a 2, existen esquemas como Format Preserving Encryption que no filtran ninguna información que no sea texto plano completamente idéntico. FPE es generalmente bastante costoso cuando se trata de implementación (por otro lado, no tener que almacenar un IV generalmente no es un problema para binarios grandes, ya que generalmente tendrían un tamaño VARiable). Otra opción es realizar un cifrado de bloque en el índice y usarlo como IV impredecible para el modo CBC (posiblemente con robo de texto cifrado si no le gusta la sobrecarga de relleno). Ya se han mencionado las rutinas de cifrado de disco existentes, como XTS y ESSIV.
En cuanto a 3, el robo de texto cifrado (CTS) para el modo ECB, por supuesto, puede implementarse, pero definitivamente no ayuda con la facilidad de implementación, que sería el mayor beneficio sobre otros esquemas (ECB generalmente está disponible en, por ejemplo, SQL y CTR es relativamente simple de implementar usando ECB, aunque definitivamente no me gustaría hacerlo en SQL).
Finalmente, si tiene espacio para una etiqueta de autenticación, entonces se podría usar un modo SIV (como AES-GCM-SIV) para eliminar la necesidad de un IV explícito. Si tiene espacio para ambos, por supuesto, solo un AES-GCM genérico tendría sentido.
En general, creo que, si bien el esquema tiene méritos, existen mejores opciones, preferiblemente las que están integradas en el motor de base de datos.