Calculadora HMAC, PBKDF2 y HKDF

Calcule un código de autenticación de mensaje con clave mediante HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 o HMAC-SHA-512 (RFC 2104) sobre texto, bytes hex o archivos completos — con claves en texto, hex o Base64. O derive claves con PBKDF2 (RFC 8018) y HKDF (RFC 5869). Cada resultado puede mostrarse en hex, hex en mayúsculas, Base64 o Base64url. Para resúmenes simples vea el Generador de hash; para sumas de comprobación, la Calculadora CRC; para HMAC tal como se usa dentro de los JWT, el Decodificador JWT.
Se ejecuta por completo en local: las claves y los mensajes nunca salen de su pestaña. Archivos de hasta 200 MB.
Construcción: Salida:
Algoritmo HMAC: RFC 2104: la variante MD5 requiere md5.js (cargado por esta página).
Clave secreta (secreto compartido; cualquier longitud; el texto de abajo se codifica en UTF-8)
El hex admite espacios, dos puntos y prefijos 0x; el Base64 debe estar en forma estándar, con o sin relleno.
Una clave vacía es legal según el RFC 2104, pero casi siempre es un error: un HMAC sin clave es solo un hash lento.
Texto del mensaje (los datos que se autentican, codificados en UTF-8)
Salida HMAC (una línea: construcción, parámetros, valor)
La primera línea registra los parámetros exactos usados (algoritmo, lectura, tamaños de entrada), así que un resultado copiado y pegado siempre es reproducible.
¿Qué construcción necesita?
HMAC convierte un secreto compartido más un mensaje en un autenticador: el receptor que conoce la clave puede recalcularlo y detectar una manipulación. Es el «HS256» de todo JWT firmado (vea el Decodificador JWT) y la mitad de los esquemas de firma de peticiones de API del mundo. PBKDF2 sirve para estirar una contraseña humana hasta convertirla en clave: repite HMAC miles de veces para que cada intento de adivinar la contraseña cueste al atacante el mismo retardo. HKDF sirve para claves de protocolo: toma bytes secretos ya aleatorios (p. ej., un secreto compartido de Diffie-Hellman) y los expande de forma segura en varias claves ligadas a un propósito; TLS 1.3 deriva todas sus claves de tráfico de esta forma. Regla práctica: autenticar → HMAC; contraseña → PBKDF2 (o scrypt/Argon2, vea el Generador de hash de contraseñas cuando esté publicado); secreto uniforme → HKDF.
Autoprueba
Ejecuta los motores de la página contra vectores publicados: 10 anclas HMAC (estilo RFC 2202/4231: cinco algoritmos × dos entradas), 6 anclas PBKDF2 (SHA-1 y SHA-256 con tres recuentos de iteraciones) y los cuatro casos de prueba RFC 5869 de HKDF, A.1–A.4. No se envía nada a ningún sitio.
HMAC, PBKDF2 y HKDF: hash con clave explicado desde cero
En una frase: un hash simple como SHA-256 lo puede calcular cualquiera, así que no demuestra quién envió un mensaje; HMAC mezcla una clave secreta para que solo quien tiene la clave pueda producir (o verificar) el resumen; PBKDF2 y HKDF reutilizan esa misma maquinaria HMAC para convertir secretos en claves: despacio para contraseñas y rápido para material ya aleatorio.
Qué es HMAC (RFC 2104)

La construcción. HMAC son dos pasadas de hash, no una. Su clave se rellena hasta el tamaño de bloque del hash (64 bytes para MD5/SHA-1/SHA-256, 128 para SHA-384/512); el mensaje se resume una vez con la clave XOR un relleno interno fijo, y ese resumen se vuelve a resumir con la clave XOR un relleno externo fijo. Este doble sándwich es demostrablemente seguro mientras el hash subyacente sea una función pseudoaleatoria razonable — por eso HMAC-MD5 todavía resiste los ataques prácticos de colisión que rompieron el MD5 simple (aunque está retirado de todos modos, vea abajo).

Claves. Vale cualquier longitud de clave: la más corta que el tamaño de bloque se usa tal cual (aunque menos de 32 bytes se desaconseja), y la más larga se resume primero. La misma página le deja escribir la clave como texto, hex o Base64, de modo que una clave de producción de 64 caracteres hexadecimales pueda pegarse sin que nadie la confunda con una contraseña de texto de 64 caracteres; por esa razón la lectura queda registrada en la línea de salida.

Dónde aparece. El campo HS256 de la cabecera de un JWT es literalmente HMAC-SHA-256 sobre las partes del token codificadas en base64url (el Decodificador JWT de este sitio calcula exactamente eso cuando pega un secreto HS256). Las firmas de webhooks (Stripe, GitHub), AWS SigV4, la protección de registros TLS (en versiones antiguas) y el primo umac-64@openssh.com de OpenSSH pertenecen a la misma familia.

¿Por qué no basta con hash(mensaje || clave)? Extensión de longitud: todo hash de la familia MD5/SHA-1/SHA-2 permite que un atacante que conoce H(secreto || msg) calcule H(secreto || msg || relleno || cualquier cosa) sin el secreto. La división interna/externa de HMAC elimina esa clase de ataque. Es el error casero más habitual en el código de firmas de API, y la razón de que exista HMAC.

Qué es PBKDF2 (RFC 8018)

Lento por diseño. Una contraseña tiene quizá 40 bits de entropía real; la GPU de un atacante prueba miles de millones de SHA-256 crudos por segundo. PBKDF2 ejecuta HMAC(contraseña, sal) una y otra vez — iter veces — así que cada intento cuesta lo mismo, iter HMAC, a usted y al atacante. El valor predeterminado aquí es 600 000 iteraciones con HMAC-SHA-256, la referencia de la OWASP Password Storage Cheat Sheet; el deslizador llega hasta diez millones porque las recomendaciones de seguridad suben a medida que se acelera el hardware.

Sal. Una sal aleatoria por contraseña hace que los usuarios idénticos ya no produzcan hashes idénticos, y las tablas precalculadas (tablas arcoíris) dejan de servir. No es secreta — se guarda junto al hash — solo debe ser única. Lo habitual son 16 bytes aleatorios.

Debilidad conocida. PBKDF2 es intensivo en CPU pero no en memoria: las GPU y los ASIC lo paralelizan muy bien. Por eso el consejo moderno, al diseñar el almacenamiento de hashes de contraseña, es scrypt o Argon2id (el Generador de hash de contraseñas de esta familia los cubre), y PBKDF2 sigue siendo la respuesta correcta para compatibilidad y para configuraciones FIPS-140.

Qué es HKDF (RFC 5869)

Extraer y después expandir. HKDF hace dos trabajos. Extraer: comprimir material de clave de entrada posiblemente irregular (un secreto compartido de Diffie–Hellman, por ejemplo) junto con una sal en una clave pseudoaleatoria corta PRK = HMAC(sal, IKM). Expandir: estirar ese PRK hasta cualquier longitud de hasta 255 bloques de hash, encadenando cada bloque de salida con el anterior y etiquetándolo con el campo info. El resultado es que un solo secreto puede darle de forma segura una clave de cifrado, una clave MAC y un IV, todos separados.

No sirve para contraseñas. HKDF supone que su entrada ya tiene entropía completa — hace un HMAC por cada 32 bytes de salida, así que una contraseña humana lo atraviesa de forma casi instantánea, justo lo que quiere un atacante. Pasar contraseñas por HKDF en lugar de PBKDF2 es un error de diseño clásico; el campo info sirve para etiquetas de propósito ("client traffic key", "server iv"), no para añadir entropía.

Dónde aparece. TLS 1.3 deriva todas las claves que usa a partir del secreto del handshake mediante HKDF; WireGuard, Signal, EAP-TLS 1.3 y JSON Web Encryption (como KDF de acuerdo de clave directo) aparecen todos en el mismo árbol familiar.

Valores de referencia: reprodúzcalos en esta página

Las dos primeras tablas son los vectores de prueba en los que se basan el botón Ejemplo y la autoprueba de esta página (clave "key", mensaje «The quick brown fox jumps over the lazy dog»; después el caso de estilo RFC de una clave de 16 bytes 0x0b y el mensaje «Hi There»). Todos se generaron con una implementación nativa independiente y se volvieron a verificar en esta página.

HMAC de «fox», clave = keyResumen (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
Referencias de KDFParámetrosSalida (hex, primeros bytes)
PBKDF2-HMAC-SHA-1contraseña / sal, c=4096, 32 bytes4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256contraseña / sal, c=4096, 32 bytesc5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
HKDF-SHA-256 (RFC 5869 A.1)IKM=0x0b×22, sal=00..0c, info=f0..f9, L=423cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865
HKDF-SHA-256 (RFC 5869 A.2)IKM=00..4f, sal=60..af, info=b0..ff, L=82b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c…
HKDF-SHA-256 (RFC 5869 A.3)IKM=0x0b×22, sal e info vacías, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Errores habituales
  • Confundir HMAC con cifrado. HMAC demuestra integridad y origen (dado un secreto compartido); no oculta nada. Quien no tiene la clave sigue viendo el mensaje completo.
  • Confundir HMAC con una firma. Las firmas digitales son de clave pública: uno firma y cualquiera verifica. HMAC es simétrico: cualquier verificador también podría falsificar. Para no repudio necesita RSA/ECDSA (vea la herramienta RSA de esta familia cuando esté publicada), no HMAC.
  • Discrepancias en la lectura de la clave. Una cadena hexadecimal de 64 caracteres pegada en el cuadro de clave de texto se convierte en 64 bytes, no en 32 — y el HMAC cambia por completo. Esta página imprime la lectura en la línea de salida; cuando dos herramientas no coinciden, eso es lo primero que hay que comparar.
  • Iteraciones de PBKDF2 demasiado bajas. 1000 iteraciones era razonable en el año 2000; hoy las granjas de GPU las consumen en un suspiro. Si su sistema todavía almacena hashes de 1000 iteraciones, planifique una migración con rehash al iniciar sesión.
  • HKDF sobre una contraseña. Un HMAC por bloque de salida significa que una contraseña lo atraviesa al instante — use PBKDF2 (o Argon2id) para contraseñas y HKDF para secretos de alta entropía.
  • Reutilizar una misma clave derivada para todo. La solución no cuesta nada: derive claves separadas con etiquetas info distintas. Dos claves de un mismo IKM con etiquetas distintas son independientes por diseño.
Preguntas frecuentes

¿Está roto HMAC-MD5? Como hash resistente a colisiones, MD5 está muerto, pero la seguridad de HMAC-MD5 depende de MD5 como función pseudoaleatoria, y no se conoce ninguna rotura práctica. Está retirado de todos modos: no hay razón para elegirlo frente a HMAC-SHA-256 salvo por compatibilidad con un protocolo antiguo.

¿Cuánto debe medir mi clave HMAC? Al menos el tamaño de salida del hash (32 bytes para SHA-256) y generada por un CSPRNG. Se admite una clave más corta que el resumen, pero cada bit por debajo reduce directamente la seguridad.

¿Se vuelve PBKDF2 «más seguro» indefinidamente con más iteraciones? Sube el coste del atacante de forma lineal, pero también su coste al iniciar sesión, igualmente de forma lineal. El reto es elegir el mayor número que sus usuarios toleren — para eso calibran las cifras de la OWASP.

¿Por qué HKDF está limitado a 255 × tamaño del hash? El bucle de expansión es T(i) = HMAC(PRK, T(i-1) || info || i) con un contador de un byte i; 255 es el valor máximo del contador, un límite estructural fijo del RFC 5869, no una decisión de política.

¿Cuál es la diferencia entre el PBKDF2 de esta página y el Generador de hash de contraseñas? El mismo algoritmo, distinto trabajo. Esta página deriva bytes de clave en bruto para que los use en otro lugar; la página de hash de contraseñas produce cadenas de credenciales almacenadas (con sal y parámetros incrustados) y verifica contra ellas los candidatos pegados.