Resumen

  • La sal de HKDF suele ser pública. Puede reforzar la independencia de la extracción, pero no crea entropía, no autentica el material de entrada y no impone un coste deliberado a quien prueba contraseñas.
  • info cumple otra función durante Expand: incorpora protocolo, versión, rol o finalidad. Para auditar una derivación hay que conservar por separado la procedencia del IKM, la de la sal, el contexto codificado y la custodia de la salida.

La alerta que mira el campo equivocado

En un incidente, un analista encuentra la sal en una captura y concluye que las claves deben rotarse. Otro responde que no hay problema porque los dos extremos obtuvieron el mismo resultado. Ambas posiciones confunden una observación válida con una conclusión que no se desprende de ella.

RFC 5869 define la sal de HKDF como un valor aleatorio opcional y no secreto. Si no se proporciona, la función usa una cadena de ceros del tamaño de la salida del hash. Ver la sal no equivale a conocer el secreto. Pero coincidir en el resultado tampoco demuestra que el IKM fuese impredecible, que la sal respetase el modelo de independencia o que la salida perteneciera a la operación prevista.

Hugo Krawczyk y Pasi Eronen firmaron juntos ese RFC. El artículo académico de Krawczyk desarrolló la justificación formal del esquema, y su historial en el IETF incluye también HMAC, la primitiva sobre la que se construye HKDF. El libro de premios de ACM de 2025 reconoció su contribución a los fundamentos y protocolos prácticos de las comunicaciones seguras. La relevancia editorial no está en convertir una especificación colectiva en biografía heroica, sino en seguir una idea que hoy atraviesa varias capas de Internet: un secreto intermedio todavía no es una clave con finalidad.

Extract ordena la incertidumbre que ya existe

La primera operación de HKDF es:

PRK = HMAC-Hash(salt, IKM)

El material de clave inicial puede tener estructura, una distribución no uniforme o rasgos parcialmente conocidos por un adversario. Extract concentra la entropía disponible en una clave seudoaleatoria de longitud fija. No aumenta la lista real de posibilidades. Si el IKM es una contraseña humana con pocos candidatos plausibles, cada candidato sigue pudiendo probarse mediante el mismo cálculo rápido.

Por eso omitir Extract no es una decisión universal de rendimiento. Cuando el IKM ya es una clave seudoaleatoria robusta, algunas aplicaciones pueden pasar directamente a Expand. Un valor compartido de Diffie–Hellman no debe tratarse así; RFC 5869 aconseja extraerlo porque su representación no es por sí sola una clave HMAC uniforme.

NIST SP 800-56C Rev. 2 organiza los procedimientos de derivación para establecimiento de claves en extracción, expansión y extracción seguida de expansión. El límite se ha convertido en vocabulario operativo de estándares: permite saber qué supuesto sobre la fuente se ha satisfecho antes de generar salidas para algoritmos concretos.

No secreto tampoco significa manipulable

Una sal adecuada puede separar usos de la función hash, favorecer una extracción independiente de la fuente y reforzar el análisis de seguridad. Puede transmitirse en claro, derivarse de nonces públicos autenticados o, donde el modelo lo admita, permanecer fija. Incluso una sal de calidad limitada puede aportar valor.

La propiedad crucial no es esconderla, sino mantenerla independiente del IKM. Cuando la sal procede de valores aportados por participantes, el protocolo debe impedir que un adversario los seleccione sin autenticación. De ahí que un inventario operativo necesite más de una casilla «usa sal». Debe diferenciar la ausencia con valor predeterminado, una constante versionada del protocolo, una sal pública fresca y autenticada, y una entrada bajo influencia externa.

RFC 8188 ofrece una aplicación muy clara. En el cifrado de contenido HTTP, una sal transportada entra en HKDF-Extract; una cadena fija que identifica el tipo de codificación entra como info en la expansión. Ambas pueden ser públicas. Lo que las distingue es la afirmación criptográfica que cada una ayuda a construir.

El parecido con las contraseñas engaña

En sistemas de contraseñas, una sal única reduce la utilidad de tablas precalculadas y evita que dos contraseñas iguales produzcan el mismo registro. Pero la baja entropía de la elección humana permanece. Para resistir ataques sin conexión también se necesita que cada intento consuma tiempo o memoria de forma deliberada.

HKDF no incorpora factor de trabajo ni una fase resistente por memoria. RFC 5869 advierte que Extract concentra entropía existente y no puede amplificarla; tampoco contiene el mecanismo de ralentización de una KDF para contraseñas. PBKDF2 incluye un contador de iteraciones. Argon2 permite controlar memoria, pasadas y paralelismo. Esos mecanismos no redimen una contraseña débil, pero elevan el coste de ensayar diccionarios completos.

«Está salada» no es entonces una respuesta técnica. El revisor debe preguntar qué construcción usó la sal, qué tipo de material recibió, cuánto cuesta una prueba, si la sal debía ser única o independiente y quién hizo cumplir esa propiedad. Compartir el nombre de un parámetro no hace equivalentes dos modelos de amenaza.

La finalidad entra por info

HKDF-Expand recibe la PRK, info y una longitud. info puede incluir número de protocolo, identificadores de algoritmos, identidad, rol o tamaño. Su cometido es vincular la salida a una aplicación y evitar que el mismo IKM produzca material indistinguible en contextos distintos.

La sal no puede ocupar ese lugar por conveniencia. RFC 5869 desaconseja devolver la PRK directamente incluso cuando cabe en la longitud solicitada, porque se omite el paso que incorpora info. También desaconseja introducir el contexto en Extract como sustituto. La PRK es capacidad de derivación; no es todavía una autorización para cifrar, autenticar o construir nonces.

TLS 1.3 vuelve explícito el contrato. HKDF-Expand-Label antepone tls13 al nombre e incorpora un contexto que puede contener el hash de la transcripción. Etiquetas como finished, key e iv forman parte de los bytes procesados.

QUIC deriva de un secreto de tráfico una clave AEAD, un IV y una clave de protección de cabecera mediante quic key, quic iv y quic hp. RFC 9001 indica que esos nombres también separan el dominio de QUIC del de TLS. Registrar únicamente «HKDF correcto» destruye la pista que dice para qué existía cada valor.

HPKE incluye en LabeledExtract y LabeledExpand HPKE-v1, el identificador de la suite y una etiqueta de uso. Así ata los secretos al esquema, su versión y los algoritmos elegidos. MLS utiliza su propio prefijo MLS 1.0 y una agenda que produce secretos distintos por época y función. Una etiqueta legible no crea esa separación sola: cada participante debe codificarla sin ambigüedad y validar las reglas de versión y suite.

Cuatro comprobantes, no un hash de la salida

El primero es la procedencia del IKM. Hay que distinguir un acuerdo Diffie–Hellman autenticado, una clave aleatoria, un secreto precompartido, una contraseña y la salida de otra KDF. Igual longitud no implica igual entropía ni igual control del adversario.

El segundo es la procedencia de la sal: regla de generación, versión, autenticación, reutilización y justificación de independencia respecto del IKM. «Público» describe confidencialidad, no origen.

El tercero es el contexto ya codificado. Debe preservarse una huella no secreta de prefijo, versión, suite, etiqueta, rol, transcripción y longitud tal como llegaron a Expand. El texto amigable de una interfaz no detecta concatenaciones ambiguas ni diferencias de codificación.

El cuarto es la custodia de la salida. Hay que nombrar si se trata de clave, IV, exportador, secreto de reanudación o PRK, quién puede usarla, en qué época vive y cuándo debe borrarse. Una derivación impecable no corrige una reutilización de nonce ni la retención de una clave antigua.

Con los cuatro comprobantes, la coincidencia de resultados ocupa su lugar correcto: evidencia de una computación compartida, no prueba automática de autenticación, calidad de la fuente, finalidad ni borrado.

Fuentes