Calculatrice de dérivation de clés HKDF | RFC 5869 décomposé en Extract et Expand
Outil qui sépare HKDF (fonction de dérivation de clés basée sur HMAC) en ses deux étapes pour les afficher côte à côte. Saisissez IKM, salt et info, choisissez SHA-256/384/512, et il montre le PRK (clé pseudo-aléatoire) de l'étape Extract à côté de l'OKM (matériau de clé de sortie) de l'étape Expand, en hexadécimal.
💡 À propos de cet outil
HKDF se définit en deux étapes internes : Extract -> Expand. L'étape Extract condense d'abord l'entropie dispersée de l'IKM en un PRK de longueur fixe ; l'étape Expand étire ensuite ce PRK, avec le champ info, jusqu'à la longueur en octets demandée. En pratique, presque toutes les bibliothèques n'exposent qu'un seul appel HKDF(ikm, salt, info, length) et masquent le PRK intermédiaire. Quand une valeur ne correspond pas à la spécification, impossible de savoir si le problème vient d'Extract ou d'Expand.
Cette calculatrice affiche PRK = HMAC(salt, IKM) séparément, et juste en dessous l'OKM qui en dérive. Si vous laissez le salt vide, elle suit le RFC 5869 en utilisant HashLen octets nuls comme salt. L'OKM est plafonné à 255xHashLen octets (8160 pour SHA-256) ; tant que le champ contient une valeur plus grande, un message de plage s'affiche, et en quittant le champ elle revient au maximum. Tout est calculé via l'API Web Crypto native du navigateur (crypto.subtle), si bien que les résultats correspondent à ceux de votre environnement d'exécution.
L'IKM, le salt et l'info que vous saisissez sont du matériau de clé brut : ils ne quittent pas le navigateur, vous pouvez donc coller des clés de test sans qu'elles soient envoyées où que ce soit.
🧐 Questions fréquentes
Q. Quelle est la différence entre PRK et OKM ? Le PRK (clé pseudo-aléatoire) est la sortie d'Extract : un HMAC de l'IKM avec le salt comme clé, de longueur fixe égale au hachage. L'OKM (matériau de clé de sortie) est la sortie d'Expand : la clé finale, de la longueur demandée, étirée à partir du PRK et de l'info. C'est l'OKM que votre application utilise.
Q. Que se passe-t-il si je laisse le salt vide ? Le RFC 5869 stipule qu'un salt absent équivaut à HashLen octets nuls. Cet outil fait de même : videz le champ salt et un salt de zéros sera utilisé automatiquement.
Q. Je saisis de l'hexadécimal ou du texte ?
Les deux. Avec le format d'entrée Texte (UTF-8), IKM, salt et info sont pris comme des octets UTF-8 : abc donne 3 octets (0x61 0x62 0x63). Avec Hex, chaque paire de chiffres est un octet : 0b0b donne les 2 octets 0x0b 0x0b. Les espaces, retours à la ligne et 0x sont ignorés, ce qui permet de coller tels quels les vecteurs de test de l'annexe A de la RFC 5869. La page s'ouvre en Hex avec les valeurs de l'annexe A.1 (SHA-256, L = 42).
Q. Quelle est la longueur maximale de l'OKM ? 255xHashLen octets : 8160 pour SHA-256, 12240 pour SHA-384, 16320 pour SHA-512. La limite vient du compteur sur un seul octet (1 à 255) de l'étape Expand.
Q. En quoi cela diffère-t-il de PBKDF2 ou Argon2 ? PBKDF2 et Argon2 sont des fonctions d'étirement qui ralentissent volontairement le hachage de mots de passe. HKDF répartit un secret déjà à forte entropie en plusieurs clés à usages distincts ; il n'a pas de facteur de travail lent. Les objectifs sont différents.
Q. Ma sortie ne correspond pas à un autre outil Les écarts proviennent du remplissage par des zéros du salt, de la présence ou non d'info, et du format d'entrée (Texte ou Hex). Vérifiez que les trois entrées sont identiques octet par octet.
📚 Le saviez-vous
HKDF a été normalisé en 2010 par Hugo Krawczyk et Pasi Eronen sous le nom de RFC 5869. Sa conception « Extract-then-Expand » repose sur une idée élégante : d'abord extraire l'entropie désordonnée vers un PRK uniforme, puis l'étendre en autant de clés que nécessaire. Cette séparation est ce qui permet de dériver des clés sûres à partir d'entrées biaisées, comme un secret partagé Diffie-Hellman. TLS 1.3 bâtit tout son calendrier de clés sur HKDF et s'appuie largement sur une variante étiquetée appelée HKDF-Expand-Label. Placer une chaîne de contexte dans le champ info pour scinder un même IKM en clés de « chiffrement » et d'« authentification » indépendantes est le modèle canonique, et la raison d'être du paramètre info.