Ya existía un tema similar "¿Por qué AES no se usa para el hashing seguro, en lugar de SHA-x?", pero no se trataba de archivos específicamente, y personalmente no estoy convencido de las respuestas. "AES no está diseñado para este trabajo" no es una respuesta.
Lo que me molesta con esas respuestas es que ellos teorizan sobre cómo AES es un tipo diferente de algoritmo y no es adecuado para el trabajo, pero nadie expuso casos reales, como en "la implementación sugerida se rompería con < fuerte> este procedimiento ". Espero que hayan estado hablando en general, y que el hash de archivos sea una historia diferente.
Se debe tener en cuenta un hecho importante: todos los algoritmos hash criptográficamente seguros actuales son lentos. Las mejores implementaciones de SHA-256 están alcanzando un par de cientos de megabytes por segundo como máximo. Tienen una propiedad de paralización inherente, que no se pueden calcular en paralelo, la secuencia de datos de entrada no se puede dividir.
Los sistemas de IO de hoy ya son más rápidos que el hardware de consumo de un solo hilo más rápido en el que pueden calcular estos hashes. Esto significa que estos algoritmos se han convertido en un cuello de botella, y solo baja desde aquí, porque el rendimiento de un solo hilo ya no muestra ningún progreso serio (para varias generaciones de CPU), mientras que IO se está volviendo más rápido rápidamente (gracias a las unidades SSD y los discos RAM , que finalmente comenzó a empujar hacia adelante las velocidades de la unidad de disco de largo estancamiento).
La mayor ventaja del hash de AES es que tenemos implementaciones de hardware para él y que el hash de AES se puede diseñar para habilitar el paralelismo.
Echemos un vistazo a un esquema simple: AES256 (DATA_BLOCK_0 XOR COUNTER_0) XOR AES256 (DATA_BLOCK_1 XOR COUNTER_1) XOR ...
El último bloque de datos se rellena con ceros. La clave AES es conocida y preestablecida. Otra opción es usar el bloque de datos como clave cada vez y cifrar solo el contador. No sé ahora si esto puede tener un impacto negativo en la velocidad, ya que la clave debe cambiar en cada bloque. Si no hay un impacto serio, puede ser la mejor opción.
De todos modos, el esquema dado es masivamente paralelizable y puede empujar 2.5 gigabytes por segundo en un moderno quad-core con aceleración de hardware AES. También se escalará perfectamente en el futuro, que es cada vez más núcleos de CPU.
El hash AES se debe usar debido a la velocidad, y su propósito principal es hacer hash de los archivos, y no inicializar las claves privadas y cosas por el estilo. Es mejor dejarlo para algoritmos hash "reales", estoy de acuerdo.
Ahora para un análisis.
En cuanto a la detección de errores aleatorios, no veo ningún problema con el esquema anterior. Debería mezclarse bien y reaccionar al azar para cualquier cambio.
No debemos preocuparnos por que alguien calcule a la inversa los datos originales del hash. Los hashes de archivos siempre se distribuyen con sus archivos, y su propósito no es ocultar los datos originales. Su propósito es garantizar (con una probabilidad razonable) que los datos no hayan cambiado, que se trata de un archivo sin modificar. Los hash de archivos privados no deben hacerse públicos en ningún caso, incluso con algoritmos como SHA-256.
La parte problemática solo puede ser un ataque inteligente que intenta modificar el archivo de tal manera que el hash no cambie. En el escenario más simple, creo que un atacante modifica una parte de un bloque para lograr algún objetivo. Después de eso, necesita modificar cualquier bloque (o más), lo que se considera poco importante, de tal manera que produzca un hash conocido, uno que será XOR con el primer hash del bloque modificado para que la diferencia se elimine. y el hash final seguirá siendo el mismo.
Dejemos de lado el caso de que el atacante agregue datos a un archivo, ya que puede detectarse fácilmente y probablemente no sea más fácil de calcular de todos modos.
Estoy mirando el esquema simple de arriba, y para mí, parece que el atacante tiene que buscar un espacio de 2 ^ 256 para encontrar la entrada apropiada, que es casi lo mismo que descifrar AES. Y ese espacio es simplemente demasiado grande.
Ahora, ¿alguien puede explicar qué procedimiento permitiría el ataque descrito?
Gracias.