SHA-1 vs SHA-256: SHA-1 está muerto, pero Git sigue usándolo

Resumen. SHA-1 está criptográficamente roto — Google demostró una colisión práctica en 2017 y los ataques de prefijo elegido se volvieron asequibles en 2020 — así que usa SHA-256 para cualquier nueva aplicación de seguridad. Git sigue usando SHA-1 para hashes de objetos pero está migrando; las huellas digitales no relacionadas con la seguridad (cachés, deduplicación) no se ven afectadas.

SHA-1 (salida de 160 bits, 1995) y la familia SHA-2 (salidas de 256/384/512 bits, 2001) son ambas funciones hash criptográficas publicadas por NIST. SHA-1 fue el hash de integridad dominante durante la década de 2000. Ahora está deprecado en todos los lugares donde importa la seguridad — pero aún no en todos los lugares.

El resumen

Cómo se rompió SHA-1

Una función hash criptográfica debe hacer computacionalmente inviable encontrar dos entradas que produzcan el mismo hash. La salida de 160 bits de SHA-1 daba una resistencia a colisiones de 2⁸⁰ en papel — muy por encima de los presupuestos de fuerza bruta en el momento del diseño en 1995.

Tres hitos erosionaron eso:

1. 2005: Wang, Yin y Yu publicaron un ataque teórico que reducía la búsqueda de colisiones a ~2⁶⁹ operaciones — todavía inviable en ese momento pero una advertencia clara.
2. 2017: El proyecto SHAttered de Google demostró la primera colisión práctica de SHA-1: dos PDFs con el mismo hash SHA-1. Coste: ~110.000 $ de cómputo en GPU y 9 trillones de evaluaciones SHA-1.
3. 2020: Leurent y Peyrin publicaron un ataque de colisión de prefijo elegido — dados dos encabezados de archivo arbitrarios, añade bytes cuidadosamente elaborados y produce archivos que colisionan. Coste: ~45.000 $ en cómputo en nube. Este es el tipo de ataque que permite falsificar certificados y suplantar firmas en la práctica.

Después de 2020, SHA-1 es inadecuado para cualquier propósito de seguridad donde la falsificación sea relevante.

Dónde SHA-1 sigue siendo aceptable

Las huellas digitales no adversariales — donde no hay incentivo de atacante para falsificar colisiones — siguen estando bien con SHA-1:

• Hashes de objetos commit y tree de Git. Un atacante que falsifique una colisión necesitaría inyectar commits elaborados y que sean aceptados en los espejos principales. Git también ejecuta la detección de patrones de ataque conocidos (la detección de SHAttered) en cada operación, haciendo visible la inyección de ataques.
• Almacenamiento direccionable por contenido donde tú controlas todas las entradas (cachés de compilación, deduplicación de CDN).

Incluso en estos casos, SHA-256 es el valor predeterminado correcto para nuevos sistemas. La brecha de rendimiento (SHA-256 es ~40% más lento que SHA-1 en la mayoría de CPUs modernas) es irrelevante para casi todas las cargas de trabajo.

Dónde SHA-256 es obligatorio

• Firmas de certificados TLS. Los navegadores dejaron de aceptar SHA-1 en 2017.
• Firmas JWT (HS256, RS256, ES256). El 256 es SHA-256.
• Firma de código. Microsoft y Apple dejaron de aceptar firmas SHA-1 alrededor de 2016-2017.
• Cualquier lugar donde los ataques de colisión habilitarían la falsificación. Firmas de documentos, criptomonedas, pruebas de identidad.

La migración de Git

Git ha estado migrando a SHA-256 desde 2018. La migración es técnicamente sencilla pero lleva tiempo porque cada servidor Git, cada sistema CI/CD, cada gestor de dependencias tiene que admitir ambos. Estado a partir de 2026:

• Los repositorios SHA-256 funcionan de extremo a extremo en Git moderno.
• GitHub admite repos SHA-256 pero usa SHA-1 por defecto para nuevos repos.
• GitLab y Bitbucket: soporte parcial, varía según la versión.
• La mayoría de las integraciones CI funcionan con ambos.

El comportamiento predeterminado para el CLI de Git sigue siendo SHA-1. Para crear un repositorio SHA-256: git init --object-format=sha256. Una vez que la migración se complete — probablemente en el plazo de 2027-2028 — el valor predeterminado cambiará.

La regla pragmática

• Para nuevos sistemas: SHA-256. Siempre. La brecha de rendimiento no importa.
• Para sistemas SHA-1 heredados: migra cuando sea factible, pero no entres en pánico — la amenaza es real pero específica.
• Para Git específicamente: SHA-1 está bien por ahora. Observa cómo SHA-256 se convierte en el predeterminado.
• Para TLS, firma de código, JWT, cripto: SHA-256 ya era la única opción aceptable.

Calcula ambos hashes con nuestro generador de hash.

Datos numéricos

• Longitud hex: SHA-1 = 40 chars (160 bits); SHA-256 = 64 chars (256 bits); base64url = 27 chars vs 43 chars sin relleno.
• Resistencia a colisiones por el cumpleaños: SHA-1 ~2⁸⁰ genérico, bajó a ~2⁶¹ después del ataque SHAttered de 2017; SHA-256 permanece ~2¹²⁸.
• Coste SHAttered (2017): 9.223.372.036.854.775.808 evaluaciones SHA-1, ~110.000 $ en tiempo de GPU en nube, equivalente a 6.500 años-CPU.
• Ataque de prefijo elegido (Leurent & Peyrin, 2020): ~45.000 $ en AWS — asequible para operaciones criminales de tamaño mediano.
• Rendimiento en Intel SHA-NI (Ice Lake / Zen 3+): SHA-1 ~2,1 GB/s/núcleo; SHA-256 ~1,9 GB/s/núcleo — la aceleración por hardware reduce la brecha a ~10%, no 40%.
• Sin aceleración por hardware: SHA-1 ~700 MB/s frente a SHA-256 ~400 MB/s — la brecha heredada de ~40% que la gente cita.
• Tamaño de bloque: ambos usan bloques de 512 bits; SHA-1 produce un estado de 160 bits, SHA-256 un estado de 256 bits.
• Navegadores en 2017: Chrome 56, Firefox 51, Edge — todos dejaron de aceptar certificados TLS SHA-1 el 24 de enero de 2017.

Matriz de decisión

Fuentes

• NIST FIPS 180-4 — Secure Hash Standard — csrc.nist.gov/pubs/fips/180-4.
• Stevens, M. et al. — The first collision for full SHA-1, CRYPTO 2017 (SHAttered) — shattered.io.
• Leurent, G. & Peyrin, T. — SHA-1 is a Shambles, USENIX Security 2020 — sha-mbles.github.io.