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) ; en demander davantage renvoie une erreur. 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 ?
IKM, salt et info sont traités comme des séquences d'octets UTF-8. Si vous tapez abc, vous obtenez 3 octets (0x61 0x62 0x63). Pour des octets précis, saisissez le texte dont l'encodage UTF-8 produit ces octets.
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 de l'interprétation UTF-8 contre octets bruts. 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.