Générateur HMAC
Calculez HMAC-SHA256, SHA-384, SHA-512, SHA-224, SHA-1, MD5, SHA3 ou RIPEMD-160 d’un message avec une clé texte, hex ou Base64. Sortie hex ou Base64, en direct.
HMAC (RFC 2104) injecte la clé deux fois dans le hachage : H((K ⊕ opad) || H((K ⊕ ipad) || message)). Les clés plus longues que le bloc du hachage sont d’abord hachées. Côté serveur, comparez les MAC en temps constant.
Qu'est-ce que Générateur HMAC ?
Calcule un code d’authentification de message à clé (HMAC, RFC 2104) pour un message et une clé secrète. Il prend en charge SHA-2, SHA-3, SHA-1, MD5 et RIPEMD-160, des clés données en texte, hex ou Base64, et affiche le MAC en hex minuscules/majuscules ou en Base64 pendant la saisie.
Comment utiliser Générateur HMAC
- Saisissez le Message (texte, ou passez l’encodage sur Hex pour des octets bruts).
- Entrez la Clé secrète et indiquez s’il s’agit de texte (UTF-8), d’Hex ou de Base64.
- Choisissez l’Algorithme, par exemple HMAC-SHA-256.
- Choisissez le Format de sortie et copiez le HMAC.
Exemple
Message « what do ya want for nothing? », clé « Jefe », HMAC-SHA-256
5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843
Cas de test 2 de la RFC 4231.
Quand utiliser Générateur HMAC
Utilisez-le pour vérifier des signatures de webhooks (Stripe, GitHub, Shopify, Slack), signer des requêtes d’API, déboguer des étapes de signature de type AWS ou vérifier des vecteurs de test HMAC. Il ne convient pas au hachage de mots de passe (utilisez bcrypt ou Argon2) et ce n’est pas une signature numérique : quiconque possède la clé peut créer le MAC.
Comment fonctionne Générateur HMAC
HMAC(K, m) = H((K′ ⊕ opad) ‖ H((K′ ⊕ ipad) ‖ m)), où K′ est la clé complétée par des zéros à la taille de bloc du hachage (les clés plus longues que le bloc sont d’abord hachées), avec ipad = 0x36 et opad = 0x5C répétés. Cette construction reste sûre même pour des hachages comme MD5 et SHA-1 dont la résistance aux collisions est cassée. Les empreintes proviennent de hash-wasm et les résultats correspondent aux vecteurs de test des RFC 4231 et RFC 2202.
Cas d'utilisation courants
- Vérifier une signature GitHub
X-Hub-Signature-256ou un webhook Stripe - Reproduire la signature d’une requête d’API pendant le débogage
- Vérifier les vecteurs de test HMAC de la RFC 4231
- Générer des valeurs HMAC-SHA1 pour déboguer OAuth 1.0 ou TOTP hérités
- Comparer les résultats de deux langages qui ne concordent pas
Note de Sécurité
La clé et le message restent dans votre navigateur. Comparez les MAC côté serveur avec une fonction à temps constant pour éviter les attaques temporelles.
Questions Fréquentes
Pourquoi mon HMAC ne correspond-il pas à l’en-tête du webhook ?
Vérifiez que vous hachez le corps brut de la requête octet par octet (sans JSON reformaté), le secret exact (certains fournisseurs le donnent en Base64 ou avec un préfixe comme whsec_), et l’encodage de sortie attendu : GitHub utilise l’hex, Shopify le Base64.
HMAC-SHA1 ou HMAC-MD5 sont-ils encore sûrs ?
En tant que MAC, ils n’ont pas de cassure pratique, car HMAC ne repose pas sur la résistance aux collisions. Ils sont considérés comme hérités ; utilisez HMAC-SHA-256 ou plus pour les nouveaux systèmes.
La clé peut-elle être vide ?
La RFC 2104 l’autorise et l’outil la calcule, mais une clé vide n’apporte aucune sécurité.
HMAC revient-il à hacher clé + message ?
Non. Un simple hash(key + message) est vulnérable aux attaques par extension de longueur avec SHA-2 ; le double hachage de HMAC l’évite.