Résumé

  • Le sel de HKDF est normalement non secret. Il peut renforcer l’indépendance de l’extraction, sans ajouter d’entropie au matériau initial, authentifier ce matériau ni ralentir une attaque par dictionnaire.
  • Le paramètre info, employé lors de l’expansion, lie les clés dérivées à un protocole, une version, un rôle ou un contexte. Un audit doit donc conserver séparément la provenance de l’IKM, celle du sel, l’encodage du contexte et la fonction de chaque sortie.

Le paradoxe n’en est pas un

Une équipe reçoit un ticket de sécurité : le sel utilisé pour dériver les clés apparaît dans une capture réseau. La réaction paraît évidente — il faut changer les clés puisque leur sel a « fuité ». Pourtant, dans HKDF, la visibilité du sel est prévue. RFC 5869 le définit comme une valeur aléatoire optionnelle et non secrète. S’il manque, la fonction emploie une chaîne de zéros de la longueur de la sortie de hachage.

Cette visibilité ne rend pas le sel inutile. Elle montre seulement que sa contribution ne repose pas sur la confidentialité. Un sel convenable améliore les conditions d’extraction, sépare différents emplois de la fonction de hachage et soutient une extraction moins dépendante de la source. Le secret demeure dans le matériau de clé initial, ou IKM, et dans les secrets qui en découlent.

L’inverse est tout aussi important. Deux machines qui obtiennent la même sortie ont prouvé qu’elles ont exécuté un calcul compatible sur des entrées compatibles. Elles n’ont pas prouvé que l’IKM était imprévisible, que le sel avait une provenance acceptable, que les pairs étaient authentifiés ni que la clé avait reçu le bon usage.

Cette frontière explique l’importance de Hugo Krawczyk dans l’histoire. Il a cosigné RFC 5869 avec Pasi Eronen ; son article de 2010 expose le modèle et la justification de la construction. Son dossier IETF comprend aussi RFC 2104 sur HMAC, le composant utilisé par HKDF. Le livret des prix ACM 2025 a distingué son apport aux fondements et aux protocoles pratiques des communications sûres. Il ne s’agit pas d’attribuer seul à un homme tout un écosystème, mais d’observer la diffusion d’une idée précise : une clé intermédiaire n’a pas encore de métier.

Extraire n’est pas inventer de l’entropie

HKDF commence par l’opération suivante :

PRK = HMAC-Hash(salt, IKM)

L’objectif est de produire une clé pseudo-aléatoire de longueur fixe à partir d’un IKM dont la distribution peut être irrégulière. L’extraction concentre l’incertitude déjà présente. Elle ne transforme pas un espace de mille mots de passe en un espace de secrets à 256 bits. Si l’attaquant peut énumérer les candidats à l’IKM, il peut exécuter le même HMAC sur chacun d’eux.

La possibilité de sauter Extract dépend donc de la nature de l’entrée. Un IKM qui est déjà une excellente clé pseudo-aléatoire peut, dans certains cas, aller directement à Expand. Une valeur Diffie–Hellman n’est pas à traiter de cette manière : RFC 5869 recommande de ne pas omettre l’extraction, car la représentation du secret partagé n’est pas elle-même une clé HMAC uniforme.

NIST SP 800-56C Rev. 2 reprend les catégories extraction, expansion et extraction-puis-expansion pour les schémas d’établissement de clés. La séparation n’est donc pas le nom interne d’une bibliothèque. Elle permet à un dossier d’architecture d’indiquer quel problème a été résolu avant de donner une fonction à une sortie.

Public ne signifie pas choisi par l’adversaire

Un sel peut provenir de nonces publics authentifiés, être aléatoire et transmis en clair, voire être réutilisé lorsque le modèle l’autorise. Même une valeur imparfaite peut apporter quelque chose. Mais RFC 5869 pose une condition moins visible : le sel doit être indépendant de l’IKM. Dans un protocole où des nonces le déterminent, il faut empêcher un adversaire de les choisir à sa convenance.

Cette nuance disparaît dans un champ de journalisation réduit à salt=true. Un opérateur devrait distinguer au moins le sel absent et remplacé par la valeur par défaut, le sel fixe d’une version de protocole, le sel public frais et authentifié, et le sel influençable par une partie non authentifiée. Tous peuvent être connus du public ; leurs garanties diffèrent.

RFC 8188 fournit un cas concret. Pour le codage chiffré du contenu HTTP, une valeur de sel transportée alimente HKDF-Extract, tandis qu’une chaîne fixe désignant le codage devient l’info de l’expansion. Les deux données peuvent être visibles en même temps parce qu’elles ne servent pas au même raisonnement.

Le faux raccourci du mot de passe « salé »

En cryptographie fondée sur un mot de passe, le sel empêche surtout de rentabiliser une table précalculée sur de nombreux comptes et différencie deux occurrences du même mot de passe. Il ne supprime pas le faible nombre de choix plausibles faits par les humains. Une défense contre la recherche hors ligne doit aussi rendre chaque essai volontairement coûteux.

HKDF ne contient ni facteur de travail configurable ni étape gourmande en mémoire. RFC 5869 précise qu’Extract peut concentrer l’entropie existante, pas l’amplifier, et qu’aucun ralentissement destiné aux mots de passe n’est inclus. PBKDF2 expose un nombre d’itérations. Argon2 intègre notamment un coût mémoire, un nombre de passages et un degré de parallélisme. Ces fonctions ne rendent pas bon un mauvais mot de passe, mais elles changent le prix industriel d’une campagne d’essais.

Dire « c’est salé » masque ainsi cinq questions : quelle fonction a consommé le sel, quelle est la classe de l’entrée, combien coûte un essai, le sel devait-il être unique ou indépendant, et cette propriété a-t-elle été vérifiée ? Le même nom de paramètre ne crée pas le même contrôle.

info donne une fonction à la clé

Après Extract, HKDF-Expand reçoit la PRK, une valeur info et la longueur demandée. info peut encoder un numéro de protocole, un algorithme, une identité, un rôle ou la longueur elle-même. Sa mission est de lier la sortie à une application et à un contexte, notamment lorsque le même IKM intervient dans plusieurs domaines.

Le sel ne remplace pas cette liaison. RFC 5869 déconseille même d’utiliser directement la PRK comme sortie finale lorsque cela évite info, et déconseille de glisser le contexte dans Extract à sa place. Une PRK est un secret intermédiaire générique. Elle n’est pas encore une clé d’émission, un IV ou un secret d’exportation.

TLS 1.3 matérialise ce principe avec HKDF-Expand-Label. L’encodage ajoute le préfixe tls13 , un label et un contexte qui peut inclure le hachage de la transcription. Des mots comme finished, key et iv entrent réellement dans le calcul ; ils ne sont pas des commentaires dans le code.

QUIC dérive à partir d’un même secret de trafic une clé AEAD, un IV et une clé de protection d’en-tête avec quic key, quic iv et quic hp. RFC 9001 indique que ces labels séparent également les clés QUIC des clés TLS. Un tableau de bord qui ne conserve que « HKDF-SHA256 : succès » efface la pièce qui explique l’usage de chaque sortie.

HPKE ajoute dans LabeledExtract et LabeledExpand la chaîne HPKE-v1, l’identifiant de la suite cryptographique et un label fonctionnel. Cette construction lie les secrets au schéma, à sa version et aux algorithmes choisis. MLS emploie son propre préfixe MLS 1.0 dans une arborescence de secrets par époque. La répétition de ce motif ne signifie pas qu’une chaîne lisible protège à elle seule. La séparation existe seulement si chaque implémentation produit le même encodage non ambigu et si les versions et suites sont effectivement contrôlées.

Les quatre pièces d’un dossier de dérivation

Première pièce : la provenance de l’IKM. Un secret Diffie–Hellman authentifié, une clé aléatoire, un secret prépartagé, un mot de passe et la sortie d’une autre KDF peuvent avoir la même taille sans avoir les mêmes hypothèses d’entropie ou de contrôle adverse.

Deuxième pièce : la provenance du sel. Il faut connaître la règle de génération, la version, l’état d’authentification, la politique de réemploi et la raison pour laquelle il est indépendant de l’IKM. « Non secret » décrit la confidentialité, pas l’intégrité de la source.

Troisième pièce : le contexte encodé. L’audit doit retenir le préfixe de protocole, le label, la suite, le rôle, le hachage de transcription et l’encodage de longueur qui ont atteint Expand. Un intitulé convivial dans une interface ne révèle ni une concaténation ambiguë ni une différence d’encodage.

Quatrième pièce : la garde de la sortie. L’équipe doit savoir si elle détient une clé, un IV, une PRK, un secret de reprise ou d’exportation, quelles opérations sont autorisées, dans quelle époque la valeur vit et quand elle doit être effacée.

Ces quatre pièces donnent à un résultat identique sa juste portée. Elles permettent de comprendre un écart, mais aussi de détecter un cas plus insidieux : deux côtés peuvent exécuter exactement la même erreur.

Sources