SHA-1 fue estandarizado por la NSA. Parece que es posible elegir las constantes de tal manera que las colisiones puedan derivarse fácilmente. Sin embargo, no es fácil descubrir que las constantes se han elegido de esa manera.
¿Habría sido posible para la NSA insertar una puerta trasera en SHA-1 usando esta técnica? ¿Habría alguna forma de averiguarlo? ¿Existen implicaciones de seguridad con respecto al estándar SHA-1?
Este ataque no se trata de generar un SHA-1 modificado que facilita las colisiones, se trata de generar un SHA-1 modificado como parte del proceso de generar una colisión específica . La función hash modificada así producida solo es útil para crear la colisión única utilizada en el proceso de generación; en general no es más vulnerable a las colisiones que el SHA-1 común. Consulte la parte inferior de la página 5 de el documento de investigación .
Las constantes en SHA-1 ordinario son las raíces cuadradas de 2, 3, 5 y 10, veces 2 ^ 30. Sí, es posible que esos cuatro números hayan sido seleccionados porque permiten la creación de una colisión única de gran valor en algún lugar, pero es poco probable.
No puedo decir si este método se usó en alguna parte. Probablemente sea difícil de descubrir. Sin embargo, no es posible utilizar esta técnica para explotar implementaciones ya existentes de SHA-1 que no han sido diseñadas para ser débiles por propósito. SHA-1 sigue siendo seguro de usar (tan seguro como lo era antes). El documento al que se refiere solo muestra cómo, al usar ciertas constantes, puede hacer que SHA-1 sea inseguro y obtener colisiones con mayor facilidad.
Supongamos que tiene un programa binario que usa SHA-1 para algún tipo de cifrado. Teóricamente es posible que su programa no haga uso de una función SHA-1 "segura", pero que el proveedor (la NSA o quien sea) haya escrito su propia implementación y haya modificado las constantes en consecuencia o simplemente se haya equivocado por accidente. Entonces la implementación SHA-1 de ese programa específico no es segura.
Sin embargo, si tiene la fuente de un software y probablemente incluso lo compiló usted mismo, puede verificar que la implementación de SHA-1 sea correcta. Si el software hace uso de implementaciones "oficiales" de SHA-1 que vienen con muchos lenguajes de programación (python, perl, java - lo que sea) no debería haber ningún problema.
Este tipo de ataque no es algo que pueda usarse para atacar software ya existente: el software (la implementación SHA-1 que usa) ya debe estar comprometido de antemano.
Creo que esta pregunta es crítica, pero aquí está mi opinión.
SHA-1 está estandarizado. Las constantes utilizadas se describen en RFC3174 . Ese artículo describe la modificación de las constantes de una implementación SHA-1 para inducir colisiones.
Ahora, tu pregunta, ¿se seleccionaron las constantes en RFC3174 de forma que la NSA pudiera producir colisiones? Podría hacer esta misma pregunta sobre cualquier estándar que se haya derivado en los últimos 20 años. Si modificas algo para que actúe de una manera no fue diseñado; Sí, pueden ocurrir cosas maliciosas.
Yo diría que las probabilidades en favor de que no haya backdoor. Se ha estandarizado durante casi 15 años, demasiadas personas lo han implementado y demasiadas personas lo han analizado. El trabajo de investigación dice que no podían hacer el mismo procedimiento con las constantes actuales. En mi opinión, si SHA-1 tuviera fallas / puertas traseras, ya se habría encontrado. Si no te gusta puedes usar otra cosa.
Lea otras preguntas en las etiquetas hash cryptography sha