Calculateur HMAC, PBKDF2 et HKDF

Calculez un code d’authentification de message à clé avec HMAC-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384 ou HMAC-SHA-512 (RFC 2104) sur du texte, des octets hexadécimaux ou des fichiers entiers — clés saisies en texte, en hexadécimal ou en Base64. Ou dérivez des clés avec PBKDF2 (RFC 8018) et HKDF (RFC 5869). Chaque résultat peut être affiché en hexadécimal, en hexadécimal majuscule, en Base64 ou en Base64url. Pour des empreintes simples, voir le Générateur de hachage ; pour des sommes de contrôle, voir le Calculateur CRC ; pour le HMAC utilisé dans les JWT, voir le Décodeur JWT.
Tout s’exécute localement — les clés et les messages ne quittent jamais votre onglet. Fichiers jusqu’à 200 Mo.
Construction : Sortie :
Algorithme HMAC : RFC 2104 — la variante MD5 nécessite md5.js (chargé par cette page).
Clé secrète (secret partagé ; longueur quelconque, le texte ci-dessous est encodé en UTF-8)
La lecture hexadécimale tolère les espaces, les deux-points et les préfixes 0x ; le Base64 doit être au format standard, avec ou sans remplissage.
Une clé vide est légale selon la RFC 2104 mais constitue presque toujours une erreur — un HMAC sans clé n’est qu’un hachage lent.
Texte du message (les données à authentifier, encodées en UTF-8)
Sortie HMAC (une ligne : construction, paramètres, valeur)
La première ligne consigne les paramètres exacts utilisés (algorithme, lecture, tailles d’entrée), si bien qu’un résultat copié-collé est toujours reproductible.
Quelle construction vous faut-il ?
HMAC transforme un secret partagé et un message en authentificateur : le destinataire qui connaît la clé peut le recalculer et détecter une altération. C’est le « HS256 » de chaque JWT signé (voir le Décodeur JWT) et la moitié des schémas de signature de requêtes d’API dans le monde. PBKDF2 sert à étirer un mot de passe humain en clé : il répète HMAC des milliers de fois afin que chaque essai de mot de passe coûte le même délai à l’attaquant. HKDF sert aux clés de protocole : il prend des octets secrets déjà aléatoires (par ex. un secret partagé DH) et les étend en sécurité en plusieurs clés liées à leur finalité — TLS 1.3 dérive toutes ses clés de trafic ainsi. Règle empirique : authentifier → HMAC ; mot de passe → PBKDF2 (ou scrypt/Argon2, voir le Générateur de hachage de mots de passe une fois publié) ; secret uniforme → HKDF.
Autotest
Exécute les moteurs de la page contre des vecteurs publiés : 10 ancres HMAC (style RFC 2202/4231, cinq algorithmes × deux entrées), 6 ancres PBKDF2 (SHA-1 et SHA-256 à trois nombres d’itérations) et les quatre cas de test HKDF de la RFC 5869 A.1–A.4. Rien n’est envoyé nulle part.
HMAC, PBKDF2 et HKDF — le hachage à clé expliqué depuis zéro
En une phrase : un hachage nu comme SHA-256 peut être calculé par n’importe qui, il ne prouve donc rien sur l’expéditeur d’un message — HMAC mélange une clé secrète pour que seuls les détenteurs de la clé puissent produire (ou vérifier) l’empreinte ; PBKDF2 et HKDF réutilisent ensuite cette même mécanique HMAC pour transformer des secrets en clés, lentement pour les mots de passe et rapidement pour du matériau déjà aléatoire.
Ce qu’est HMAC (RFC 2104)

La construction. HMAC consiste en deux passes de hachage, pas une seule. Votre clé est complétée jusqu’à la taille de bloc du hachage (64 octets pour MD5/SHA-1/SHA-256, 128 pour SHA-384/512) ; le message est haché une fois avec la clé XOR un bourrage interne fixe, et cette empreinte est hachée à nouveau avec la clé XOR un bourrage externe fixe. Cette double enveloppe est prouvablement sûre tant que le hachage sous-jacent est une bonne fonction pseudo-aléatoire — c’est pourquoi HMAC-MD5 résiste encore aux attaques de collision pratiques qui ont brisé MD5 nu (bien qu’il soit de toute façon retiré, voir plus bas).

Clés. Toute longueur de clé convient : une clé plus courte que la taille de bloc est utilisée telle quelle (mais moins de 32 octets est mal vu), une clé plus longue est d’abord hachée. Cette même page vous laisse saisir la clé en texte, en hexadécimal ou en Base64, afin qu’une clé de production de 64 caractères hexadécimaux puisse être collée sans qu’on la confonde avec un mot de passe texte de 64 caractères — la lecture est consignée dans la ligne de sortie pour cette raison précise.

Où vous le rencontrez. Le champ HS256 de l’en-tête d’un JWT est littéralement HMAC-SHA-256 sur les parties du jeton encodées en base64url (le Décodeur JWT de ce site calcule exactement cela lorsque vous collez un secret HS256). Les signatures de webhooks (Stripe, GitHub), AWS SigV4, la protection des enregistrements TLS (anciennes versions) et le cousin umac-64@openssh.com d’OpenSSH appartiennent tous à la même famille.

Pourquoi ne pas simplement hacher message || clé ? L’extension de longueur : toute fonction de la famille MD5/SHA-1/SHA-2 permet à un attaquant qui connaît H(secret || msg) de calculer H(secret || msg || bourrage || quoi que ce soit) sans le secret. La séparation interne/externe de HMAC élimine cette classe d’attaques. C’est l’erreur « fais-le toi-même » la plus fréquente dans le code de signature d’API — et la raison d’être de HMAC.

Ce qu’est PBKDF2 (RFC 8018)

Lent par conception. Un mot de passe possède peut-être 40 bits d’entropie réelle ; le GPU d’un attaquant essaie des milliards de SHA-256 nus par seconde. PBKDF2 exécute HMAC(mot de passe, sel) encore et encore — iter fois — si bien que chaque essai coûte les mêmes iter HMAC pour vous et pour l’attaquant. La valeur par défaut ici est 600 000 itérations avec HMAC-SHA-256, la référence de l’OWASP Password Storage Cheat Sheet ; le curseur va jusqu’à dix millions, car les recommandations de sécurité montent à mesure que le matériel s’accélère.

Sel. Un sel aléatoire par mot de passe signifie que des utilisateurs identiques ne produisent plus le même hachage, et les tables précalculées (tables arc-en-ciel) deviennent inutiles. Il n’est pas secret — il est stocké à côté du hachage — il doit seulement être unique. 16 octets aléatoires sont la norme.

Faiblesse connue. PBKDF2 est difficile pour le processeur mais pas pour la mémoire : les GPU et ASIC le parallélisent très bien. C’est pourquoi le conseil moderne est scrypt ou Argon2id lorsqu’on conçoit un stockage de hachage de mot de passe (la page Générateur de hachage de mots de passe de cette famille les couvre), et PBKDF2 reste la bonne réponse pour la compatibilité et les réglages FIPS-140.

Ce qu’est HKDF (RFC 5869)

Extraire, puis étendre. HKDF fait deux choses. Extraire : condenser un matériau de clé d’entrée potentiellement inégal (un secret partagé Diffie–Hellman, par exemple) avec un sel en une clé pseudo-aléatoire courte PRK = HMAC(sel, IKM). Étendre : étirer ce PRK jusqu’à une longueur quelconque, jusqu’à 255 blocs de hachage, chaque bloc de sortie étant chaîné au précédent et marqué par le champ info. Résultat : un même secret peut donner en toute sécurité une clé de chiffrement, une clé MAC et un IV, tous séparés.

Pas pour les mots de passe. HKDF suppose que son entrée a déjà une entropie complète — il effectue un HMAC par 32 octets de sortie, donc un mot de passe humain le traverse quasiment instantanément, exactement ce que veut un attaquant. Faire passer des mots de passe dans HKDF au lieu de PBKDF2 est une erreur de conception classique ; le champ info sert à des étiquettes de finalité ("client traffic key", "server iv"), non à ajouter de l’entropie.

Où vous le rencontrez. TLS 1.3 dérive chaque clé utilisée à partir du secret de handshake via HKDF ; WireGuard, Signal, EAP-TLS 1.3 et JSON Web Encryption (comme KDF directe d’accord de clé) figurent tous dans le même arbre généalogique.

Valeurs d’ancrage — reproduisez-les sur cette page

Les deux premiers tableaux sont les vecteurs de test sur lesquels reposent le bouton Exemple et l’autotest de cette page (clé "key", message « The quick brown fox jumps over the lazy dog » ; puis le cas de type RFC d’une clé de 16 octets 0x0b et du message « Hi There »). Tous ont été générés par une implémentation native indépendante et revérifiés sur cette page.

HMAC de « fox », clé = keyEmpreinte (hex)
HMAC-MD580070713463e7749b90c2dc24911e275
HMAC-SHA-1de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9
HMAC-SHA-256f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA-384d7f4727e2c0b39ae0f1e40cc96f60242d5b7801841cea6fc592c5d3e1ae50700582a96cf35e1e554995fe4e03381c237
HMAC-SHA-512b42af09057bac1e2d41708e48a902e09b5ff7f12ab428a4fe86653c73dd248fb82f948a549f7b791a5b41915ee4d1ec3935357e4e2317250d0372afa2ebeeb3a
Ancres KDFParamètresSortie (hex, premiers octets)
PBKDF2-HMAC-SHA-1mot de passe / sel, c=4096, 32 octets4b007901b765489abead49d926f721d065a429c12e463f6c4cd79401085b03db
PBKDF2-HMAC-SHA-256mot de passe / sel, c=4096, 32 octetsc5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
HKDF-SHA-256 (RFC 5869 A.1)IKM=0x0b×22, sel=00..0c, info=f0..f9, L=423cb25f25faacd57a90434f64d0362f2a2d2d0a90cf1a5a4c5db02d56ecc4c5bf34007208d5b887185865
HKDF-SHA-256 (RFC 5869 A.2)IKM=00..4f, sel=60..af, info=b0..ff, L=82b11e398dc80327a1c8e7f78c596a49344f012eda2d4efad8a050cc4c19afa97c…
HKDF-SHA-256 (RFC 5869 A.3)IKM=0x0b×22, sel et info vides, L=428da4e775a563c18f715f802a063c5a31b8a11f5c5ee1879ec3454e5f3c738d2d9d201395faa4b61a96c8
Erreurs courantes
  • Confondre HMAC et chiffrement. HMAC prouve l’intégrité et l’origine (avec un secret partagé) ; il ne cache rien. Quiconque n’a pas la clé voit toujours le message entier.
  • Confondre HMAC et une signature. Les signatures numériques sont à clé publique : l’un signe, tout le monde vérifie. HMAC est symétrique : chaque vérificateur pourrait aussi forger. Pour la non-répudiation, il faut RSA/ECDSA (voir l’outil RSA de cette famille une fois publié), pas HMAC.
  • Désaccords de lecture de clé. Une chaîne de 64 caractères hexadécimaux collée dans la zone de clé en texte devient 64 octets, et non 32 — et le HMAC change complètement. Cette page affiche la lecture dans la ligne de sortie ; quand deux outils ne sont pas d’accord, c’est la première chose à comparer.
  • Itérations PBKDF2 trop faibles. 1 000 itérations étaient raisonnables en 2000 ; aujourd’hui, les machines à GPU les avalent. Si votre système stocke encore des hachages à 1 000 itérations, prévoyez une migration avec rehachage à la connexion.
  • HKDF sur un mot de passe. Un HMAC par bloc de sortie signifie qu’un mot de passe passe instantanément — utilisez PBKDF2 (ou Argon2id) pour les mots de passe et HKDF pour les secrets à forte entropie.
  • Réutiliser une même clé dérivée pour tout. La correction est gratuite : dérivez des clés distinctes avec des étiquettes info différentes. Deux clés issues d’un même IKM avec des étiquettes différentes sont indépendantes par conception.
FAQ

HMAC-MD5 est-il cassé ? En tant que hachage résistant aux collisions, MD5 est mort, mais la sécurité de HMAC-MD5 repose sur MD5 comme fonction pseudo-aléatoire, et aucune cassure pratique n’est connue. Il est de toute façon retiré — rien ne justifie de le choisir plutôt que HMAC-SHA-256, sauf la compatibilité avec un ancien protocole.

Quelle doit être la longueur de ma clé HMAC ? Au moins la taille de sortie du hachage (32 octets pour SHA-256), et générée par un CSPRNG. Une clé plus courte que l’empreinte est acceptée, mais chaque bit en dessous réduit directement la sécurité.

PBKDF2 avec plus d’itérations devient-il « plus sûr » indéfiniment ? Il augmente le coût pour l’attaquant de façon linéaire, mais aussi votre coût de connexion de façon linéaire. Le jeu consiste à choisir le plus grand nombre que vos utilisateurs toléreront — c’est ce que calibrent les chiffres de l’OWASP.

Pourquoi HKDF est-il limité à 255 × la taille du hachage ? La boucle d’expansion est T(i) = HMAC(PRK, T(i-1) || info || i) avec un compteur i d’un octet — 255 est la plus grande valeur de compteur, une limite structurelle stricte de la RFC 5869, et non un choix de politique.

Quelle différence entre PBKDF2 sur cette page et le Générateur de hachage de mots de passe ? Même algorithme, rôle différent. Cette page dérive des octets de clé bruts que vous utiliserez ailleurs ; la page de hachage de mots de passe produit des chaînes d’identifiants stockés (avec le sel et les paramètres intégrés) et vérifie des candidats collés par rapport à elles.