¿Por qué Git no usa SHA más moderno?

Leí acerca de que Git usa el resumen SHA-1 como identificación para una revisión. ¿Por qué no usa una versión más moderna de SHA?

ACTUALIZACIÓN : La pregunta anterior y esta respuesta son de 2015. Desde entonces, Google ha anunciado la primera colisión SHA-1: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html


Obviamente, solo puedo especular desde afuera con respecto a por qué Git continúa usando SHA-1, pero estas pueden ser algunas de las razones:

  1. Git fue la creación de Linus Torvald, y Linus aparentemente no quiere sustituir SHA-1 con otro algorithm de hash en este momento.
  2. Él hace afirmaciones plausibles de que los exitosos ataques basados ​​en colisiones SHA-1 contra Git son mucho más difíciles que lograr las colisiones en sí mismas, y considerando que SHA-1 es más débil de lo que debería ser, no está completamente roto, eso lo hace sustancialmente lejos de una ataque viable al less hoy. Además, señala que un ataque "exitoso" lograría muy poco si el object en colisión llega más tarde que el existente, ya que el último se supondría que es el mismo que el válido e ignorado (aunque otros han señalado que lo contrario podría ocurrir).
  3. Cambiar el software lleva mucho time y es propenso a errores, especialmente cuando existe una infraestructura existente y datos basados ​​en los protocolos existentes que deberán migrarse. Incluso aquellos que producen productos de software y hardware donde la security criptográfica es el único punto del sistema todavía están en el process de migrar de SHA-1 y otros algorithms débiles en algunos lugares. Imagínense todos esos búfers unsigned char[20] codificados de unsigned char[20] todos lados ;-), es mucho más fácil progtwigr la agilidad criptográfica desde el principio, en lugar de volver a instalarla más tarde.
  4. El performance de SHA-1 es mejor que los diversos hashes SHA-2 (probablemente no tanto como para romper el trato ahora, pero tal vez fue un punto de fricción hace 10 años), y el tamaño de almacenamiento de SHA-2 es mayor .

Algunos enlaces:

  • Pregunta de Stackoverflow sobre lo que sucedería si ocurriera una colisión en Git
  • Publicación de un grupo de noticias que muestra un breve comentario de Linus sobre el tema un par de meses después de que se conociera la debilidad principal de SHA-1 en 2005
  • Un hilo que discute la debilidad y posible cambio a sha-256 (con respuestas de Linus) en 2006
  • Declaración NIST sobre desaprobación de SHA-1 y recomendación de "transición rápida a la familia SHA-2 más fuerte de funciones hash"

Mi punto de vista personal sería que, si bien los ataques prácticos probablemente tengan algún time libre, e incluso cuando ocurran, las personas probablemente mitigarán inicialmente con medios distintos a cambiar el algorithm hash en sí, que si te preocupa la security debes estar equivocado por precaución con sus elecciones de algorithms, y continuamente revisando hacia arriba sus puntos fuertes de security, porque las capacidades de los atacantes también van solo en una dirección, por lo que no sería prudente tomar a Git como un model a seguir, especialmente porque su propósito en usar SHA-1 no pretende ser una security criptográfica.

Esta es una discusión sobre la urgencia de emigrar de SHA1 para Mercurial, pero también se aplica a Git: https://www.mercurial-scm.org/wiki/mpm/SHA1

En resumen: si hoy no eres extremadamente diligente, tienes vulnerabilidades mucho peores que sha1. Pero a pesar de eso, Mercurial comenzó hace más de 10 años para prepararse para la migration de sha1.

el trabajo ha estado en marcha durante años para adaptar las estructuras de datos y los protocolos de Mercurial para los sucesores de SHA1. El espacio de almacenamiento se asignó para hashes más grandes en nuestra estructura de revlog hace más de 10 años en Mercurial 0.9 con la introducción de RevlogNG. El formatting bundle2 introducido más recientemente admite el intercambio de diferentes types de hash a través de la networking. Las únicas piezas restantes son la elección de una function de reemploop y la elección de una estrategia de compatibilidad con versiones anteriores.

Si git no se aleja de sha1 antes de Mercurial, siempre se puede agregar otro nivel de security manteniendo un espejo Mercurial local con hg-git .