SHA-1 vs SHA-256 vs SHA-512: Elegir el algoritmo de hash correcto en 2026

Abra un certificado TLS, una base de datos de objetos de Git, una cabecera de bloque de Bitcoin, un gestor de paquetes de Linux y un manifiesto de imagen Docker — encontrará un hash SHA en todos ellos. Pero no el mismo SHA. SHA-1, SHA-256, SHA-384, SHA-512, SHA-3: la familia abarca tres décadas, dos linajes de diseño y un ataque de colisión decisivo que rompió al miembro más antiguo en producción.

Esta guía mapea toda la familia para que pueda elegir el algoritmo correcto para su caso de uso sin tener que dudar en el camino.

Árbol de decisión rápido

Antes de entrar en los detalles, aquí está el resumen en una tabla que la mayoría de los desarrolladores realmente necesita:

Su situación	Mejor elección	Razón
Certificado TLS/HTTPS	SHA-256 (mínimo), SHA-384 para alta seguridad	Obligatorio por los Requisitos de Referencia del CA/Browser Forum
Firma JWT (HMAC o RSA)	SHA-256 (HS256/RS256)	Soporte universal; SHA-384/512 para regímenes de cumplimiento
Suma de verificación de integridad de software	SHA-256	Valor predeterminado del sector; ampliamente comprendido
Integridad archivística o de larga duración	SHA-512	Salida mayor, margen de seguridad para las próximas décadas
Direccionamiento por contenido (IPFS, OCI)	SHA-256	Estándar de facto para almacenamiento dirigido por contenido
Git (leer/escribir repositorios existentes)	SHA-1 para los existentes; SHA-256 para los nuevos con `--object-format=sha256`	Git está en mitad de la migración; SHA-1 sigue dominando
Interoperar con Ethereum	Keccak-256 (no NIST SHA-3)	Ethereum usa la variante Keccak previa a la estandarización
Defensa en profundidad o sistemas clasificados	SHA-384 o SHA-512	NSA Suite B; se combina con AES-256-GCM
Código nuevo sin restricciones heredadas	SHA-3 (SHA3-256)	Linaje de diseño diferente; sin vulnerabilidad de extensión de longitud
Almacenamiento de contraseñas	Ninguno de los anteriores	Use bcrypt, Argon2id o scrypt — SHA es demasiado rápido

La familia SHA de un vistazo

Algoritmo	Estándar	Bits de salida	Chars hex	Año	Estado NIST	Uso principal hoy
SHA-1	FIPS 180-4	160	40	1995	Obsoleto (2011), retirado para firmas digitales	Legado de Git, huellas digitales
SHA-256	FIPS 180-4	256	64	2001	Vigente	TLS, JWT, Bitcoin, sumas de verificación
SHA-384	FIPS 180-4	384	96	2001	Vigente	Suite B, TLS de alta seguridad
SHA-512	FIPS 180-4	512	128	2001	Vigente	Archivos, LUKS, HMAC-SHA-512
SHA-3 (cualquier variante)	FIPS 202	224/256/384/512	varía	2015	Vigente	Linaje alternativo, aceleración por hardware

SHA-1 y SHA-2 (el grupo 256/384/512) comparten una construcción de Merkle-Damgård. SHA-3 usa una construcción de esponja — una distinción que importa más de lo que podría parecer, y que se trata más adelante.

SHA-1: Roto pero no muerto

SHA-1 fue el caballo de batalla de la década de 2000. Los certificados SSL, el correo S/MIME, las huellas digitales PGP y Git convergieron en él. Luego, en febrero de 2017, Google y CWI Amsterdam publicaron SHAttered: un ataque de colisión de prefijo elegido que produjo dos archivos PDF distintos con hashes SHA-1 idénticos. El ataque requirió aproximadamente 6,5 × 10^19 evaluaciones SHA-1 — costoso en 2017, asequible hoy con cómputo en la nube.

NIST ya había declarado obsoleto SHA-1 para firmas digitales en 2011 (Publicación Especial NIST 800-131A). La demostración de SHAttered aceleró la limpieza: los navegadores dejaron de confiar en los certificados TLS con SHA-1 hacia 2017, y el CA/Browser Forum hizo obligatorio SHA-256 para las nuevas emisiones.

Para qué se sigue usando SHA-1:

Base de datos de objetos de Git: Git fue diseñado con SHA-1 como hash de contenido rápido, no como primitivo de seguridad. El formato del repositorio hardcodea identificadores de objeto de 40 caracteres hex. Existe una ruta de migración a SHA-256 (git init --object-format=sha256), pero la adopción es lenta porque cada plataforma de alojamiento, cada herramienta de CI y cada clon existente necesitarían migrar de forma sincronizada.
Huellas de sistemas heredados: Las antiguas huellas de claves de host SSH, las huellas de claves PGP y los esquemas de número de serie de certificados siguen exponiendo valores SHA-1. Son informativos, no críticos para la seguridad en la mayoría de los contextos.

Qué hacer: No use SHA-1 para nada nuevo. Para Git, el riesgo de colisión es bajo en los flujos de trabajo típicos de desarrollo de software (un atacante necesitaría controlar ambos archivos en la colisión), pero los proyectos nuevos con --object-format=sha256 son la dirección correcta a largo plazo.

Genere un hash SHA-1 en su navegador: Generador SHA-1.

SHA-256: El caballo de batalla

SHA-256 es el algoritmo que mantiene en marcha internet en 2026. Todos los certificados TLS emitidos por una CA pública usan SHA-256 como hash de firma. Todos los JWT firmados con HS256, RS256 o ES256 usan SHA-256 internamente. La prueba de trabajo de Bitcoin es SHA-256 doble. El hash de contenido de Docker es SHA-256. La integridad de los paquetes de npm usa SHA-256.

Las razones son prácticas:

Margen de seguridad: 256 bits de salida suponen 2^128 operaciones para un ataque de preimagen por fuerza bruta — más allá de cualquier hardware concebible en el futuro previsible. El nivel de seguridad real es ligeramente inferior debido a los ataques de colisión por el límite del cumpleaños (2^128 operaciones), aun así inexpugnable.
Aceleración por hardware: SHA-256 está implementado en silicio en todos los procesadores Intel Goldmont+ (extensión SHA-NI), en todos los chips de Apple Silicon, en todos los procesadores ARMv8, y en ASICs dedicados en dispositivos de red y controladores de almacenamiento. Cuando se utiliza la ruta hardware, el rendimiento de SHA-256 supera al de muchas alternativas de software aparentemente más rápidas.
Soporte de bibliotecas ubicuo: Todas las bibliotecas TLS, todas las bibliotecas JWT y todas las bibliotecas estándar de cada lenguaje implementan SHA-256. No encontrará una barrera de compatibilidad.

Para el direccionamiento de contenido, la verificación de integridad y la mayoría de los flujos de firma, SHA-256 es el valor predeterminado correcto a menos que un estándar específico exija otra cosa.

Genere un hash SHA-256 en su navegador: Generador SHA-256.

SHA-384: La especialidad de TLS

SHA-384 es SHA-512 truncado a 384 bits. Se creó para proporcionar un nivel de seguridad de 192 bits (la mitad del tamaño de salida es el umbral de resistencia a colisiones) y se incluyó en la criptografía NSA Suite B junto con AES-256-GCM y claves de curva elíptica P-384.

Dos propiedades hacen de SHA-384 una opción especialmente atractiva para TLS:

Inmunidad a la extensión de longitud con este tamaño de salida: SHA-256 y SHA-512 son vulnerables a ataques de extensión de longitud — un atacante que conoce H(secreto || mensaje) puede calcular H(secreto || mensaje || extensión) sin conocer el secreto. SHA-384 y SHA-512/256 son truncados del estado interno completo, por lo que la extensión de longitud no aplica. Si usa hashes SHA crudos como MACs (en lugar de HMAC), SHA-384 es más seguro.
Cumplimiento de Suite B: Las organizaciones obligadas a cumplir los requisitos del conjunto NSA/CNSA (Algoritmo de Seguridad Nacional Comercial) deben usar SHA-384 o SHA-512 junto con RSA-3072+, ECDH P-384 y AES-256. Si su cliente es una agencia federal estadounidense o un contratista que opera bajo los requisitos FIPS 140-3, SHA-384 puede ser obligatorio.

SHA-384 no es significativamente más seguro que SHA-256 para la mayoría de los casos de uso — la brecha práctica entre una resistencia a colisiones de 128 bits y de 192 bits es teórica con los niveles de cómputo actuales. Elíjalo cuando el cumplimiento normativo o la combinación con Suite B lo requieran, no para uso genérico.

Genere un hash SHA-384 en su navegador: Generador SHA-384.

SHA-512: Cuando necesita más bits

SHA-512 produce un resumen de 512 bits (128 caracteres hex). En hardware de 64 bits suele ser más rápido que SHA-256 porque el algoritmo opera con palabras de 64 bits en lugar de 32 bits — la planificación interna de SHA-256 usa aritmética de 32 bits, mientras que la de SHA-512 usa aritmética de 64 bits que se mapea más eficientemente sobre las CPU modernas.

Benchmarks en hardware de 64 bits (orientativos; Web Crypto API del navegador):

Algoritmo	Rendimiento aproximado
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Nota: SHA-384 y SHA-512 comparten la misma función de compresión interna, por lo que se ejecutan a la misma velocidad. SHA-256 es más lento en 64 bits porque su tamaño de palabra de 32 bits exige más iteraciones para procesar cada bloque de mensaje de 512 bits. En hardware de 32 bits o restringido, SHA-256 es más rápido.

SHA-512 es adecuado para:

Integridad archivística: Las sumas de verificación pensadas para sobrevivir décadas se benefician del mayor margen de salida.
Cifrado de disco completo: Linux LUKS usa SHA-512 como el hash PBKDF de derivación de clave predeterminado (como componente de PBKDF2, no como hash independiente).
HMAC-SHA-512: Se usa en algunos esquemas de firma JWT (HS512) y en la autenticación de API donde se prefieren MACs más grandes.
Generación de grandes cantidades de datos pseudoaleatorios: Las aplicaciones que hacen hash de una semilla y necesitan muchos bits de salida pueden usar SHA-512 para reducir el número de llamadas al hash.

Genere un hash SHA-512 en su navegador: Generador SHA-512.

SHA-3: Una filosofía de diseño diferente

SHA-3 no es SHA-2 con una salida mayor. Es un algoritmo fundamentalmente diferente basado en una construcción de esponja llamada Keccak, diseñada por Guido Bertoni, Joan Daemen, Michaël Peeters y Gilles Van Assche. NIST lo seleccionó como ganador de una competencia pública de siete años (2007–2012) destinada a producir una familia de hash que pudiera servir como respaldo si se encontraban debilidades en la construcción de Merkle-Damgård de SHA-2.

La construcción de esponja funciona de forma diferente a Merkle-Damgård:

La entrada se rellena y se divide en bloques.
Cada bloque se aplica XOR a la primera parte de un gran estado interno (la «tasa»), y luego el estado completo se permuta con la permutación Keccak-f.
Después de absorber toda la entrada, la salida se «exprime» de la parte de tasa del estado.

Como la salida se extrae solo de una parte del estado, y la porción de capacidad nunca se expone directamente, las construcciones de esponja son inherentemente inmunes a los ataques de extensión de longitud sin necesidad de truncación.

Variantes estándar de SHA-3 (FIPS 202):

Variante	Bits de salida	Nivel de seguridad
SHA3-224	224	112 bits
SHA3-256	256	128 bits
SHA3-384	384	192 bits
SHA3-512	512	256 bits
SHAKE128	variable	128 bits
SHAKE256	variable	256 bits

SHA-3 vs SHA-2 en la práctica:

SHA-3 aún no está ampliamente desplegado en los protocolos diseñados antes de 2015 — TLS, JWT y la mayor parte de la infraestructura de internet siguen usando SHA-2. SHA-3 está apareciendo en esquemas de firma post-cuántica (CRYSTALS-Dilithium, SPHINCS+ usan SHA-3 internamente), en diseños de nuevos protocolos que quieren un respaldo de linaje diferente, y en hardware donde la permutación Keccak se acelera bien. En software puro, SHA-3 es aproximadamente un 40 % más lento que SHA-256 en x86.

Genere un hash SHA-3 en su navegador: Generador SHA-3.

La distinción de Keccak-256 en Ethereum

Un gotcha crítico: Ethereum no usa NIST SHA-3. Ethereum fue diseñado mientras la competencia Keccak estaba en curso y antes de que NIST finalizara FIPS 202. La Máquina Virtual de Ethereum usa la presentación original de Keccak-256, que emplea un relleno diferente al del estándar NIST SHA-3 definitivo.

En concreto:

NIST SHA3-256 añade relleno 0x06 antes del bloque final.
Keccak-256 original (tal como lo usa Ethereum) añade relleno 0x01.

La misma entrada produce hashes diferentes. Llamar a NIST SHA3-256 y llamar a keccak256 de Ethereum no son intercambiables. La mayoría de los lenguajes tienen ambos: en Python, hashlib.sha3_256() es NIST SHA-3; para Keccak-256 tal como lo usa Ethereum, necesita una biblioteca como pysha3 (que implementa keccak_256). En JavaScript, la biblioteca js-sha3 expone ambos. El Generador SHA-3 implementa NIST SHA3-256 — si necesita hashes Keccak-256 de Ethereum, use una herramienta específica de Ethereum.

Benchmarks de rendimiento

Los números siguientes son orientativos para la Web Crypto API del navegador en un portátil x86-64 moderno. El rendimiento real varía según el hardware, el tamaño del mensaje y si la plataforma utiliza una ruta de aceleración por hardware.

Algoritmo	Rendimiento en streaming (64 bits)
SHA-1	~600 MB/s
SHA-256	~500 MB/s
SHA-384	~700 MB/s
SHA-512	~700 MB/s
SHA-3-256	~300 MB/s

Para mensajes pequeños (tokens de API, sumas de verificación de pocos KB), todos los algoritmos completan en menos de 2 µs — la diferencia es invisible. Para datos grandes (tarballs, imágenes de disco), SHA-384/512 superan a SHA-256 en sistemas de 64 bits porque operan con palabras de 64 bits. SHA-3 es más lento en software puro; prefiera SHA-2 en código crítico de rendimiento a menos que disponga de aceleración hardware de Keccak. El rendimiento de SHA-1 nunca es razón para usarlo.

Errores comunes

Desajustes de codificación

SHA opera sobre bytes. Si hace hash de la cadena "hello" en un navegador donde JavaScript la codifica como UTF-16 en lugar de UTF-8, obtiene un resumen diferente al de un script Python que usa str.encode("utf-8"). Normalice siempre a UTF-8 antes de hacer hash de texto.

Un patrón consistente:

const encoder = new TextEncoder(); // UTF-8
const data = encoder.encode(inputString);
const hashBuffer = await crypto.subtle.digest("SHA-256", data);

Falta de salting para MACs

Usar un hash SHA crudo como código de autenticación de mensaje (H(secreto || mensaje)) es vulnerable a ataques de extensión de longitud sobre SHA-256 y SHA-512. Use HMAC (RFC 2104) en su lugar: HMAC-SHA256(clave, mensaje). HMAC envuelve el hash con un pad clave interior y exterior que impide los ataques de extensión.

Extensión de longitud sobre SHA-256

Si construye una firma de API como SHA256(secreto + payload), un atacante que conozca el hash resultante puede calcular SHA256(secreto + payload + extensión_atacante) sin conocer el secreto. Solución: use HMAC, o use SHA-3 (inmune por construcción), o use SHA-384/SHA-512/256 (inmune por truncación).

Confundir Keccak-256 con NIST SHA-3

Como se describe anteriormente: Ethereum usa Keccak-256 con relleno 0x01; NIST SHA3-256 usa relleno 0x06. Producen salidas diferentes con la misma entrada. Verifique qué variante implementa su biblioteca antes de integrarse con contratos Ethereum o codificación Solidity ABI.

Usar SHA para contraseñas

Los algoritmos SHA están diseñados para ser rápidos. Esa es exactamente la propiedad equivocada para el almacenamiento de contraseñas: un clúster de GPU puede calcular miles de millones de hashes SHA-256 por segundo, haciendo práctico un ataque de diccionario contra una base de datos de contraseñas con hash SHA. Para contraseñas, use una función de derivación de clave memory-hard: Argon2id (recomendado), bcrypt o scrypt. Nunca almacene contraseñas como hashes SHA crudos, ni siquiera con salt.

Preguntas frecuentes

¿Cuál es la diferencia entre SHA-1 y SHA-256?

SHA-1 y SHA-256 son ambas funciones hash de Merkle-Damgård estandarizadas en FIPS 180-4, pero SHA-256 produce un resumen de 256 bits frente a los 160 bits de SHA-1. Más importante aún, SHA-1 ha sido roto: un ataque de colisión en el mundo real (SHAttered, 2017) demostró dos archivos PDF distintos con el mismo hash SHA-1. SHA-256 no tiene ataques de colisión conocidos y proporciona un nivel de resistencia a colisiones de 128 bits. Use SHA-256 para cualquier cosa que requiera garantías de integridad; no use SHA-1 para trabajo nuevo.

¿Es SHA-512 más rápido que SHA-256?

En hardware de 64 bits, sí, a menudo entre un 30–40 % para entradas grandes. SHA-512 usa aritmética de palabras de 64 bits, que las CPU modernas procesan de forma nativa. SHA-256 usa aritmética de palabras de 32 bits, lo que requiere el doble de operaciones por bloque de mensaje en el mismo hardware. En plataformas de 32 bits o microcontroladores restringidos, SHA-256 es más rápido. Para mensajes cortos (de pocos KB), la diferencia es imperceptible.

¿Debo migrar de SHA-1 a SHA-256?

Para firmas digitales, certificados TLS y firma de código: sí, absolutamente — SHA-1 está obsoleto y activamente roto. Para repositorios Git: la ruta de migración existe (git init --object-format=sha256), pero la adopción es lenta debido a los requisitos de coordinación del ecosistema; el riesgo de colisión para el uso típico de repositorios es bajo. Para huellas digitales informativas (visualización de claves de host SSH): la exposición de seguridad es mínima, pero migrar a SHA-256 es buena higiene.

¿Se puede revertir SHA-256?

No. SHA-256 es una función de sentido único por diseño. Dado un hash, no es posible recuperar matemáticamente la entrada original. Lo que los atacantes pueden hacer es ejecutar un ataque de diccionario o fuerza bruta: hacer hash de millones de entradas candidatas y comparar. Para entradas de baja entropía (cadenas cortas, contraseñas comunes, números secuenciales), las tablas arcoíris precalculadas hacen esto práctico. Para entradas de alta entropía (UUIDs aleatorios, archivos grandes), la reversión no es computacionalmente factible. Por eso SHA solo es inapropiado para contraseñas — se necesita una KDF lenta y con salt.

¿Cuándo debería usar SHA-3 en lugar de SHA-2?

SHA-3 es apropiado cuando: (a) quiere un hash de un linaje de diseño diferente como seguro ante futuras debilidades de SHA-2; (b) su protocolo requiere inmunidad a la extensión de longitud sin usar HMAC; (c) está implementando esquemas de firma post-cuántica que especifican SHA-3 internamente; o (d) dispone de aceleración hardware para Keccak y necesita rendimiento. Para la mayoría de los casos de uso cotidianos (TLS, JWT, sumas de verificación), SHA-256 tiene un soporte de ecosistema más amplio y es el valor predeterminado pragmático. SHA-3 no es más seguro que SHA-2 con tamaños de salida equivalentes — es una apuesta diferente sobre la seguridad a largo plazo.

¿Por qué Ethereum usa Keccak-256 en lugar de NIST SHA-3?

Ethereum fue diseñado en 2013–2014, antes de que NIST publicara FIPS 202 (agosto de 2015) finalizando el estándar SHA-3. En ese momento, la presentación de Keccak era considerada la probable ganadora, y los autores de Ethereum la usaron directamente. Cuando NIST finalizó el estándar, cambiaron el relleno de separación de dominio de 0x01 (Keccak original) a 0x06, produciendo una salida diferente con la misma entrada. Ethereum ya estaba desplegado con el relleno original de Keccak y no podía cambiarlo. Por tanto, «Ethereum keccak256» y «NIST SHA3-256» son algoritmos diferentes a pesar de compartir la misma permutación Keccak-f subyacente.

Pruebe las herramientas: SHA-1 · SHA-256 · SHA-384 · SHA-512 · SHA-3 — todas funcionan en su navegador, ningún dato sale de su máquina.

SHA-1 vs SHA-256 vs SHA-512: guía hash 2026