Générateur HMAC

Qu’est-ce que HMAC ?#

HMAC signifie Hash-based Message Authentication Code (code d’authentification de message fondé sur le hachage). Un hachage simple (comme SHA-256) répond à la question « ce flux d’octets a-t-il changé ? ». HMAC répond à une question plus forte : « ce flux d’octets a-t-il changé, et a-t-il été envoyé par quelqu’un qui partage réellement ma clé secrète ? ». La différence compte chaque fois qu’un message voyage sur un canal en lequel vous n’avez pas une confiance aveugle — rappels de webhook, URL signées, signature de requêtes d’API, jetons inter-services.

Mécaniquement, HMAC mélange une clé secrète dans la fonction de hachage d’une façon définie (deux passes, avec remplissage) afin que le condensat ne puisse pas être forgé sans la clé. La sortie est une chaîne d’octets de longueur fixe dont la taille correspond au hachage sous-jacent : 20 octets pour SHA-1, 32 pour SHA-256, 48 pour SHA-384, 64 pour SHA-512.

Cette page calcule HMAC dans votre navigateur via l’API Web Crypto. Vous choisissez le hachage, collez le message et la clé secrète, et obtenez le condensat en hex ou base64.

Mode d’emploi#

1. Saisissez ou collez le Message — la charge utile que vous voulez authentifier. Ce sont les octets que le récepteur hachera de son côté.
2. Saisissez la Clé secrète. Le champ est masqué par défaut ; cliquez sur le bouton en forme d’œil à droite pour le révéler pendant la frappe. La clé et le message sont tous deux encodés en UTF-8.
3. Choisissez l’Algorithme :
   • SHA-1 — 160 bits. Rapide, mais uniquement adapté à HMAC hérité (certaines anciennes procédures de signature l’exigent encore). N’utilisez pas SHA-1 pour les signatures numériques.
   • SHA-256 — 256 bits. Le défaut moderne ; la grande majorité des signatures de webhook (Stripe, GitHub, les flux façon Slack) utilisent HMAC-SHA-256.
   • SHA-384 / SHA-512 — condensats plus longs, résistance aux collisions marginalement meilleure, légèrement plus lents. Choisissez-en un quand le système récepteur l’exige explicitement.
4. Choisissez l’encodage de sortie : hex (typique pour les en-têtes façon X-Signature) ou base64 (typique quand le condensat est embarqué dans du JSON ou un jeton).
5. Cliquez sur Générer. Le condensat apparaît dans le panneau de droite ; la ligne d’état affiche l’algorithme et la longueur en octets à titre de vérification de cohérence. Copier pour le récupérer.

Principales fonctionnalités#

• Soutenu par Web Crypto. Utilise le crypto.subtle natif du navigateur, la même primitive qu’utilise le code de production — pas une réimplémentation JavaScript.
• Vérification de cohérence de longueur. Chaque condensat est vérifié contre la longueur d’octets attendue pour son algorithme, donc un résultat tronqué ou altéré ne passe pas silencieusement.
• Sortie hex ou base64. Bascule en un clic ; pas de retaper.
• La clé reste locale. Le champ de clé est rendu comme un champ de mot de passe et ne quitte jamais la page — il n’y a pas de backend.
• Conscient du contexte sécurisé. Si la page était jamais chargée en HTTP brut, crypto.subtle est indisponible et l’outil le signale explicitement au lieu de produire un mauvais résultat.

Exemple détaillé#

La paire de référence classique (RFC 4231) utilise une clé Jefe et le message what do ya want for nothing?. Avec cette page réglée sur SHA-256 et hex, le condensat est :

5bdcc146bf60754e6a042426089575c75a003f089d2739839dec58b964ec3843

Basculez sur SHA-512 avec les mêmes entrées et le condensat double de longueur :

164b7a7bfcf819e2e395fbe73b56e0a387bd64222e831fd610270cd7ea2505549758bf75c05a994a6d034f65f8f0e6fdcaeab1a34d4a6b4b636e070a38bce737

Vous pouvez reproduire les deux ici-même : chargez Exemple, puis Générer. Cette paire exacte est aussi comment la propre suite de tests de cet outil vérifie son exactitude — si vous obtenez un jour un condensat différent, quelque chose a altéré la page.

FAQ#

SHA-256 ou SHA-512 — lequel utiliser ?#

Pour HMAC spécifiquement, SHA-256 est le défaut pragmatique : tous les grands signataires de webhook l’utilisent, il est rapide, et 256 bits de condensat sont déjà loin au-delà du territoire de la force brute. Passez à SHA-512 uniquement quand (a) le système récepteur l’exige, ou (b) vous concevez un nouveau protocole à partir de zéro et voulez la marge de collision supplémentaire pour un coût en vitesse modeste. Évitez SHA-1 entièrement à moins que vous ne calquiez un système hérité qui l’impose.

HMAC est-il la même chose que chiffrer le message ?#

Non. HMAC ne fait qu’authentifier — il prouve que le message n’a pas été altéré et qu’il provient de quelqu’un qui détient la clé. Le message lui-même reste en texte clair. Si vous avez aussi besoin de confidentialité, associez HMAC à un schéma de chiffrement, ou utilisez un mode de chiffrement authentifié comme AES-GCM.

La clé secrète peut-elle être récupérée à partir du condensat ?#

Non. Le condensat est une fonction à sens unique du message et de la clé ; récupérer la clé à partir des sorties est calculatoirement infaisable. Cela dit, une clé courte ou devinable peut encore être forcée brutalement en essayant des clés candidates hors ligne — utilisez donc une clé avec au moins 128 bits de vraie entropie, pas un mot de passe choisi par un humain.

Le récepteur dit que ma signature ne correspond pas. Que vérifier en premier ?#

Neuf fois sur dix, c’est la représentation en octets du message : sauts de ligne finaux, encodage d’URL contre corps brut, espaces JSON, ou un ordre de champs différent. Comparez les octets exacts que vous avez signés contre les octets exacts que le récepteur a hachés, caractère par caractère, avant de vérifier quoi que ce soit d’autre.