Générateur HMAC

En quoi consiste cet outil ?

HMAC signifie Hash-based Message Authentication Code. Il combine une clé secrète, un message et une fonction de hachage standard (comme SHA-256) pour produire une empreinte de longueur fixe. Toute personne disposant de la même clé et du même message obtiendra exactement le même HMAC — mais sans la clé, il est calculatoirement impossible de produire un HMAC valide pour un message, même en connaissant l'algorithme de hachage utilisé.

C'est là toute la différence avec un simple hachage : un hachage classique (MD5, SHA-256, etc.) ne prend en entrée que le message, si bien que n'importe qui peut le calculer et il ne prouve rien sur son auteur. Un HMAC prend le message *et* une clé secrète, de sorte qu'un HMAC valide prouve que l'expéditeur possédait bien le secret — c'est un mécanisme d'authentification, pas une simple vérification d'intégrité.

Le HMAC est formellement normalisé par le NIST dans le FIPS 198-1 et défini pour les protocoles internet dans la RFC 2104 de l'IETF. Cet outil calcule les HMAC via l'API Web Crypto native de votre navigateur (`crypto.subtle.sign` avec l'algorithme HMAC), qui implémente correctement la RFC 2104 plutôt qu'une version JavaScript maison.

Pourquoi l'utiliser ?

• Vous intégrez le webhook Stripe et le endpoint renvoie "signature verification failed" — vous collez la même clé et le même payload ici pour voir si votre serveur calcule correctement le HMAC-SHA256 avant de continuer à déboguer le code.
• Vous venez d'écrire la fonction qui signe les requêtes sortantes vers une API tierce et voulez comparer sa sortie à un calcul indépendant avant de la valider.
• Un collègue vous a transmis un secret partagé pour tester une intégration et vous devez générer la signature d'une requête de test sans installer de bibliothèque ni écrire un script juste pour ça.
• Vous documentez comment signer les requêtes vers votre propre API interne et avez besoin d'un exemple reproductible avec clé, message et HMAC résultant à inclure dans le guide de l'équipe.
• Vous soupçonnez votre backend d'utiliser SHA-1 au lieu de SHA-256 pour signer un token et voulez comparer les deux résultats côte à côte pour confirmer lequel correspond à celui que vous recevez.

Mode d'emploi

1. Saisissez votre clé secrète dans le champ « Clé secrète ».
2. Saisissez le message que vous souhaitez authentifier dans le champ « Message ».
3. Les résultats HMAC-SHA1, HMAC-SHA256, HMAC-SHA384 et HMAC-SHA512 sont générés instantanément (cochez « Sortie en majuscules » si le système visé attend des lettres majuscules).
4. Cliquez sur « Copier » à côté du HMAC dont vous avez besoin.

Exemple

Entrée

Clé secrète : key
Message : The quick brown fox jumps over the lazy dog

Résultat

HMAC-SHA256: f7bc83f430538424b13298e6aa6fb143ef4d59a14946175997479dbc2d1a3cd8
HMAC-SHA1: de7c9b85b8b78aa6bc8a7a36f70a90701c9db4d9

Il s'agit d'un vecteur de test standard publié : avec la clé « key » et ce message exact, HMAC-SHA256 et HMAC-SHA1 produisent toujours ces valeurs quelle que soit l'implémentation correcte utilisée, ce qui vous permet de vérifier indépendamment le résultat de cet outil.

HMAC contre simple hachage : quand une clé est nécessaire

La question déterminante est : devez-vous prouver qui a créé cette empreinte, ou simplement que le contenu n'a pas changé ? Si une somme de contrôle publique suffit — vérifier qu'un fichier téléchargé correspond à ce qu'a indiqué l'éditeur, dédupliquer des enregistrements —, un simple hachage fait l'affaire et n'importe qui peut le vérifier, sans clé. Si vous devez prouver que l'empreinte n'a pu être produite que par une personne détenant un secret précis — authentifier l'appelant d'une API, faire confiance à l'expéditeur d'un webhook —, il vous faut du HMAC, car un simple hachage donnerait à un attaquant sans aucun secret la même capacité à forger une empreinte valide que l'expéditeur légitime.

→ Générateur de hachage multi-algorithmes · Décodeur JWT · Générateur MD5

Comparaison des quatre algorithmes HMAC

Les quatre utilisent la même construction HMAC issue de la RFC 2104, et ne diffèrent que par la fonction de hachage sous-jacente, donc par la longueur de sortie.

Cas d'usage courants

• Signer les requêtes API sortantes avec un secret partagé pour que le serveur puisse vérifier l'identité de l'appelant.
• Vérifier les charges utiles de webhooks entrants (les en-têtes Stripe-Signature, X-Hub-Signature-256 de GitHub et similaires utilisent tous HMAC-SHA256).
• Générer et valider la partie signature d'un JWT signé avec HS256/HS384/HS512.
• Vérifier que votre implémentation HMAC côté serveur ou côté client correspond au résultat attendu avant de la déployer.

Erreurs courantes lors du débogage d'une signature HMAC qui ne correspond pas

• Signer le JSON reformaté par votre framework au lieu du corps brut exact de la requête — la plupart des fournisseurs de webhooks (Stripe compris) exigent de signer les octets exacts reçus avant tout parsing, car même un espace en trop change le HMAC résultant.
• Utiliser un encodage de texte différent de l'UTF-8 d'un côté de l'intégration — presque toutes les bibliothèques modernes utilisent l'UTF-8 par défaut, mais un système hérité en Latin-1 produira un HMAC différent pour le même texte visible.
• Comparer une sortie en hexadécimal minuscule à une valeur attendue en majuscules (ou en Base64 au lieu d'hexadécimal) — la valeur cryptographique est la même, mais une comparaison de chaînes littérale échouera si les formats ne correspondent pas exactement.
• Oublier un saut de ligne final ajouté automatiquement par votre éditeur de texte lors du collage de la clé ou du message — invisible à l'œil, mais change complètement le HMAC calculé.

Foire aux questions