¿Es posible obtener un hash SHA1 idéntico? [duplicar]


Esta pregunta ya tiene una respuesta aquí:

Dadas dos cadenas diferentes S1 y S2 (S1 != S2) es posible que:

SHA1(S1) == SHA1(S2)

Es Verdad?

  1. En caso afirmativo - ¿con qué probabilidad?
  2. Si no - ¿por qué no?
  3. ¿Hay un límite superior en la longitud de una cadena de entrada, para que la probabilidad de obtener duplicados es 0? ¿O es el cálculo de SHA1 (de ahí la probabilidad de duplicados) independiente de la longitud de la cadena?

El objetivo que estoy tratando de lograr es hash alguna cadena de IDENTIFICACIÓN sensible (posiblemente unida con algunos otros campos como el ID padre), para que pueda usar el valor hash como un ID en su lugar (por ejemplo en la base de datos).

Ejemplo:

Resource ID: X123
Parent ID: P123

No quiero exponer la naturaleza de mi recurso identifica para permitir cliente para ver "X123-P123".

En su lugar quiero crear un nuevo hash de columna("X123-P123"), digamos que es AAAZZZ. Entonces el cliente puede solicitar recursos con id AAAZZZ y no saber acerca de mis id internos, etc.

Author: darkAsPitch, 2010-03-19

5 answers

Lo que usted describe se llama una colisión . Las colisiones necesariamente existen, ya que SHA-1 acepta muchos más mensajes distintos como entrada que puede producir salidas distintas (SHA-1 puede consumir cualquier cadena de bits de hasta 2^64 bits, pero solo produce 160 bits; por lo tanto, al menos un valor de salida debe aparecer varias veces). Esta observación es válida para cualquier función con una salida más pequeña que su entrada, independientemente de si la función es una función hash "buena" o no.

Suponiendo que SHA-1 se comporta como un "oráculo aleatorio" (un objeto conceptual que básicamente devuelve valores aleatorios, con la única restricción de que una vez que ha devuelto output v on input m, siempre debe devolver v on input m), entonces la probabilidad de colisión, para dos cadenas distintas S1 y S2, debe ser 2^(-160). Todavía bajo el supuesto de SHA-1 comportándose como un oráculo aleatorio, si usted recoge muchas cadenas de entrada, entonces usted comenzará a observar colisiones después de haber recogido cerca de 2^80 tales cuerdas.

(Eso es 2^80 y no 2^160 porque, con 2^80 cadenas puedes hacer alrededor de 2^159 pares de cadenas. Esto a menudo se llama la "paradoja del cumpleaños" porque es una sorpresa para la mayoría de las personas cuando se aplica a las colisiones en los cumpleaños. Ver la página de Wikipedia sobre el tema.)

Ahora sospechamos fuertemente que SHA-1 se comporta no realmente como un oráculo aleatorio, porque el enfoque de la paradoja de cumpleaños es el óptimo algoritmo de búsqueda de colisión para un oráculo aleatorio. Sin embargo, hay un ataque publicado que debería encontrar una colisión en aproximadamente 2^63 pasos, por lo tanto 2^17 = 131072 veces más rápido que el algoritmo de paradoja de cumpleaños. Tal ataque no debería ser factible en un verdadero oráculo aleatorio. Eso sí, este ataque no se ha completado realmente, sigue siendo teórico (algunas personas intentaron pero aparentemente no pudieron encontrar suficiente potencia de CPU)(Actualización: a principios de 2017, alguien hizo calcular un Colisión SHA-1 con el método mencionado anteriormente, y funcionó exactamente como se predijo). Sin embargo, la teoría parece sólida y realmente parece que SHA-1 no es un oráculo aleatorio. Correspondientemente, en cuanto a la probabilidad de colisión, bueno, todas las apuestas están fuera.

En cuanto a su tercera pregunta: para una función con una salida n-bit, entonces necesariamente hay colisiones si puede ingresar más de 2^n mensajes distintos, es decir, si la longitud máxima del mensaje de entrada es mayor que n. Con un límite m inferior a n, la respuesta no es tan fácil. Si la función se comporta como un oráculo aleatorio, entonces la probabilidad de la existencia de una colisión disminuye con m, y no linealmente, más bien con un corte pronunciado alrededor de m=n/2. Este es el mismo análisis que la paradoja del cumpleaños. Con SHA-1, esto significa que si m , entonces es probable que no hay colisión, mientras que m > 80 hace que la existencia de al menos una colisión muy probable(con m > 160 esto se convierte en una certeza).

Tenga en cuenta que hay una diferencia entre "existe una colisión" y "encuentra una colisión". Incluso cuando una colisión debe existir, todavía tiene su probabilidad de 2^(-160) cada vez que lo intenta. Lo que el párrafo anterior significa es que tal probabilidad no tiene sentido si no puedes (conceptualmente) intentar 2^160 pares de cadenas, por ejemplo, porque te restringes a cadenas de menos de 80 bits.

 114
Author: Thomas Pornin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-22 20:39:20

Sí, es posible debido al principio del palomar .

La mayoría de los hashes (también sha1) tienen una longitud de salida fija, mientras que la entrada es de tamaño arbitrario. Así que si lo intentas lo suficiente, puedes encontrarlos.

Sin embargo, las funciones hash criptográficas (como la familia sha, la familia md, etc.) están diseñadas para minimizar tales colisiones. El mejor ataque conocido toma 2^63 intentos para encontrar una colisión, por lo que la probabilidad es 2^(-63) que es 0 en la práctica.

 31
Author: Henri,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-09-13 07:37:22

Una colisión es casi siempre posible en una función hash. SHA1, hasta la fecha, ha sido bastante seguro en la generación de colisiones impredecibles. El peligro es que cuando se pueden predecir colisiones, no es necesario conocer la entrada de hash original para generar la misma salida de hash.

Por ejemplo, se han realizado ataques contra MD5 contra la firma de certificados de servidor SSL el año pasado, como se muestra en el episodio 179 del podcast Security Now. Esto permitió a los atacantes sofisticados generar un certificado de servidor SSL falso para un sitio web falso y parecen ser la cosa reaol. Por esta razón, es muy recomendable evitar la compra de certificados firmados por MD5.

 4
Author: spoulson,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-03-20 02:02:59

git utiliza hashes SHA1 como IDs y todavía no hay colisiones SHA1 conocidas en 2014. Obviamente, el algoritmo SHA1 es mágico. Creo que es una buena apuesta que las colisiones no existen para cuerdas de su longitud, ya que ya habrían sido descubiertas. Sin embargo, si no confías en magic y no eres un apostador, podrías generar cadenas aleatorias y asociarlas con tus ID en tu base de datos. Pero si usas hashes SHA1 y te conviertes en el primero en descubrir una colisión, puedes simplemente cambie su sistema para usar cadenas aleatorias en ese momento, conservando los hashes SHA1 como cadenas "aleatorias" para los ID heredados.

 4
Author: Vladimir Kornea,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-07-21 21:50:55

De lo que estás hablando se llama colisión. Aquí hay un artículo sobre las colisiones SHA1: http://www.rsa.com/rsalabs/node.asp?id=2927

Editar: Así que otro respondedor me venció al mencionar el principio del palomar LOL, pero para aclarar esto es por qué se llama el principio del palomar, porque si tienes algunos agujeros cortados para que las palomas mensajeras aniden, pero tienes más palomas que agujeros, entonces algunas de las palomas (un valor de entrada) deben compartir un agujero (la salida valor).

 3
Author: AaronLS,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2010-03-19 17:45:17