¿Sha1sum sigue siendo seguro para la firma de paquetes de software descargables?

Supongo que "usa sha1sum " en el siguiente contexto: distribuye algunos paquetes de software y desea que los usuarios puedan verificar que lo que descargaron es el paquete correcto, hasta el último bit. Esto supone que tiene una forma de transmitir el valor de hash (calculado con SHA-1) de manera "inalterable" (por ejemplo, como parte de una página web que se sirve a través de HTTPS).

También supongo que estamos hablando de ataques , es decir, algunas personas malintencionadas que de alguna manera pueden alterar el paquete a medida que se descarga, y querrán inyectar alguna modificación que no se detectará.

La propiedad de seguridad que la función hash utilizada debería ofrecer aquí es resistencia a las segundas imágenes previas . Lo más importante es que no es lo mismo que la resistencia a las colisiones. Una colisión es cuando el atacante puede crear dos mensajes distintos m y m ' que contienen el mismo valor; una segunda imagen previa es cuando al atacante se le da un m fijo y se lo desafía a encontrar un m ' distinto que haga hashes al mismo valor.

Las segundas preimágenes son mucho más difíciles de obtener que las colisiones. Para una función hash "perfecta" con bits de tamaño de salida n , el esfuerzo computacional para encontrar una colisión es de aproximadamente 2 ^{n / 2} invocaciones de función hash; para una segunda imagen previa, esto es 2 ⁿ . Además, las debilidades estructurales que permiten un ataque de colisión más rápido no se aplican necesariamente a un ataque de segunda preimagen. Esto es cierto, en particular, para las debilidades conocidas de SHA-1: en este momento (septiembre de 2015), existen algunas debilidades teóricas conocidas de SHA-1 que deberían permitir el cálculo de una colisión en menos del ideal 2 ^{Esfuerzo de 80} (esto sigue siendo un gran esfuerzo, aproximadamente 2 ⁶¹ , por lo que aún no se ha demostrado); pero estas debilidades son caminos diferenciales que requieren intrínsecamente que el atacante diseñe tanto m como m ', por lo tanto, no se transfieren a las segundas preimágenes.

Por el momento, no se conoce un ataque de segunda imagen en SHA-1 que sea teórica o académicamente más rápido que el ataque genérico, con un costo de 2 ¹⁶⁰ que va mucho más allá de lo tecnológico. viabilidad, por un toma larga .

Conclusión: dentro del contexto de lo que está tratando de hacer, el SHA-1 es seguro y es probable que permanezca seguro durante algún tiempo (incluso MD5 aún sería apropiado).

Otra razón para usar sha1sum es la disponibilidad de las herramientas del lado del cliente: en particular, la herramienta de hashing de línea de comandos proporcionada por Microsoft para Windows (llamada FCIV ) conoce MD5 y SHA-1, pero no SHA-256 (al menos así lo dice la documentación) (*).

^{Windows 7 y versiones posteriores también contienen una herramienta de línea de comandos llamada "certutil" que puede calcular los hashes SHA-256 con el subcomando "-hashfile". Esto no se conoce ampliamente, pero a veces puede ser conveniente.}

Dicho esto, una poderosa razón contra que usa SHA-1 es la de imagen : actualmente está muy de moda abuchear y burlarse de cualquier uso de SHA-1; las multitudes claman por su remoción, anatema, arresto y ejecución pública. Al usar SHA-1, le estás diciendo al mundo que, definitivamente, no eres un hipster. Desde un punto de vista empresarial, rara vez es bueno no ceder a la moda du jour , por lo que debería usar una de las funciones SHA-2, por ejemplo. SHA-256 o SHA-512.

No hay una razón sólida para preferir SHA-256 a SHA-512 o al revés; algunas arquitecturas pequeñas de solo 32 bits se sienten más cómodas con SHA-256, pero esto rara vez es importante en la práctica (incluso una implementación de SHA-512 de 32 bits aún podrá contener tres docenas de megabytes de datos por segundo en una anemia) una computadora portátil, e incluso en modo de 32 bits, una CPU x86 no muy antigua tiene algunas capacidades en los cálculos de 64 bits con SSE2, lo que proporciona un buen impulso para SHA-512). Cualquier experto en marketing le diría que use SHA-512 sobre la única base de que 512 es mayor que 256, por lo que "debe ser mejor" de alguna manera (mágica).

Debes usar SHA-256 o SHA-512.

Si solo está firmando paquetes que usted mismo ha creado, entonces, técnicamente, SHA-1 sigue siendo seguro para ese propósito. La propiedad que ahora está debilitada es la "resistencia a la colisión" en la que no está confiando estrictamente. Sin embargo, la seguridad de SHA-1 solo empeorará con el tiempo, por lo que tiene sentido seguir adelante.

Tom Leak tiene una hermosa respuesta (razón por la cual se acepta). Se refiere a los hechos demostrables matemáticamente detrás del uso de SHA-1. Hay un segundo enfoque que se basa menos en los hechos pero que puede proporcionar información heurística valiosa. Aprendí este enfoque al leer las opiniones de Bruce Schneier, pero no puedo encontrar los enlaces de inmediato, por lo que Bruce tendrá que lidiar con mi eliminación de nombre.

En teoría, un algoritmo no se rompe hasta que se rompe. Hasta que alguien haya encontrado una forma de hacer X, donde X es algo que debería ser computacionalmente inviable, no se considera "roto". ¹ Sin embargo, eso demuestra ser de valor limitado en su aplicación práctica en criptografía. Los criptógrafos realmente preferirían recibir una pequeña notificación antes de que sus productos se desmoronen, no después.

Lo que se ha encontrado, históricamente, es que los algoritmos rara vez se rompen en un gran paso. Sí, puede suceder, y un criptógrafo tiene que planificar para eso, pero lo que se ha encontrado empíricamente es que normalmente se reducen con el tiempo, papel tras papel. Se ha encontrado que observar la dificultad de generar una colisión es una métrica razonablemente buena para estimar cuándo se romperá el algoritmo. Entonces, cuando Tom señala que la colisión debe tomar 2 operaciones ⁸⁰ y ahora toma 2 ⁶¹ , es muy válido señalar, como lo hizo, que el 2 ⁶¹ las operaciones son teóricas, porque todavía son demasiado grandes para justificar un intento. Sin embargo, también es válido pensar en él como "el algoritmo ha experimentado una reducción en la potencia de 19 bits de potencia" y utilizarlo como la regla empírica de un hombre pobre para proyectar hacia adelante y estimar cuándo se convertirá en un problema.

Este tipo de pensamiento es la razón por la cual ahora hay un SHA-3, aunque en teoría SHA-1 todavía no está completamente roto. Los criptógrafos involucrados en el desarrollo y las pruebas de SHA-3 saben que tomará bastante tiempo desarrollar confianza en SHA-3, y quieren asegurarse de que haya confianza antes de que SHA-1 se rompa, no después.

^1. Soy consciente de que la definición más estricta desde el punto de vista técnico de un hash "roto" es simplemente uno en el que un atacante puede hacerlo mejor que la fuerza bruta, a diferencia de cuando se vuelve computacionalmente viable. Sin embargo, esta última definición se usa más a menudo cuando se analiza el lado práctico del hash.

Incluso si no está haciendo un trabajo para el gobierno federal, el enlace al documento a continuación es una buena referencia de cuánto tiempo las personas deben usar las longitudes de clave hash hasta fechas futuras para tareas específicas como autenticar una firma. Para la autenticación de paquetes, también incluiría un tamaño que hace que sea mucho más difícil crear una colisión (paquete modificado que coincida con el mismo hash). ¿Por qué no usarías tanto SHA1 como SHA512 (si el tiempo de cómputo no es tan gravoso)? También tenga en cuenta la longitud de la clave asimétrica utilizada para firmar el hash dado. Si bien es genial que esté pensando en esto, probablemente haya otros problemas de integridad más apremiantes, como por ejemplo, asegurarse de que una persona no reciba un hash falsificado para la comparación y la fuente de todas las bibliotecas incluidas que serían más de un riesgo.

P.S. Si está pensando en certificados para un navegador, tanto Chrome como IE van a tener o han establecido una interfaz de usuario acerca de cómo utilizar el SHA1. Si está almacenando contraseñas, busque los hashes salados (y posiblemente salpimentados) con PBKDF2.

enlace enlace enlace

Para el propósito previsto, la respuesta práctica es "Sí, por supuesto", aunque por razones de prestigio también debe publicar un hash más reciente (como SHA-3).
Si no tuviera tanto "olor", en principio podría seguir usando MD5 (aparte de las personas que le gritan, incluso MD5 funcionará bien para esta aplicación).

El uso de SHA-1 para verificar las descargas nunca ha sido "seguro" y principalmente no está destinado a ser. El propósito principal de proporcionar un hash (de cualquier tipo) es detectar errores de bit, descargas parciales o descargar accidentalmente el ejecutable incorrecto (hacer clic en la fila de arriba o abajo en la lista y no darse cuenta).

Las modificaciones malintencionadas son un problema que no se resuelve muy bien con un hash, ya que un atacante que tiene suficiente acceso al servidor para que pueda reemplazar el binario generalmente también puede reemplazar el hash.
Podría decirse que usted obtiene algo de seguridad si usa un CDN, ya que alguien que obtiene acceso a un nodo en el CDN no puede reemplazar exitosamente el binario en ese nodo sin el usuario (que descarga el hash desde el servidor que solo usted controle).

Sin embargo, si necesita algo que debe ser "seguro" y resistente a la modificación malintencionada, debe firmar digitalmente sus ejecutables de manera definitiva e incluir, por ejemplo, una firma GPG. Un hash no servirá.

¿Aún puedes usarlo? ... Sí, puedes, pero sha-1 es vulnerable a los ataques de colisión y ha sido rechazado por varios navegadores.

Si la pregunta era si todavía lo usas, entonces diría que no, no deberías, deberías pasar al programa de tipo sha-2 y sha256sum.

Hay mejores opciones que SHA2. Blake2, por ejemplo, es un finalista de la competencia SHA3, y blake2-256 es tan rápido como SHA1 y mucho más rápido que SHA2. Puede utilizarse como el algoritmo de suma de comprobación en Winrar 5. Al igual que MD5 y SHA1, SHA2 se basa en la estructura de Merkle-Damgard y tiene vulnerabilidades similares. SHA3 no es vulnerable, pero SHA3-224 es ca. 8 veces más lento que SHA1.