Primero, SHA-256 es significativamente más rápido (generalmente) que SHA-512, y es lo suficientemente fuerte para la gran mayoría de los usos.

Segundo, puedes truncar la salida de hash , siempre que estés al tanto de la" paradoja del cumpleaños ", por ejemplo, 160 bits de salida te dan ~ 80 bits de seguridad. Probablemente desee evitar el truncado si es posible, pero si necesita hacerlo, el SHA-256 truncado a 160 bits es mejor que el SHA-1 en este momento.

Tenga en cuenta que todos los ataques SHA-1 recientes se basan en colisiones: no hay ataques de preimagen ni de 2º pre, incluso contra MD5, por lo que no es posible "revertir" (actualmente).

Has redactado dos cosas diferentes aquí:

• para certificados SSL que usan SHA1 para HMAC aún es seguro, no es necesario cambiarlo (vea esto publicación relacionada )
• para usos regulares (por ejemplo, verificación de integridad) no hay un mejor algoritmo mejor usado en 160 bits. Podría valer la pena tener en cuenta que, dependiendo del algoritmo, truncar un hash de más bits podría ser una mejor opción ( vea este tema )

  

Esto no es un problema si el hash solo lo usan las máquinas, pero para   p.ej. La verificación manual de la integridad del archivo es demasiado larga.

Esto no es un problema, en el 99,999% de los casos puede determinar la falta de coincidencia con su ojo. De lo contrario, puedes comparar sumas de comprobación en tu terminal, lo cual es tan fácil como este 8 liner que acabo de escribirte en menos de 30 segundos (llámalo sha1check.sh )

#!/usr/bin/env sh

if [ 'sha1sum $1 | cut -d' ' -f1' = "$2" ]; 
then
   echo 1
 else 
   echo 0
fi

Uso:

$ sha1check.sh file.zip ffc06e14fb40db2da3ce0117b4483a8f0ca86937
0

PS: La primera colisión exitosa de sha1 se publicó hace una semana, y sus detalles técnicos se mantienen privados. Es muy poco probable que otra persona que no sea Google use esto.