Colisión de hash en git

¿Qué pasaría realmente si tuviera una colisión hash mientras uso git?

Por ejemplo, me las arreglo para enviar dos archivos con la misma suma de verificación sha1, ¿lo notaría Git o corrompería uno de los archivos?

¿Se podría mejorar git para vivir con eso, o tendría que cambiar a un nuevo algoritmo hash?

(Por favor, no desvíe esta pregunta discutiendo cuán improbable es eso, gracias)

preguntado el 03 de mayo de 12 a las 16:05

I've been informed by the git Gods that the chances of a SHA1 collision is the same as the Earth being sucked up into the black hole created by the CERN accelerator. If this is indeed true, then there's no need for that extra memcmp. , Fuente: lwn.net/Artículos/307281 -

ABSOLUTAMENTE NO ES ASÍ. Para citar a Dan Bernstein: "El hecho de que los académicos aún no hayan llevado a cabo el ataque de colisión SHA-1 es un accidente histórico menor": ahora que el concurso SHA-3 ha terminado, es muy probable que las personas relevantes presten atención. a usar el ataque conocido para producir una colisión. Marc Stevens estima que la dificultad es de 2^61 operaciones. Es muy probable que pronto se muestre una colisión SHA-1; es raro que no haya pasado ya. -

@KurzedMetal: Existe la posibilidad de crear un agujero negro en el CERN (dos protones habrían colisionado con precisión (10^-15 m)), sin embargo, este agujero negro no absorbería la Tierra, se evaporaría instantáneamente debido a la radiación de Hawking... Entonces las posibilidades de colisión de SHA1 son mucho mayores que ser succionado... solo digo... -

Es sorprendente que le pidieras específicamente a la gente que no discutiera la improbabilidad de la colisión de git, y casi todos hablaron sobre la improbabilidad de la colisión de git. ¡Estas personas deberían ser expulsadas de stackoverflow de por vida! -

9 Respuestas

Recogiendo átomos en 10 Lunas

Un hash SHA-1 es una cadena de 40 caracteres hexadecimales... eso es 4 bits por carácter multiplicado por 40... 160 bits. Ahora sabemos que 10 bits son aproximadamente 1000 (1024 para ser exactos), lo que significa que hay 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 hash SHA-1 diferentes... 1048.

¿De qué es este equivalente? Bueno, la Luna se compone de alrededor de 1047 átomos Entonces, si tenemos 10 lunas... y eliges al azar un átomo en una de estas lunas... y luego continúas y eliges un átomo al azar en ellas nuevamente... entonces la probabilidad de que elijas el mismo átomo dos veces , es la probabilidad de que dos confirmaciones de git dadas tengan el mismo hash SHA-1.

Ampliando esto, podemos hacer la pregunta...

¿Cuántas confirmaciones necesita en un repositorio antes de que deba comenzar a preocuparse por las colisiones?

Esto se relaciona con los llamados "ataques de cumpleaños", que a su vez se refiere a la "paradoja del cumpleaños" o "problema del cumpleaños", que establece que cuando elige al azar de un conjunto determinado, sorprendentemente necesita pocas selecciones antes de que sea más probable que no. haber escogido algo dos veces. Pero "sorprendentemente pocos" es un término muy relativo aquí.

Wikipedia tiene una tabla sobre la probabilidad de colisiones de Birthday Paradox. No hay ninguna entrada para un hash de 40 caracteres. Pero una interpolación de las entradas de 32 y 48 caracteres nos lleva al rango de 5*1022 git se compromete para una probabilidad de colisión del 0.1 %. Eso es cincuenta mil billones de billones de confirmaciones diferentes, o cincuenta Zetta se compromete, antes de que haya alcanzado incluso un 0.1% de probabilidad de que tenga una colisión.

La suma de bytes de los hashes solo para estas confirmaciones sería más datos que todos los datos generados en la Tierra durante un año, lo que significa que necesitaría producir código más rápido de lo que YouTube transmite el video. Buena suerte con eso. :D

El punto de esto es que, a menos que alguien esté causando una colisión deliberadamente, la probabilidad de que ocurra al azar es tan asombrosamente pequeña que puede ignorar este problema.

"Pero cuando una colisión ocurrir, entonces, ¿qué sucede realmente?"

Ok, supongamos que sucede lo improbable, o supongamos que alguien logró adaptar una colisión de hash SHA-1 deliberada. ¿Qué pasa entonces?

En ese caso hay una excelente respuesta donde alguien experimentó con ella. Citaré de esa respuesta:

  1. Si ya existe un blob con el mismo hash, no recibirá ninguna advertencia. Todo parece estar bien, pero cuando presiona, alguien clona o revierte, perderá la última versión (en línea con lo explicado anteriormente).
  2. Si ya existe un objeto de árbol y crea un blob con el mismo hash: todo parecerá normal, hasta que intente empujar o alguien clone su repositorio. Entonces verás que el repositorio está corrupto.
  3. Si ya existe un objeto de confirmación y crea un blob con el mismo hash: igual que el n. ° 2: corrupto
  4. Si ya existe un blob y crea un objeto de confirmación con el mismo hash, fallará al actualizar la "ref".
  5. Si ya existe un blob y crea un objeto de árbol con el mismo hash. Fallará al crear la confirmación.
  6. Si ya existe un objeto de árbol y crea un objeto de confirmación con el mismo hash, fallará al actualizar la "ref".
  7. Si ya existe un objeto de árbol y crea un objeto de árbol con el mismo hash, todo parecerá correcto. Pero cuando se compromete, todo el repositorio hará referencia al árbol incorrecto.
  8. Si ya existe un objeto de confirmación y crea un objeto de confirmación con el mismo hash, todo parecerá correcto. Pero cuando se confirma, la confirmación nunca se creará y el puntero HEAD se moverá a una confirmación anterior.
  9. Si ya existe un objeto de confirmación y crea un objeto de árbol con el mismo hash, fallará al crear la confirmación.

Como puede ver, algunos casos no son buenos. Especialmente los casos #2 y #3 estropean tu repositorio. Sin embargo, parece que la falla permanece dentro de ese repositorio y el ataque o la extraña improbabilidad no se propaga a otros repositorios.

Además, parece que el problema de las colisiones deliberadas se está reconociendo como una amenaza real y, por ejemplo, GitHub está tomando medidas para evitarlo.

Respondido el 14 de Septiembre de 20 a las 16:09

No sé si los números son precisos, pero Dios mío, esta es una excelente forma gráfica de describir la improbabilidad y es divertido :) - mimoralea

@UtkarshKumar Bueno, la parte divertida será verificar que la cantidad de átomos sea correcta. Buena suerte en contarlos. :D - miguelk

La posibilidad de que una confirmación aleatoria de un archivo de texto real colisione es tan buena como cero, muy poco probable. Pero esta respuesta omite por completo el hecho de que alguien podría intentar crear una colisión deliberadamente. Con el hash SHA-1 bajo ataque, eso se está convirtiendo en un factor bastante importante. - Maarten Bodewes

Motivo de la votación negativa: muy bien dicho, pero la probabilidad no significa absolutamente nada aquí. Puede decir lo mismo acerca de ganar la lotería, pero la gente gana la lotería aquí y allá todos los días. Entonces, la compañía de lotería realmente no puede simplemente decir: la posibilidad es pequeña, por lo que no deberíamos tener que preocuparnos por pagar el premio mayor. La pregunta del OP aquí es: qué sucede cuando ocurre esa pequeña posibilidad y no pudo responderla. - Max

@FukuzawaYukio Sin embargo, no hay 2^48 boletos de lotería impresos, solo millones (quizás 200 millones en total por año... ¿quién sabe?), y hay una lotería ganadora. La probabilidad es mucho mayor y, para algunos billetes de lotería, siempre se imprime el billete ganador; por lo tanto, el ganador es inevitable (a menos que el boleto ganador se extravíe accidentalmente). Además, hice un juego de boletos de lotería pseudo-realista hace muchos años: loteria.py. No hace falta decir que pierdes el 99% del tiempo. - dylnmc

Si dos archivos tienen la misma suma hash en git, los trataría como idénticos. En el caso absolutamente improbable de que esto suceda, siempre puede retroceder una confirmación y cambiar algo en el archivo para que no vuelvan a chocar ...

Vea Publicación de Linus Torvalds en el hilo "¿Empezando a pensar en sha-256?" en la lista de correo de git.

respondido 16 nov., 16:15

"Si dos archivos tienen la misma suma hash en git, los trataría como idénticos". Esta es en realidad una respuesta adecuada. Sin embargo, ¿tiene alguna fuente para esta declaración klaustopher? Tu enlace no me funciona. - Bitcoin Cash - entusiasta de la ADA

Pero esto no es absolutamente improbable si trabaja en un proyecto con una colección de muestras de colisión de hash. - Doomjunky

@JBishop No, no fue así. Si tienes una prueba de una colisión hash, tendrás fama instantánea. ¡No olvides publicarlo! Enviaré una caja de cerveza de Haarlem verdaderamente buena si me muestran una colisión de hash SHA-1 de tamaño completo creada dentro de Git dentro de una semana. Tenga en cuenta que debe ser una colisión hash separada, no una ya citada en otro lugar (no es que nadie haya publicado una todavía, pero aún así). - Maarten Bodewes

+1 La única respuesta hasta ahora que realmente responde la pregunta. Todos los demás solo están balbuceando sobre la "pequeña posibilidad" de que ocurra, que todos los desarrolladores ya saben. - Max

Sea muy cauteloso cuando Linus hable sobre seguridad de TI: se equivocó antes y se equivoca en este caso. Si uno pudiera crear colisiones SHA-1 a voluntad, podría usarlo para todo tipo de caos, como la creación de historias circulares que hacen que los servidores y clientes de Git se bloqueen. - Dom Q

Realmente no es posible responder a esta pregunta con el "pero" correcto sin explicar también por qué no es un problema. No es posible hacer eso sin tener un buen control de lo que realmente es un hash. Es más complicado que los casos simples a los que podría haber estado expuesto en un programa de CS.

Aquí hay un malentendido básico de la teoría de la información. Si reduce una gran cantidad de información a una cantidad más pequeña descartando cierta cantidad (es decir, un hash), habrá una posibilidad de colisión directamente relacionada con la longitud de los datos. Cuanto más cortos sean los datos, MENOS probable será. Ahora, la gran mayoría de las colisiones serán un galimatías, lo que hace que sea mucho más probable que sucedan realmente (nunca verificaría un galimatías... incluso una imagen binaria está algo estructurada). Al final, las posibilidades son remotas. Para responder a su pregunta, sí, git los tratará de la misma manera, cambiar el algoritmo hash no ayudará, tomará una "segunda verificación" de algún tipo, pero en última instancia, necesitaría la mayor cantidad de datos de "verificación adicional". como la longitud de los datos para estar 100% seguro... tenga en cuenta que sería 99.99999... a un número realmente largo de dígitos... seguro con una verificación simple como la que describe. SHA-x son hashes criptográficamente fuertes, lo que significa que generalmente no es difícil crear intencionalmente dos conjuntos de datos de origen que sean MUY SIMILARES entre sí y tengan el mismo hash. Un pequeño cambio en los datos debería crear más de un (preferiblemente tantos como sea posible) bits de cambio en la salida del hash, lo que también significa que es muy difícil (pero no del todo imposible) trabajar desde el hash hasta el conjunto completo de colisiones y, por lo tanto, extraiga el mensaje original de ese conjunto de colisiones: todas menos algunas serán un galimatías, y de las que no lo son, todavía hay una gran cantidad para filtrar si la longitud del mensaje es significativa. La desventaja de un hash criptográfico es que son lentos de calcular... en general.

Entonces, ¿qué significa todo esto para Git? No mucho. Los hashes se realizan tan raramente (en relación con todo lo demás) que su penalización computacional es baja en general para las operaciones. Las posibilidades de encontrar un par de colisiones son tan bajas que no es una posibilidad realista de que ocurran y no se detecten de inmediato (es decir, lo más probable es que su código deje de construirse repentinamente), lo que permite al usuario solucionar el problema (haga una copia de seguridad de una revisión, y haga el cambio nuevamente, y casi con certeza obtendrá un hash diferente debido al cambio de hora, que también alimenta el hash en git). Es más probable que sea un problema real para usted si está almacenando archivos binarios arbitrarios en git, que no es realmente su modelo de uso principal. Si quiere hacer eso... probablemente sea mejor que use una base de datos tradicional.

No está mal pensar en esto: es una buena pregunta que mucha gente simplemente hace pasar como "tan poco probable que no vale la pena pensar en ella", pero en realidad es un poco más complicado que eso. Si SÍ sucede, debería ser fácilmente detectable, no será una corrupción silenciosa en un flujo de trabajo normal.

Respondido el 30 de junio de 13 a las 01:06

you'll almost certainly get a different hash because of the time change, which also feeds the hash in git ¿El hash no se basa únicamente en el contenido de un archivo? - fredodesbordamiento

El hash de un blob se basa en el contenido de un archivo (con una pequeña cantidad de metadatos), sin embargo, el hash de una confirmación (que en teoría también podría colisionar) contiene la hora actual, así como el hash del árbol, el autor, los hash de las confirmaciones principales, etc. Sin embargo, como señala @Steve, es menos probable que las cosas pequeñas colisionen, y una confirmación es una cosa pequeña. - cdyson37

No crea que estoy de acuerdo con "Cuanto más cortos sean los datos, MENOS probables serán las [colisiones]". Si te refieres a hashes más cortos, entonces estás reduciendo el conjunto de posibles hash = más entradas asignadas a cada hash = mayor probabilidad de colisión. Si te refieres a mensajes más cortos que estás procesando, entonces esto solo es cierto en el sentido de que la cantidad de entradas posibles está limitada por la cantidad de caracteres utilizados, lo que parece tan obvio que siento que debo estar perdiendo el punto. - Básico

Nunca pensé en el punto "MUY SIMILAR", que es un muy buen punto. Básicamente significa que para tener 2 confirmaciones con el mismo hash, deberá cambiar una parte significativa de los caracteres en cada archivo (sin mencionar los nombres de archivo, las rutas y la cantidad de archivos). - pieter nuyts

@PieterNuyts No, para obtener un hash específico, de un archivo inicial arbitrario, normalmente tendría que cambiar la información en el archivo en una cantidad similar a la cantidad de bits de información en el hash, es decir, alrededor de 160 bits para SHA-1. Sin embargo, la información sobre qué bits cambiar también cuenta aquí, por lo que cuanto más largo sea el archivo, menos bits tendrá que cambiar si elige los correctos. Hipotéticamente, dado un archivo de una longitud muy superior a 2^160 bytes, podría obtener casi cualquier hash cambiando un solo bit, ¡ya que la ubicación de ese bit contiene más de 160 bits de información! - M Kloster

Puedes ver un buen estudio en "¿Cómo manejaría Git una colisión SHA-1 en un blob?".

Dado que ahora es posible una colisión SHA1 (como hago referencia en esta respuesta con destrozado.io), sepa que Git 2.13 (Q2 2017) mejorará/mitigará la situación actual con una variante de "detectar intento de crear colisiones" de Implementación de SHA-1 por Marc Stevens (CWI) y Dan Shumow (Microsoft).

Vea cometer f5f5e7f, cometer 8325e43, cometer c0c2006, cometer 45a574e, cometer 28dc98e (16 de marzo de 2017) por jeff rey (peff).
(Fusionada por Junio ​​C Hamano - gitster -- in cometer 48b3693, 24 de marzo de 2017)

Makefile: fabricar DC_SHA1 el valor por defecto

Solíamos usar la implementación SHA1 de la biblioteca OpenSSL de forma predeterminada.
Como estamos tratando de tener cuidado con los ataques de colisión después del reciente anuncio "destrozado", cambie el valor predeterminado para alentar a las personas a usar la implementación DC_SHA1 en su lugar.
Aquellos que quieran usar la implementación de OpenSSL pueden solicitarlo explícitamente por OPENSSL_SHA1=YesPlease al correr"make".

En realidad, no tenemos una colisión Git-objeto, por lo que lo mejor que podemos hacer es ejecutar uno de los PDF destrozados a través de test-sha1. Esto debería activar la verificación de colisión y morir.


¿Se podría mejorar Git para vivir con eso, o tendría que cambiar a un nuevo algoritmo hash?

Actualización de diciembre de 2017 con Git 2.16 (Q1 2018): este esfuerzo para admitir un SHA alternativo está en marcha: consulte "¿Por qué Git no usa SHA más moderno?".

Podrás usar otro algoritmo hash: SHA1 ya no es el único para Git.


Git 2.18 (Q2 2018) documenta ese proceso.

Vea cometer 5988eb6, cometer 45fa195 (26 de marzo de 2018) por Ævar Arnfjörð Bjarmason (avar).
(Fusionada por Junio ​​C Hamano - gitster -- in cometer d877975, 11 abr 2018)

doctor hash-function-transition: aclarar lo que significa SHAttered

Intenta aclarar qué significa el ataque SHAttered en la práctica para Git.
La versión anterior del texto no mencionó en absoluto que Git ya tuviera una mitigación para este ataque específico, que según los investigadores de SHAttered detectará ataques de colisión criptoanalítica.

Es posible que haya entendido mal algunos de los matices, pero hasta donde yo sé, este nuevo texto resume con precisión la situación actual con SHA-1 en git. Es decir git ya no usa SHA-1, usa Hardened-SHA-1 (Da la casualidad de que producen los mismos resultados el 99.99999999999...% del tiempo).

Así, el texto anterior era incorrecto al afirmar que:

[...] Como resultado [de SHAttered], SHA-1 ya no puede considerarse criptográficamente seguro [...]

Ese no es el caso. Tenemos una mitigación contra SHAttered, sin embargo consideramos prudente pasar a trabajar hacia una NewHash en caso de que surjan futuras vulnerabilidades en SHA-1 o Hardened-SHA-1.

Entonces el nueva documentación ahora lee:

Git v2.13.0 y versiones posteriores se trasladaron posteriormente a una implementación SHA-1 reforzada de forma predeterminada, que no es vulnerable al ataque SHAttered.

Por lo tanto, Git ya migró a un nuevo hash que no es SHA-1 y no comparte sus vulnerabilidades, su nueva función hash produce exactamente el mismo resultado para todas las entradas conocidas, excepto dos PDF publicados por SHAttered investigadores, y la nueva implementación (escrita por esos investigadores) pretende detectar futuros ataques de colisión criptoanalítica.

De todos modos, se considera prudente pasar de cualquier variante de SHA-1 a un nuevo hash. No hay garantía de que futuros ataques a SHA-1 no se publiquen en el futuro, y es posible que esos ataques no tengan mitigaciones viables.

Si SHA-1 y sus variantes se rompieran realmente, la función hash de Git ya no podría considerarse criptográficamente segura. Esto afectaría la comunicación de los valores hash porque no podíamos confiar en que un valor hash determinado representara la buena versión conocida del contenido que pretendía el hablante.

Nota: ese mismo documento ahora (Q3 2018, Git 2.19) hace referencia explícita al "nuevo hash" como SHA-256: ver "¿Por qué Git no usa SHA más moderno?".

Respondido 21 ago 18, 07:08

Esta es la única respuesta o comentario decente aquí. El resumen es, aunque extremadamente improbable, es posible. También serían inmediatamente no identificables y se solucionarían ajustando un archivo (con un comentario) para evitar la colisión. Se cree que las explotaciones intencionales son irrelevantes, porque alguien podría verificar fácilmente el "código incorrecto", y hay cosas como firmas y solicitudes de extracción deliberadas para evitar que personas aleatorias verifiquen cosas aleatorias. - Brad

Gracias por ese increíble resumen. - Vankog

¿Se podría mejorar git para vivir con eso, o tendría que cambiar a un nuevo algoritmo hash?

Las colisiones son posibles para cualquier algoritmo hash, por lo que cambiar la función hash no elimina el problema, solo hace que sea menos probable que suceda. Entonces, debe elegir una función hash realmente buena (SHA-1 ya lo es, pero pidió que no se lo dijeran :)

Respondido 08 ago 16, 16:08

Creo que quieres decir "más improbable" o "menos probable", ¿verdad? Seguro podría cambiar a un algoritmo hash con menos bytes en la salida, pero eso no es lo que quieres decir, ¿verdad? :) - miguelk

SHA-1 está roto en el sentido de que será posible crear colisiones de hash deliberadas. Creo que ya lo fue en 2012 también. Por lo tanto, cambiar a un hash diferente que sea más seguro y tenga un estado y salida más grandes ciertamente marcaría la diferencia. - Maarten Bodewes

Google ahora afirma que la colisión SHA-1 es posible bajo ciertas condiciones previas: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Dado que git usa SHA-1 para verificar la integridad del archivo, esto significa que la integridad del archivo en git está comprometida.

En mi opinión, git definitivamente debería usar un mejor algoritmo hash ya que ahora es posible una colisión deliberada.

Respondido 24 Feb 17, 03:02

Además, sería prudente no confiar en la palabra de Linus con respecto a la seguridad informática. Ha estado equivocado antes, y está equivocado en este caso. (Por ejemplo, un oráculo de colisión SHA-1 permite crear historiales de compromiso circulares para colapsar servidores y clientes por igual) - Dom Q

Recientemente encontré una publicación del 2013 de abril de 04 en un grupo de discusión de BSD en

http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html

donde el cartel dice:

Me encontré con una colisión de hash una vez, usando git rebase.

Desafortunadamente, no proporciona ninguna prueba para su afirmación. Pero tal vez le gustaría tratar de contactarlo y preguntarle sobre este supuesto incidente.

Pero en un nivel más general, debido al ataque de cumpleaños, la posibilidad de una colisión de hash SHA-1 es de 1 en pow (2, 80).

Esto suena mucho y ciertamente es mucho más que el número total de versiones de archivos individuales presentes en todos los repositorios de Git del mundo combinados.

Sin embargo, esto solo se aplica a las versiones que realmente permanecen en el historial de versiones.

Si un desarrollador confía mucho en la reorganización, cada vez que se ejecuta una reorganización para una rama, todas las confirmaciones en todas las versiones de esa rama (o parte reorganizada de la rama) obtienen nuevos hashes. Lo mismo es cierto para cada archivo modificado con "git filter-branch". Por lo tanto, "rebase" y "filter-branch" pueden ser grandes multiplicadores de la cantidad de hashes generados a lo largo del tiempo, aunque no todos se mantengan: con frecuencia, después del rebase (especialmente con el propósito de "limpiar" una rama ), la rama original se desecha.

Pero si la colisión ocurre durante la reorganización o la ramificación del filtro, aún puede tener efectos adversos.

Otra cosa sería estimar el número total de entidades hash en los repositorios de git y ver qué tan lejos están de pow(2, 80).

Digamos que tenemos alrededor de 8 mil millones de personas, y todas ellas ejecutarían git y mantendrían sus cosas versionadas en 100 repositorios git por persona. Supongamos además que el repositorio promedio tiene 100 confirmaciones y 10 archivos, y solo uno de esos archivos cambia por confirmación.

Para cada revisión, tenemos al menos un hash para el objeto de árbol y el objeto de confirmación en sí. Junto con el archivo modificado, tenemos 3 hashes por revisión y, por lo tanto, 300 hashes por repositorio.

Para 100 repositorios de 8 mil millones de personas esto da pow(2, 47) que todavía está lejos de pow(2, 80).

Sin embargo, esto no incluye el supuesto efecto de multiplicación mencionado anteriormente, porque no estoy seguro de cómo incluirlo en esta estimación. Tal vez podría aumentar considerablemente las posibilidades de una colisión. Especialmente si los repositorios muy grandes que tienen un largo historial de confirmaciones (como el Kernel de Linux) son modificados por muchas personas para realizar pequeños cambios, que sin embargo crean hashes diferentes para todas las confirmaciones afectadas.

Respondido el 26 de enero de 18 a las 07:01

Interesante. +1. Como mencioné anteriormente, este problema desaparecerá eventualmente: stackoverflow.com/a/47838703/6309 - VonC

¡Una colisión de hash es tan poco probable que es alucinante! Los científicos de todo el mundo se esfuerzan por lograr uno, pero aún no lo lograron. Sin embargo, para ciertos algoritmos como MD5 tuvieron éxito.

¿Cuáles son las probabilidades?

SHA-256 tiene 2^256 hashes posibles. eso es sobre 10 78 ^. O para ser más gráfico, las posibilidades de una colisión son de aproximadamente

1 : 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

La probabilidad de ganar la lotería es de aproximadamente 1 : 14 millones. La posibilidad de una colisión con SHA-256 es como ganar la lotería en 11 días consecutivos!

Explicación matemática: 14 000 000 ^ 11 ~ 2 ^ 256

Además, el universo tiene alrededor de 10^80 átomos. Eso es solo 100 veces más que las combinaciones SHA-256.

Colisión MD5 exitosa

Incluso para MD5 las posibilidades son minúsculas. Sin embargo, los matemáticos lograron crear una colisión:

d131dd02c5e6eec4 693d9a0698aff95c 2fcab58712467eab 4004583eb8fb7f89
55ad340609f4b302 83e488832571415a 085125e8f7cdc99f d91dbdf280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2b487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080a80d1e c69821bcb6a88393 96f9652b6ff72a70

tiene el mismo MD5 que

d131dd02c5e6eec4 693d9a0698aff95c 2fcab50712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325f1415a 085125e8f7cdc99f d91dbd7280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e23487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080280d1e c69821bcb6a88393 96f965ab6ff72a70

Esto no significa que MD5 sea menos seguro ahora que su algoritmo está descifrado. Puede crear colisiones MD5 a propósito, pero la posibilidad de una colisión MD5 accidental sigue siendo 2^128, que sigue siendo mucho.

Conclusión

No tiene que preocuparse por las colisiones. Los algoritmos hash son la segunda forma más segura de verificar la uniformidad de los archivos. La única forma más segura es una comparación binaria.

Respondido 04 Abr '15, 21:04

Esta respuesta habla principalmente sobre SHA-256, lo cual es irrelevante ya que la pregunta era sobre SHA-1. Las matemáticas que muestran la improbabilidad de una colisión SHA-256 son mucho más optimistas de lo que resultaría un SHA-1. Todavía es muy poco probable, pero una respuesta SHA-1 habría sido más relevante. - andres arnott

@AndrewArnott No hay una diferencia relevante entre SHA-256 y SHA-1. SHA-1 es 2^128 veces más débil, pero esto tampoco importa. Todavía no se puede romper, así que mi respuesta no es so fuera de lugar - bytecode77

SHA-1 está realmente roto por lo que decir que "todavía no se puede romper" también es incorrecto. Dado que SHA-1 está roto, es posible que alguien ataque intencionalmente el algoritmo sha-1 de git para reemplazar el contenido sin ser detectado. SHA-256 aún no se ha roto, por lo que sería más seguro. Por lo tanto, responder a una pregunta sobre posibles colisiones de git sería mejor mantenerlo en SHA-1. - andres arnott

"Esto no significa que MD5 sea menos seguro ahora que su algoritmo está descifrado". ¿Llegar de nuevo? ¿Podrías explicar esa frase? - Maarten Bodewes

Motivo de la respuesta: porque hay mucha confusión entre las personas que no están familiarizadas con la informática y aún así aterrizan aquí después de buscar en la web. En mi experiencia, los conceptos erróneos sobre "cifrado versus poder de cómputo" son más comunes de lo que piensa, por lo que abordé esto como información adicional. - bytecode77

Bueno, supongo que ahora sabemos lo que sucedería: debe esperar que su repositorio se corrompa (fuente).

Respondido 25 Feb 17, 11:02

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.