¿Qué tan seguras son las etiquetas git firmadas? ¿Tan seguro como SHA-1 o de alguna manera más seguro?

No hay contradicción. El mismo Linus dijo en esa misma charla :

  

Si tengo esos 20 bytes, puedo descargar un repositorio git desde un   Fuente completamente no confiable y puedo garantizar que no lo hicieron   nada malo para ella.

Interpretaría el "Git usa SHA-1 no por seguridad" como "SHA-1 no se ha agregado a git por razones de seguridad, pero por razones de confiabilidad, pero la seguridad aún es un efecto secundario agradable ", y" Las partes de seguridad están en otra parte ", ya que" la verificación final se realiza mediante gpg y git verify-tag ".

Los ID de confirmación de Git no son "más seguros" que "SHA-1". Sin embargo, los casos de uso que se usan para git son más resistentes a los ataques de colisión, que la mayoría de los otros casos de uso de SHA-1.

Por ejemplo, SHA-1 en los certificados es peligroso. Alguien podría crear dos certificados con el mismo hash y para diferentes nombres de dominio. Uno (el "legítimo") se envía en una CSR a una CA, y el otro se mantiene en privado hasta que se usa en alguna víctima con la firma de la CA. Para ataques de colisión, si el atacante cambia la preimagen en una parte (como el campo de nombre de dominio del certificado), también debe cambiarlo en otra posición. Mientras que el atacante tenía libre elección para los dos nombres de dominio, los otros cambios son en su mayoría fijos. En particular, son binarios, y no pueden ser parte de ninguna parte del certificado legible por humanos. Algunos ataques los ocultan en las claves públicas / privadas del certificado ( discusión para MD5 ).

Sin embargo, Git se usa principalmente para el código fuente. Es mucho más difícil ocultar su {prefijo elegido} en una diferencia ASCII revisada por humanos. Los encargados de mantenimiento generalmente hacen preguntas cuando realiza una condición if sobre la dirección hexadecimal 2ff5e del archivo logo.png que agregó en la confirmación. Tomados juntos, es más fácil ocultar una puerta trasera dentro de un commit, que atacar SHA-1.

La etiqueta git firmada es solo una suma de comprobación SHA1 firmada. Dicho de manera muy simple, cada confirmación de git es la suma de comprobación SHA1 de la confirmación anterior (que también contiene SHA1 de su confirmación anterior, que también contiene la suma de comprobación SHA1 de su confirmación anterior y así ...).

Si encuentra una manera, cómo cambiar algo en un repositorio, manteniendo el SHA1 sin cambios (encuentra una colisión), entonces puede romper la firma.

Ten en cuenta que git se distribuye VCS. Por lo general, hay muchas personas que tienen sus propios clones. Se vería rápidamente, si hubiera algo mal.

Además, hay una gran diferencia entre encontrar una colisión y encontrar una colisión en particular. Por ejemplo, es fácil encontrar 2 datos diferentes "aleatorios" con la misma suma MD5. Pero, AFAIK, cómo cambiar los datos dados solo ligeramente y mantener el MD5 sin cambios sigue siendo un problema difícil y SHA1 es mucho más fuerte que el MD5.

Sin embargo, si alguien lograba encontrar una manera de encontrar colisiones SHA1 fácilmente, git tendría un problema mucho mayor. Git usa SHA1 como cada índice de objeto. Si intentas comprometer el objeto colisionado SHA1, probablemente romperías (... No estoy seguro de que ...) al menos la confirmación.

El siguiente es mi entendimiento.

Git identifica casi todo mediante hash sha1. La etiqueta firmada hace referencia al compromiso por su hash sha1, el compromiso identifica el "árbol" por su hash sha1 y el "árbol" hace referencia a los archivos por sus hashes sha1.

Entonces, si tiene dos archivos con el mismo hash sha1, podría reemplazar uno con el otro y la etiqueta firmada todavía se validaría.

En la práctica, creo que el riesgo depende en gran medida de lo que mantengas en tus repositorios de git. No tenemos un ataque de preimagen para SHA1 y es poco probable que tengamos tiempo pronto. Así que solo tenemos que preocuparnos por los ataques de colisión.

Si es un código fuente legible por humanos revisado por revisores humanos, el riesgo es pequeño. Si alguien puede deslizarse en un bloque de basura binaria inexplicable y un condicional que hace cosas malvadas basándose en el contenido de ese bloque de basura binaria, probablemente pueda meterse en cosas maliciosas sin tener que preocuparse por las colisiones sha1.

OTOH, si se está utilizando para almacenar archivos binarios originados en fuentes no confiables, existe un mayor potencial de problemas.

  

"es poco probable que tengamos tiempo pronto" - hmm. "Los ataques solo mejoran".

Los ataques de preimagen son MUCHO más difíciles que los ataques de colisión. Una década después de que se demostraron las primeras colisiones para MD5, todavía no tenemos un ataque de preimagen factible.

  

Estaría más preocupado por dos confirmaciones que contienen "jpeg + código inocente" y "jpeg + código malvado"

La complicación se debe a la forma en que las confirmaciones de git están estructuradas en los datos jpeg y el código debería estar en el mismo archivo. Supongo que podría ser un problema si las personas almacenan archivos comprimidos en su repositorio git o algo así.

Otro escenario posible sería si algún código decidiera qué hacer con un archivo basado en la detección automática del tipo de archivo. Si una colisión de "prefijo elegido distinto" se vuelve práctica, entonces alguien podría cometer un archivo binario de apariencia inocua (una imagen o algo así) que resultó tener un montón de basura en alguna parte. Luego reemplázalo con un archivo más peligroso.

Para la comparación con md5, tomó alrededor de 2 años pasar de las colisiones básicas a las distintas colisiones de prefijos elegidos.