Calculadora de derivación de claves HKDF | RFC 5869 dividido en Extract y Expand

Herramienta que separa HKDF (función de derivación de claves basada en HMAC) en sus dos etapas para mostrarlas juntas. Introduce IKM, salt e info, elige SHA-256/384/512 y verás el PRK (clave pseudoaleatoria) de la etapa Extract junto al OKM (material de clave de salida) de la etapa Expand, en hexadecimal.

💡 Sobre esta herramienta

HKDF se define en dos pasos internos: Extract -> Expand. Primero la etapa Extract concentra la entropía dispersa del IKM en un PRK de longitud fija; después la etapa Expand estira ese PRK, junto con el campo info, hasta la longitud en bytes que pidas. El problema práctico es que casi todas las bibliotecas exponen una sola llamada HKDF(ikm, salt, info, length) y ocultan el PRK intermedio. Cuando un valor no coincide con la especificación, no sabes si el fallo está en Extract o en Expand.

Esta calculadora muestra PRK = HMAC(salt, IKM) por separado y, debajo, el OKM derivado de él. Si dejas el salt vacío, sigue el RFC 5869 usando HashLen bytes en cero como salt. El OKM tiene un máximo de 255xHashLen bytes (8160 para SHA-256); pedir más devuelve un error. Todo se calcula con la API Web Crypto nativa del navegador (crypto.subtle), así que los resultados coinciden con los de tu entorno de ejecución.

El IKM, el salt y el info que escribes son material de clave en bruto: no salen del navegador, así que puedes pegar claves de prueba sin que se envíen a ningún sitio.

🧐 Preguntas Frecuentes

P. ¿Qué diferencia hay entre PRK y OKM? El PRK (clave pseudoaleatoria) es la salida de Extract: un HMAC del IKM con el salt como clave, de longitud fija igual al hash. El OKM (material de clave de salida) es la salida de Expand: la clave final, de la longitud que pidas, estirada a partir del PRK y del info. El OKM es lo que usa tu aplicación.

P. ¿Qué pasa si dejo el salt vacío? El RFC 5869 indica que un salt ausente equivale a HashLen bytes en cero. Esta herramienta hace lo mismo: vacía el campo salt y se usará un salt de ceros automáticamente.

P. ¿Introduzco hexadecimal o texto? IKM, salt e info se tratan como secuencias de bytes UTF-8. Si escribes abc, obtienes 3 bytes (0x61 0x62 0x63). Para bytes concretos, introduce el texto cuya codificación UTF-8 produzca esos bytes.

P. ¿Cuál es la longitud máxima del OKM? 255xHashLen bytes: 8160 para SHA-256, 12240 para SHA-384 y 16320 para SHA-512. El límite viene del contador de un solo byte (1 a 255) de la etapa Expand.

P. ¿En qué se diferencia de PBKDF2 o Argon2? PBKDF2 y Argon2 son funciones de estiramiento que ralentizan a propósito el hash de contraseñas. HKDF reparte un secreto ya de alta entropía en varias claves con propósitos distintos; no tiene factor de trabajo lento. Resuelven problemas diferentes.

P. Mi salida no coincide con otra herramienta Las diferencias surgen del relleno con ceros del salt, de si hay info presente y de la interpretación UTF-8 frente a bytes en bruto. Comprueba que las tres entradas sean idénticas byte a byte.

📚 Datos Curiosos

HKDF fue estandarizado en 2010 por Hugo Krawczyk y Pasi Eronen como RFC 5869. Su diseño "Extract-then-Expand" parte de una idea elegante: primero exprimir la entropía desordenada en un PRK uniforme, y luego expandirlo en tantas claves como hagan falta. Esa separación es lo que permite derivar claves seguras a partir de entradas sesgadas, como un secreto compartido de Diffie-Hellman. TLS 1.3 construye todo su calendario de claves sobre HKDF y usa una variante con etiqueta llamada HKDF-Expand-Label. Colocar una cadena de contexto en el campo info para dividir un mismo IKM en claves de "cifrado" y "autenticación" independientes es el patrón canónico, y la razón misma de que exista el parámetro info.