¿Por qué se siguen utilizando MD5 y SHA-1 para las sumas de comprobación y los certificados si se llaman rotos?

SHA-1 y MD5 se rompen en el sentido de que son vulnerables a los ataques de colisión. Es decir, se ha vuelto (o, para SHA-1, pronto será) encontrar dos cadenas que tengan el mismo hash.

Como se explica aquí , los ataques de colisión no afectan directamente a las contraseñas ni a la integridad de los archivos porque están comprendidos en la preimagen y segundo caso de preimagen, respectivamente.

Sin embargo, MD5 y SHA-1 son aún menos costosos computacionalmente. Las contraseñas con estos algoritmos son más fáciles de descifrar que los algoritmos más fuertes que existen actualmente. Aunque no está específicamente roto, es recomendable usar algoritmos más fuertes.

En el caso de los certificados, las firmas indican que un hash de un certificado en particular es válido para un sitio web en particular. Pero, si puede elaborar un segundo certificado con ese hash, puede hacerse pasar por otros sitios web. En el caso de MD5, esto ya sucedió, y los navegadores eliminarán el SHA-1 pronto como medida preventiva ( source ).

La verificación de la integridad del archivo a menudo está destinada a garantizar que un archivo se haya descargado correctamente. Pero, si se usa para verificar que el archivo no se manipuló maliciosamente, debe considerar un algoritmo que sea más resistente a las colisiones (consulte también: ataques de prefijo elegido ).

Para MD5, nadie con reputación y competencia lo está usando en un contexto donde la resistencia a la colisión es importante. Para SHA-1, se está eliminando gradualmente; La ruptura de SHA-1 no era práctica cuando se lanzó, y solo ahora es importante pensar en eliminarla donde se necesita resistencia a la colisión. De hecho, está siendo eliminado; por ejemplo, los certificados TLS a largo plazo con SHA-1 ya no funcionan en Chrome, para incitar a las personas a cambiar a SHA-2. Sin embargo, todavía no está prácticamente roto, por lo que es aceptable por ahora.

La razón por la que no se eliminó para todo de inmediato es porque la seguridad implica concesiones. No abandona un estándar importante y hace que todo sea incompatible con una base de instalación gigante por algo que podría llevar a ataques prácticos en el transcurso de una década. La compatibilidad importa.

Además, para muchos usos, MD5 y SHA-1 no están agrietados en absoluto. Ambos tienen debilidades contra la resistencia a la colisión, lo que significa que un atacante puede crear dos mensajes que se relacionan con la misma cosa. Tampoco se rompe contra la resistencia de preimagen (dado un hash, encuentra algo que hace ese hash), o contra la resistencia de segunda preimage (dado un mensaje, encuentra un mensaje diferente con el mismo hash), o (sus funciones de compresión) como pseudoaleatorio funciones Eso significa que las construcciones como HMAC-MD5 todavía pueden ser seguras, porque no se basa en la propiedad de MD5 que está rota. Menos que lo ideal, seguro, pero consulte "la compatibilidad es importante si aún es seguro" más arriba.

La verificación de la integridad del archivo a través de hashes es casi siempre inútil de todos modos; a menos que los hashes se envíen a través de un canal más seguro que el archivo, puede manipular los hashes tan fácilmente como con el archivo. Sin embargo, si los hashes se se envían de forma más segura que el archivo, MD5 y SHA-1 aún son capaces de proteger la integridad del archivo. Debido a que el atacante no tiene ninguna influencia sobre los archivos legítimos (y tiene que haber cero para estar realmente seguro), crear un nuevo archivo con el mismo hash requiere rompiendo la segunda resistencia de preimagen, que nadie ha hecho para MD5 o SHA-1.

Note la diferencia entre la verificación de integridad y los certificados. Los certificados son emitidos por una CA desde un CSR creado por el usuario; el atacante puede tener una gran influencia sobre el contenido del certificado real, por lo que un ataque de colisión permite a un atacante crear un certificado legítimo y falso que colisiona, obtener el legítimo emitido y usar la firma del falso. Por el contrario, en la integridad del archivo, el atacante normalmente no tiene control sobre el archivo legítimo, por lo que debe colisionar con un archivo dado , que es mucho más difícil (y que, por lo que sabemos, no puede hacerse con MD5).

MD5 y SHA-1 son rápidos y pueden ser compatibles con hardware, en contraste con hashes más nuevos y más seguros (aunque Bitcoin probablemente cambió esto con su uso de SHA-2 dando lugar a minería chips que computan las colisiones SHA-2 parciales).

colisiones de MD5 son factibles y se han realizado avances de ataque de preimagen; está una colisión SHA-1 conocida públicamente para el algoritmo de ronda completa oficial, después de otros que reduce significativamente su complejidad efectiva , que puede que aún no sea lo suficientemente práctico para el atacante ocasional, pero en el ámbito de las posibilidades, por lo que puede llamarse roto.

No obstante, los hashes "débiles" o rotos pueden ser buenos para los usos que no necesitan algoritmos criptográficos seguros, pero muchos propósitos que originalmente no se consideraron críticos más tarde pueden resulta para exponer una superficie de ataque potencial.

Los buenos ejemplos serían encontrar archivos duplicados o usarlos en sistemas de control de versiones como git. En la mayoría de los casos, usted desea un buen rendimiento con alta confiabilidad, pero no necesita seguridad estricta, lo que le da a alguien acceso de escritura. un repositorio oficial de git ya requiere que confíes en otras personas para que no jueguen, y las verificaciones de duplicación deben comparar los contenidos después de encontrar que dos archivos tienen el mismo tamaño y hash.

Hacer copias de seguridad de hashes no seguros con datos (por ejemplo, una comparación byte por byte) puede ser un riesgo, por ejemplo. cuando alguien como Dropbox tenía deduplicación con MD5 sin la verificación adecuada y un atacante se cuela en los datos con hashes en colisión para causar la pérdida de datos.

git resuelve este problema por "trusting el anciano ", como Linus mismo dijo:

  

    

si ya tiene un archivo A en git con hash X, ¿existe alguna condición para que un     archivo remoto con hash X (pero contenidos diferentes) sobrescribiría el local     versión?

  

     

No. Si tiene el mismo SHA1, significa que cuando recibimos el   objeto desde el otro extremo, no sobrescribiremos el objeto que   ya tengo.

     

Entonces, lo que sucede es que si alguna vez vemos una colisión, el "anterior"   El objeto en cualquier repositorio particular siempre terminará anulando.   Pero tenga en cuenta que "anterior" es obviamente por repositorio, en el sentido   que la red de objetos git genera un DAG que no es completamente   ordenado, por lo que mientras diferentes repositorios estarán de acuerdo sobre lo que es   "anterior" en el caso de ascendencia directa, si el objeto llegó a través   ramas separadas y no directamente relacionadas, dos repos diferentes pueden   obviamente han conseguido los dos objetos en orden diferente.

     

Sin embargo, el "anterior anulará" es mucho lo que quieres de un   punto de vista de seguridad: recuerda que el modelo git es que debes   Principalmente confía solo en tu propio repositorio. Así que si haces un "git pull",   Los nuevos objetos entrantes son, por definición, menos confiables que los   objetos que ya tiene, y como tal, sería incorrecto permitir una   Nuevo objeto para reemplazar uno viejo.

[Fuente original: enlace

Y como dicen, una falla de disco es sin duda más probable que encontrar una colisión de hash accidental (varios órdenes de magnitud - colisión SHA-1 < 10 ^-40 ; error de bit no recuperable del disco ~ 10 ^-15 ).

Si bien pueden existir colisiones, es poco probable que la verificación de la integridad de un archivo cuando existe tanto un MD5 como un SHA1 permita una colisión. así que si ambas de estas comprobaciones simples validan el mismo archivo, es suficiente. Casi nunca veo a la gente verificar uno de ellos en la mayoría de los casos de todos modos.