Generador de hash gratuito

Qué es realmente una función hash criptográfica

Una función hash criptográfica toma una entrada de cualquier tamaño y produce una salida de tamaño fijo, llamada hash, resumen o huella. La misma entrada siempre produce el mismo hash; un cambio de un solo bit en la entrada produce un hash radicalmente distinto (el «efecto avalancha»); y la función es computacionalmente inviable de invertir, dado un hash, en la práctica no puedes encontrar la entrada que lo produjo. Tres propiedades de resistencia hacen «criptográfica» a una función hash: resistencia a la preimagen (dado un hash h, inviable encontrar una entrada m tal que hash(m) = h), resistencia a la segunda preimagen (dado m₁, inviable encontrar otra m₂ distinta con el mismo hash), y resistencia a colisiones (inviable encontrar dos entradas distintas con el mismo hash). Una función hash que pierde la resistencia a colisiones puede seguir siendo segura para algunos usos (integridad de archivo) pero no para otros (firmas digitales). MD5 y SHA-1 están justo en ese cubo: con colisiones rotas, pero con preimagen aún resistente.

Una breve historia de MD5, SHA-1, SHA-2 y SHA-3

MD2 / MD4 / MD5 son obra de Ron Rivest en el MIT y RSA Data Security. MD2 se publicó en 1989; MD4 en 1990; MD5 se publicó en 1991 y se estandarizó como RFC 1321 en abril de 1992. MD5 fue el hash dominante durante una década, predeterminado para checksums de descargas, almacenamiento de contraseñas, deduplicación de archivos y sistemas direccionables por contenido. La primera señal de alarma llegó en 1995 cuando Hans Dobbertin publicó un ataque de colisión a rondas completas sobre MD4, el predecesor de MD5; la primera colisión práctica de MD5 completo llegó en agosto de 2004, cuando Wang y Yu anunciaron dos mensajes de 128 bytes en colisión; Vlastimil Klima aceleró la búsqueda de colisiones de MD5 de horas a segundos en hardware comercial en 2006. Marc Stevens, junto con investigadores de TU Eindhoven y la EPFL, demostró una colisión MD5 con prefijo elegido en el 25C3 en diciembre de 2008 produciendo un certificado CA RapidSSL falsificado. Para cuando apareció el malware Flame en 2012, que usó una colisión MD5 para falsificar certificados de Microsoft Update, MD5 estaba completamente roto para cualquier uso sensible a la seguridad.

SHA («Secure Hash Algorithm») es una familia de la NSA estadounidense. SHA-0 se publicó como FIPS 180 en mayo de 1993 y se retiró en menos de un año por defectos de diseño no especificados. SHA-1 siguió como FIPS 180-1 en abril de 1995, con un cambio de un solo bit en el calendario de mensajes que la NSA nunca explicó públicamente. SHA-1 fue el hash predeterminado de finales de los noventa y los dosmiles, usado por Git para los hashes de commit, por los certificados SSL/TLS, por prácticamente cualquier esquema de firma. El primer ataque teórico por colisión llegó en 2005 (Wang, Yin, Yu); una colisión de inicio libre en 2015 (Stevens, Karpman, Peyrin); y la primera colisión SHA-1 completa se entregó el 23 de febrero de 2017 como «SHAttered» (Stevens, Bursztein, Karpman, Albertini, Markov), que produjo dos archivos PDF distintos con el mismo hash SHA-1. En enero de 2020, el ataque de prefijo elegido «SHA-1 is a Shambles» (Leurent y Peyrin, coste total de unos 45 000 USD de alquiler de GPU) hizo asequible la falsificación a nivel de certificado, acelerando la transición a SHA-256 que el proyecto Git ya había empezado a planear en 2018. SHA-1 está ahora formalmente desaprobado por el NIST para firmas digitales y certificados.

SHA-2 es la familia que reemplazó a SHA-1: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 y SHA-512/256, publicada como FIPS 180-2 en agosto de 2002. SHA-2 fue un diseño defensivo, salidas más grandes, más rondas, estado interno mayor, y veintitrés años después sigue sin romperse. SHA-256 es el predeterminado moderno para firmas digitales, certificados, JWT, hashes de bloque de Bitcoin, almacenamiento direccionable por contenido y la mayoría de la verificación de integridad de archivos. SHA-3 es un diseño fundamentalmente distinto, la construcción esponja Keccak por Bertoni, Daemen, Peeters y Van Assche, seleccionada en una competición del NIST de cinco años abierta en 2007 y ganada por Keccak en octubre de 2012; publicada como FIPS 202 en agosto de 2015. SHA-3 no es un reemplazo de SHA-2 (SHA-2 sigue siendo seguro); es una alternativa defensiva con una estructura interna completamente distinta, de modo que una rotura criptanalítica futura de SHA-2 no afectaría necesariamente a SHA-3. Esta herramienta produce SHA-1, SHA-256, SHA-384 y SHA-512 (el conjunto soportado por la Web Crypto API) más MD5 (vía una implementación en JavaScript, ya que la Web Crypto API omite MD5 deliberadamente).

Comparación de algoritmos

Algoritmo	Salida	Seguridad
MD5	128 bits (32 caracteres hex)	Roto · no apto para seguridad
SHA-1	160 bits (40 caracteres hex)	Débil · obsoleto
SHA-256	256 bits (64 caracteres hex)	Fuerte · recomendado
SHA-384	384 bits (96 caracteres hex)	Fuerte
SHA-512	512 bits (128 caracteres hex)	Fuerte

Dónde aparecen los hashes criptográficos

• Integridad de archivo / checksums. Los espejos de distribuciones Linux publican hashes SHA-256 (e históricamente MD5/SHA-1) junto a las descargas de ISO; el usuario calcula el hash del archivo descargado y lo compara con el valor publicado. Una discrepancia significa que la descarga estaba corrupta o manipulada. shasum, sha256sum y md5sum son las herramientas Unix estándar.
• Almacenamiento de contraseñas, pero NUNCA como hash plano. Almacenar SHA-256(contraseña) directamente es peligroso porque las rainbow tables (mapas precalculados (contraseña → hash)) hacen las contraseñas con hash plano reversibles en milisegundos. El patrón correcto es una función de hashing de contraseñas (KDF) con sal por usuario y un factor de coste ajustable: Argon2id (RFC 9106, 2021, recomendación moderna), scrypt (RFC 7914, Percival 2009) o bcrypt (Provos y Mazières, USENIX 1999). Las tres combinan una sal (para que contraseñas idénticas produzcan hashes almacenados distintos) con un cómputo deliberadamente costoso (para que los ataques de fuerza bruta queden frenados por el coste de hardware). Esta herramienta calcula hashes en bruto, útil para muchas cosas, pero no apropiado para almacenamiento de contraseñas por sí solo.
• Firmas digitales. Se firma el hash, no los datos, los datos son demasiado largos para firmar de forma eficiente. RSA, DSA, ECDSA y EdDSA todos firman un hash del mensaje. La función hash usada debe ser resistente a colisiones (de lo contrario un atacante puede sustituir un mensaje en colisión); por eso MD5 y SHA-1 están desaprobados para firmas.
• Almacenamiento direccionable por contenido de Git. Cada objeto de Git (blob, tree, commit, tag) se identifica por el SHA-1 de su contenido. La elección de diseño de Linus Torvalds en 2005 está hoy en plena transición plurianual a SHA-256, motivada por la rotura de colisiones de SHA-1. Git for Windows y Git oficial entregan ambos soporte SHA-256; la migración en producción es gradual.
• Bitcoin y Ethereum. Bitcoin usa doble-SHA-256 para hashes de bloque e identificadores de transacción (la función hash domina el coste del minado de Bitcoin, existen ASICs únicamente para calcular SHA-256 rápido). Ethereum usa Keccak-256 (el Keccak original antes de los ajustes de estandarización del NIST; a veces llamado «SHA-3 menos el cambio de padding»).
• Verificación de firma JWT. Los JSON Web Tokens se firman típicamente con HMAC-SHA-256 (nombre del algoritmo «HS256» en la especificación de JWT) o con RSA/ECDSA sobre un hash SHA-256. La firma permite al receptor verificar que el token vino del emisor y no ha sido alterado.
• Subresource Integrity (SRI). El atributo integrity="sha256-..." en las etiquetas <script> y <link> permite a los navegadores verificar que un script alojado en un CDN no ha sido modificado antes de ejecutarlo, una defensa contra CDN comprometidos.
• Firma de solicitudes de API. AWS Signature Version 4 usa HMAC-SHA-256 para firmar cada solicitud de API con la clave secreta de acceso del usuario. Esto autentica la solicitud sin enviar el secreto por la red y previene ataques de repetición vía marca de tiempo.

Rotura de colisiones vs rotura de preimagen, por qué MD5 sigue usándose

Una confusión común: si MD5 está «roto», ¿por qué md5sum sigue en cada distribución de Linux? La respuesta es la distinción entre resistencia a colisiones (rota en MD5) y resistencia a la preimagen (todavía intacta en MD5). Un ataque por colisión permite a un atacante construir dos entradas distintas con el mismo hash; eso importa para firmas digitales (donde un atacante puede fabricar una pareja en colisión, hacer firmar una y sustituir la otra) y para cualquier aplicación donde la función hash se supone que ata una entrada concreta. Un ataque por preimagen, en cambio, permitiría a un atacante recuperar la entrada original a partir de un hash, eso es lo que rompería de verdad un checksum de descarga, un hash de contraseña o un identificador direccionable por contenido. La resistencia a la preimagen de MD5 no se ha roto; los mejores ataques de preimagen publicados se mantienen cerca del límite teórico de 2¹²⁸, computacionalmente inviables en cualquier hardware existente o previsible. Así que MD5 (y SHA-1) siguen siendo legítimos para: verificación de integridad de archivo cuando confías en la fuente del hash publicado (un atacante que pueda sustituir el archivo presumiblemente también puede sustituir el hash, así que el modelo de amenaza es «corrupción accidental», no «manipulación deliberada»); claves de caché y deduplicación donde controlas ambos extremos; construcciones HMAC (HMAC-MD5 sigue siendo seguro porque la estructura de HMAC es robusta frente a la debilidad de colisión de MD5, aunque HMAC-SHA-256 se prefiere para código nuevo). Donde MD5 debe reemplazarse: firmas digitales, hashes de certificado, en cualquier lugar donde un atacante pueda fabricar la entrada.

La Web Crypto API y la omisión deliberada de MD5

Los navegadores modernos exponen el hashing a través de crypto.subtle.digest(algorithm, data), una función asíncrona que devuelve el hash como ArrayBuffer. Algoritmos soportados: SHA-1, SHA-256, SHA-384, SHA-512. Fíjate en lo que no está en esa lista: MD5 se omite deliberadamente. El W3C Web Crypto Working Group tomó la decisión explícita de dejar fuera MD5, razonando que cualquier uso de MD5 en un navegador era o bien legacy (mejor manejado con un polyfill) o erróneo (y no había que facilitarlo). El soporte de MD5 de esta herramienta viene de una pequeña implementación en JavaScript (~10 KB) empaquetada en la página; todo lo demás (SHA-1, SHA-256, SHA-384, SHA-512, más todas las variantes HMAC) pasa por Web Crypto para procesamiento a velocidad nativa. La Web Crypto API solo está disponible en contextos seguros (HTTPS o localhost), abrir esta herramienta sobre HTTP simple desactivaría silenciosamente el hashing SHA.

Formatos de salida: Hex, Base64, Base32

Los hashes son binarios por naturaleza, un hash de 256 bits son 32 bytes de datos opacos. Para mostrarlos o transportarlos, se codifican como texto. Hex (Base16) es la codificación más común: cada byte se vuelve dos caracteres hex, así que la salida SHA-256 son 64 caracteres hex. Universal, legible, duplica el tamaño. Base64 empaqueta bytes con más densidad (3 bytes → 4 caracteres); SHA-256 en Base64 son 44 caracteres (con padding) o 43 (sin). Usado en JWT (la firma se codifica en Base64URL), en atributos integrity SRI, y donde la compacidad importa. Base32 (RFC 4648) usa 32 caracteres que excluyen los visualmente ambiguos (sin distinción 0/O, 1/I/L); usado en claves secretas TOTP, ULID y direcciones onion. Esta herramienta produce hex por defecto, el formato universal que toda otra herramienta entiende.

HMAC, hashing con clave para autenticación

HMAC (Hash-based Message Authentication Code) es una construcción definida en RFC 2104 (Krawczyk, Bellare, Canetti, febrero de 1997) que convierte cualquier función hash criptográfica en un código de autenticación con clave. La construcción es HMAC(K, m) = H((K' XOR opad) || H((K' XOR ipad) || m)), donde K' es una clave derivada del secreto K, y opad/ipad son pads XOR fijos. La estructura es demostrablemente segura mientras lo sea el hash subyacente, y notablemente sigue siendo segura aun cuando el hash subyacente tenga resistencia a colisiones débil (por eso HMAC-MD5 sigue considerándose seguro, y por qué HMAC-SHA1 está bien en TLS incluso después de la rotura de colisiones de SHA-1). HMAC tiene tres usos principales: firma de solicitudes de API (AWS Signature v4, webhooks de GitHub, webhooks de Stripe), donde el receptor verifica que la solicitud vino del titular del secreto; integridad de JWT (HS256 = HMAC-SHA-256); y derivación de clave basada en contraseña (PBKDF2 usa HMAC internamente). El modo HMAC de esta herramienta toma una clave secreta y produce el HMAC de la entrada bajo esa clave.

Alcance honesto: para qué sirve y para qué no esta herramienta

Esta herramienta calcula hashes criptográficos en bruto de un texto o archivo de entrada. Útil para: verificar descargas de archivos contra checksums publicados, generar identificadores direccionables por contenido, calcular valores HMAC para depurar APIs, comparar la integridad de dos copias de un archivo y aprender a qué hashea una entrada concreta. No útil para: almacenamiento de contraseñas (usa una función real de hashing de contraseñas como Argon2id, scrypt o bcrypt con sal y factor de coste apropiados); revertir hashes (que es la razón misma de las funciones hash y no es posible por diseño); o generar hashes SHA-3 / Keccak (esta herramienta hoy emite SHA-1, SHA-256, SHA-384 y SHA-512 de la familia SHA-2, más MD5, SHA-3 está en la lista de futuras funciones); generar hashes BLAKE2 o BLAKE3. Para BLAKE3 (el hash moderno de alto rendimiento para almacenamiento direccionable por contenido), usa la CLI dedicada; para almacenamiento de contraseñas, usa la biblioteca bcrypt/scrypt/Argon2id de tu aplicación directamente.

Privacidad: por qué solo navegador importa aquí

Hashear un archivo en un servidor exige subirlo. Para verificación de descargas ordinarias esto es indiferente, ya confías en la fuente. Para hashear documentos internos, identificaciones escaneadas, capturas de UIs en desarrollo o cualquier archivo que no querrías ver copiado en el disco duro de un desconocido, el hashing del lado servidor es una fuga. Esta herramienta lee el archivo directamente en tu navegador usando la File API y lo hashea localmente, nada sale de tu dispositivo. Verifica abriendo la pestaña Network de las DevTools mientras pulsas Hashear, o pon la página en modo avión después de cargar y confirma que la herramienta sigue funcionando. La Web Crypto API exige HTTPS pero no exige acceso de red en tiempo de ejecución.

Preguntas frecuentes

¿Para qué se usa MD5 si está roto?

MD5 todavía se usa ampliamente para fines no relacionados con la seguridad: verificación de integridad de archivos (comprobación de descargas), deduplicación, claves de caché y sumas de comprobación. Nunca debe usarse para hashear contraseñas ni para firmas digitales.

¿Puedo revertir un hash para obtener el texto original?

No. Las funciones hash están diseñadas para ser unidireccionales. Sin embargo, los atacantes utilizan tablas precalculadas (tablas arcoíris) para buscar hashes comunes. Por eso las contraseñas deben hashearse con funciones hash lentas y con sal, como bcrypt, y no con SHA-256 puro.

¿Se sube mi archivo cuando lo hasheo?

No. El archivo se lee directamente en tu navegador usando la File API y se hashea localmente con la Web Crypto API (para SHA) o con una implementación en JavaScript puro (para MD5). No se envía nada a ningún servidor.

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

SHA-256 es parte de la familia SHA-2 (FIPS 180-2, agosto de 2002), construcción Merkle-Damgård, diseñada por la NSA. SHA-3 (FIPS 202, agosto de 2015) es la familia Keccak, construcción esponja, diseñada por Bertoni, Daemen, Peeters y Van Assche, seleccionada en una competición pública del NIST. SHA-3 no es un reemplazo de SHA-2 (SHA-2 sigue siendo seguro); es una alternativa defensiva con una estructura interna fundamentalmente distinta, de modo que una rotura hipotética futura de SHA-2 no afectaría necesariamente a SHA-3. Para nuevas aplicaciones en 2026, SHA-256 sigue siendo el predeterminado correcto; SHA-3 se usa cada vez más en Ethereum y esquemas post-cuánticos. Esta herramienta hoy soporta SHA-2 (SHA-1 / 256 / 384 / 512); SHA-3 está en la lista de futuras funciones.

¿Qué es HMAC y cuándo lo necesito?

HMAC (Hash-based Message Authentication Code, RFC 2104, 1997) es una construcción de hash con clave que prueba que un mensaje fue creado por alguien que conoce un secreto compartido. Lo necesitas siempre que estés verificando que una solicitud vino de la parte correcta, verificación de firmas de webhooks de GitHub (el secreto es la clave de firma del webhook), firmas de webhooks de Stripe, firmas de solicitudes de API de AWS (Signature v4 es HMAC-SHA-256) o firmas JWT (HS256 = HMAC-SHA-256). HMAC sigue siendo seguro aun cuando el hash subyacente tenga resistencia a colisiones débil, por eso HMAC-MD5 sigue considerándose seguro, aunque HMAC-SHA-256 es el predeterminado moderno para código nuevo.

¿Se sube mi archivo cuando lo hasheo?

No. El archivo se lee directamente en tu navegador usando la File API y se hashea localmente, vía la Web Crypto API para algoritmos de la familia SHA, vía una pequeña implementación en JavaScript para MD5. Nada cruza la red, verifica en la pestaña Network de las DevTools mientras computas, o pon la página en modo avión después de cargar. Seguro para hashear documentos internos, identificaciones escaneadas, capturas de UIs en desarrollo o cualquier archivo que no querrías ver copiado en el disco duro de un desconocido.

Herramientas relacionadas