¿Las funciones hash criptográficas populares no deberían codificar la longitud de los datos de entrada en la salida?

Question

¿Las funciones hash criptográficas populares no deberían codificar la longitud de los datos de entrada en la salida?

#1 de Mike Ounsworth (6 votos)
#2 de Steffen Ullrich (4 votos)

1

EDIT2: esta discusión se redujo a "¿son las colisiones realmente más difíciles de crear cuando se agrega una restricción de longitud?" Lo que es más relevante para el intercambio de Crypto. Crearé una pregunta allí y la vincularé cuando exista. Gracias a todos los que participaron en la discusión

EDITAR: el término "Ataque de colisión" en Wikipedia parece hablar solo de encontrar una colisión aleatoria, quise decir "Ataque de preimagen ".

Me parece una buena idea, ya que evitaría todos los ataques de colisión que requieran que el atacante modifique la longitud de los datos. El atacante tendría que encontrar una colisión con la misma longitud, que obviamente es mucho más difícil que encontrar una colisión general.

Los ataques de colisión generalmente requieren que el atacante modifique la longitud de los datos (agregando más bloques a los datos existentes o algo así), ¿no?

El único inconveniente que veo es que requerirá que los resultados de hash sean más largos (la forma en que lo veo solo por 2-4 bytes es "La longitud del módulo de datos 2 ^ 16-2 ^ 32" debería ser suficiente) así que no por mucho.

Por supuesto, esto no tiene por qué ser parte de la función hash, podría ser una recomendación de seguridad general: "Verifique la longitud esperada de los datos, no solo que coincida con el hash calculado, para evitar muchas formas de ataques de colisión ".

Aunque nunca antes había escuchado esta recomendación o mencionada esta recomendación, a pesar de la forma en que la veo, tiene mucho sentido.

Entonces, en general, estoy preguntando aquí: ¿Por qué no es una buena idea? ¿Debería estar codificado en funciones hash para que lo aplique automáticamente cualquiera que use esas funciones, o debería ser una recomendación de seguridad general que el usuario de la función hash puede implementar solo, por separado de la función hash?

¿O tal vez me estoy perdiendo algo que hace que esta idea sea ridícula?

hash

pregunta Omer 12.10.2017 - 21:58

fuente

2 respuestas

Lea otras preguntas en las etiquetas hash

Algoritmo de hash que proporciona menos de 10 bytes Pasar una CVV no válida crea una transacción exitosa

score 6 · Answer 1

Te estás perdiendo otro inconveniente: le dice al atacante la longitud del texto sin formato.

En algunos casos, esto se considera información confidencial. Si tengo contraseñas de fuerza bruta, por ejemplo, me está diciendo que puedo omitir el intento de todas las contraseñas excepto las de la longitud especificada. Genial, gracias.

Los ataques de colisión generalmente requieren que el atacante modifique la longitud de los datos (agregando más bloques a los datos existentes o algo así), ¿no?

Creo que estás describiendo un ataque de extensión de longitud . Los verdaderos criptógrafos probablemente me asarían por decir esto, pero ingenuamente tengo una solución posible para rellenar el masaje antes de realizar el hash (en ese momento puede eliminar toda la codificación de longitud y simplemente usar una función hash tradicional): _ (realmente, no No vaya a crear software basado en esto, no garantizo que sea seguro).

hash( 0*(256 - (len(msg)%256) ) || msg)

Luego, cuando el atacante intenta realizar un ataque de extensión de longitud mediante la concatenación de msg2 hasta el final:

hash( 0*(256 - (len(msg||msg2)%256) ) || msg||msg2)

tendrán un número diferente de rellenos 0, lo que cambia el prefijo de masaje y rompe totalmente el ataque de extensión de longitud.

(Cuanto más pienso en esto, menos quiero apoyar la idea. Probablemente debería pasar un tiempo buscando en Google "mitigación del ataque de la extensión de longitud" en lugar de sentarme aquí y especular)

score 4 · Answer 2

Una función hash criptográfica está diseñada para tener grandes cambios en la salida, incluso en pequeños cambios en la salida. Al agregar algunos bytes que describen la longitud de la entrada, se cambia esta suposición, ya que estos bits de longitud solo crearán pequeños cambios en la salida en pequeños cambios en la entrada.

Aparte de eso, en realidad se filtra información importante sobre la entrada como ya se ha señalado Mike Ounsworth . Esencialmente, le dices al atacante no solo cuánto tiempo durará la entrada, sino también que definitivamente hay algo de valor que el resultado de este hash. Esto reduce en gran medida el espacio que el atacante tiene para utilizar la fuerza bruta para obtener el mismo resultado hash, que en el caso de las contraseñas es todo lo que se necesita ya que no es necesaria una colusión.

Pero incluso en el caso de que te importe una preimagen, no está claro que los bits que agregues para codificar la longitud no serían más útiles en lugar de extender la fuerza del hash para evitar un ataque de preimagen. Si bien puede ser útil en los casos en que la entrada debe ser más corta que el hash en sí misma y, por lo tanto, las imágenes previas son poco probables, creo que estos bits se usan mejor para un hash real más largo en caso de que la entrada sea más larga que la salida de hash porque las imágenes previas de la misma longitud son mucho más más probable entonces.

El atacante tendría que encontrar una colisión con la misma longitud, que obviamente es mucho más difícil que encontrar una colisión general.

¿Es realmente tan difícil? Estoy de acuerdo en que es más difícil si la entrada es más corta que el hash ya que es un problema de encontrar imágenes previas en un tamaño tan pequeño. Pero si la entrada es mucho más grande que el hash (es decir, como con los certificados) dudo que requerir una longitud específica realmente agregue complejidad adicional para encontrar una preimagen, a menos que haya una debilidad inherente en cómo se construye el hash.