Générateur HMAC

Générer des signatures HMAC avec SHA-256, SHA-384 ou SHA-512

Algorithme

Message

Fonctionne localement · Sûr pour coller des secrets

Clé secrète

Fonctionne localement · Sûr pour coller des secrets

Signature HMAC

La signature HMAC s'affichera ici…

Qu'est-ce que HMAC ?

HMAC (Hash-based Message Authentication Code) est une construction cryptographique définie dans la RFC 2104 qui combine une fonction de hachage avec une clé secrète pour produire une étiquette d'authentification de taille fixe. Contrairement à un simple hachage que n'importe qui peut calculer, un HMAC ne peut être généré et vérifié que par des parties partageant la clé secrète. HMAC est le mécanisme standard pour vérifier à la fois l'intégrité et l'authenticité d'un message — confirmant que les données n'ont pas été altérées et qu'elles ont été produites par un expéditeur de confiance.

L'algorithme HMAC fonctionne avec n'importe quelle fonction de hachage itérative : SHA-256, SHA-384, SHA-512, et même des fonctions héritées comme SHA-1 ou MD5. La construction résultante est désignée par son hachage sous-jacent — HMAC-SHA256, HMAC-SHA384 ou HMAC-SHA512. La preuve de sécurité de HMAC reposant sur la résistance aux collisions et certaines propriétés pseudo-aléatoires de la fonction de hachage, les algorithmes de la famille SHA-2 sont le choix recommandé pour les nouveaux systèmes. HMAC-SHA256 est la variante la plus déployée, utilisée dans AWS Signature V4, les webhooks Stripe, les secrets de webhook GitHub, la signature de requêtes Slack et les JSON Web Tokens (HS256).

La conception de HMAC offre une propriété critique absente du simple hachage : la résistance aux attaques par extension de longueur. Avec SHA-256 seul, un attaquant connaissant H(message) peut calculer H(message || données_attaquant) sans connaître le message original. La structure de double hachage de HMAC (hachage interne et hachage externe avec des clés rembourrées différentes) prévient entièrement cette attaque. C'est pourquoi les schémas de signature d'API utilisent HMAC plutôt que de concaténer une clé secrète au message et d'en hacher le résultat.

Pourquoi utiliser un générateur HMAC en ligne ?

Calculer des signatures HMAC nécessite généralement d'écrire du code ou d'utiliser des outils CLI. Ce générateur HMAC fonctionnant dans le navigateur vous permet de créer des signatures HMAC-SHA256, HMAC-SHA384 et HMAC-SHA512 instantanément, sans installer de logiciel ni ouvrir un terminal.

Calcul HMAC instantané
Saisissez votre message et votre clé secrète, sélectionnez l'algorithme de hachage, et obtenez immédiatement la signature HMAC. L'API Web Crypto gère le calcul nativement dans votre navigateur.
🔒
Traitement axé sur la confidentialité
Votre message et votre clé secrète ne quittent jamais votre appareil. Tout le calcul HMAC s'exécute localement via l'API Web Crypto — aucune requête serveur, aucune journalisation, aucune conservation de données.
📋
Prise en charge de plusieurs algorithmes
Passez d'un clic entre HMAC-SHA256, HMAC-SHA384 et HMAC-SHA512. Comparez les résultats entre algorithmes pour vérifier que votre implémentation côté serveur correspond.
🔍
Sans compte ni installation
Fonctionne dans tout navigateur moderne — Chrome, Firefox, Safari, Edge. Pas d'inscription, pas d'extension, pas de configuration CLI. Ouvrez la page et commencez à générer des signatures HMAC.

Cas d'usage du générateur HMAC

Développeur front-end — Vérification de signature de webhook
Stripe, GitHub et Shopify signent les charges utiles de webhook avec HMAC-SHA256. Utilisez cet outil pour calculer la signature attendue à partir d'une charge utile et d'un secret, puis comparez-la avec la signature dans l'en-tête HTTP lors du développement.
Ingénieur back-end — Signature de requêtes API
AWS Signature V4 exige HMAC-SHA256 à plusieurs étapes du processus de signature. Générez des valeurs HMAC de référence en développement pour déboguer les incohérences de signature et vérifier les étapes de calcul intermédiaires.
DevOps — Validation de rotation de secrets
Lors de la rotation de secrets de webhook ou de clés de signature API, calculez les signatures HMAC avec l'ancienne et la nouvelle clé pour confirmer que votre application gère correctement la transition avant l'expiration de l'ancienne clé.
Ingénieur QA — Vecteurs de test de signature
Générez des vecteurs de test HMAC avec des entrées et clés connues pour construire des tests de régression pour votre middleware d'authentification. Vérifiez que votre implémentation gère correctement les messages vides, les entrées Unicode et les clés longues.
Ingénieur data — Authentification de messages dans les pipelines
Attachez des signatures HMAC aux messages dans les pipelines orientés événements (Kafka, SQS) pour vérifier que les messages n'ont pas été altérés lors du transit entre les services.
Étudiant — Travaux pratiques de cryptographie
Expérimentez avec HMAC pour comprendre comment la modification d'un seul caractère dans le message ou la clé produit une signature entièrement différente. Comparez la sortie HMAC avec la sortie SHA-256 brute pour observer la différence qu'introduit une clé secrète.

HMAC vs Hachage simple vs Chiffrement

HMAC, le hachage simple et le chiffrement servent des objectifs différents. HMAC fournit l'authentification du message — la preuve qu'il a été créé par quelqu'un possédant la clé secrète et n'a pas été modifié. Un hachage simple garantit l'intégrité mais pas l'authenticité. Le chiffrement assure la confidentialité. Le tableau ci-dessous clarifie ces distinctions.

PropriétéHMACPlain HashEncryption
PurposeMessage authentication + integrityData integrity only (no key)Confidentiality + integrity
Requires secret keyYesNoYes
Verifiable byParties who share the secretAnyoneRecipient with key
ReversibleNo — digest onlyNo — digest onlyYes — decryption recovers data
Output sizeDepends on hash (e.g. 256 bits)Depends on hashVariable (ciphertext)
StandardRFC 2104FIPS 180-4NIST SP 800-38A (AES)
Use case exampleWebhook signature verificationFile checksum verificationEncrypting data at rest

Comparaison des algorithmes HMAC

HMAC peut utiliser n'importe quelle fonction de hachage, mais le choix de l'algorithme sous-jacent détermine la taille de la sortie, le niveau de sécurité et la compatibilité avec le navigateur. HMAC-SHA256 est le choix le plus courant pour les nouveaux systèmes. Le tableau ci-dessous compare les variantes que vous êtes susceptible de rencontrer.

AlgorithmeTaille du condensatLongueur hexWeb Crypto APIIdéal pour
HMAC-SHA256256 bits64 hex charsYesAPI signing, webhooks, JWT (HS256)
HMAC-SHA384384 bits96 hex charsYesTLS 1.3 PRF, CNSA compliance
HMAC-SHA512512 bits128 hex charsYesHigh-security signatures, HKDF
HMAC-SHA1160 bits40 hex charsYesLegacy OAuth 1.0, TOTP (RFC 6238)
HMAC-MD5128 bits32 hex charsNoLegacy only — not recommended

Fonctionnement interne de HMAC

HMAC applique la fonction de hachage sous-jacente deux fois avec deux remplissages dérivés de la clé. La construction est définie dans la RFC 2104 et s'avère être une PRF (fonction pseudo-aléatoire) sous les hypothèses cryptographiques standard. La clé est d'abord rembourrée ou hachée pour correspondre à la taille de bloc de la fonction de hachage (64 octets pour SHA-256, 128 octets pour SHA-512).

HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))
where K' = key padded to block size, ipad = 0x36, opad = 0x5C

L'algorithme effectue un XOR de la clé rembourrée avec une constante de remplissage interne (ipad, 0x36 répété), la concatène avec le message et hache le résultat. Il effectue ensuite un XOR de la clé rembourrée avec une constante de remplissage externe (opad, 0x5C répété), la concatène avec la sortie du hachage interne et hache à nouveau. Cette structure de double hachage est ce qui empêche les attaques par extension de longueur et garantit que la sortie HMAC ne peut pas être calculée sans connaissance de la clé secrète.

Exemples de code HMAC

HMAC est supporté nativement dans tous les langages et runtimes majeurs. L'API Web Crypto fournit HMAC-SHA256, HMAC-SHA384 et HMAC-SHA512 dans les navigateurs sans aucune bibliothèque. Les exemples ci-dessous montrent des patterns d'utilisation réels, notamment la vérification de webhook et la comparaison en temps constant.

JavaScript (Web Crypto API)
async function hmacSHA256(message, secret) {
  const enc = new TextEncoder()
  const key = await crypto.subtle.importKey(
    'raw', enc.encode(secret),
    { name: 'HMAC', hash: 'SHA-256' },
    false, ['sign']
  )
  const sig = await crypto.subtle.sign('HMAC', key, enc.encode(message))
  return Array.from(new Uint8Array(sig))
    .map(b => b.toString(16).padStart(2, '0')).join('')
}

await hmacSHA256('hello world', 'my-secret-key')
// → "90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad"

// Node.js (built-in crypto module)
const crypto = require('crypto')
crypto.createHmac('sha256', 'my-secret-key')
  .update('hello world').digest('hex')
// → "90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad"
Python
import hmac
import hashlib

# HMAC-SHA256
sig = hmac.new(
    b'my-secret-key',
    b'hello world',
    hashlib.sha256
).hexdigest()
print(sig)
# → "90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad"

# Verify a webhook signature (constant-time comparison)
expected = "90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad"
received = hmac.new(b'my-secret-key', b'hello world', hashlib.sha256).hexdigest()
if hmac.compare_digest(expected, received):
    print("Signature valid")

# HMAC-SHA512
hmac.new(b'key', b'data', hashlib.sha512).hexdigest()
Go
package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "fmt"
)

func main() {
    mac := hmac.New(sha256.New, []byte("my-secret-key"))
    mac.Write([]byte("hello world"))
    sig := mac.Sum(nil)
    fmt.Printf("%x\n", sig)
    // → 90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad

    // Verify: use hmac.Equal for constant-time comparison
    expected := mac.Sum(nil)
    fmt.Println(hmac.Equal(sig, expected)) // true
}
CLI (OpenSSL)
# HMAC-SHA256
echo -n "hello world" | openssl dgst -sha256 -hmac "my-secret-key"
# → SHA2-256(stdin)= 90eb182d8396f16d4341d582047f45c0a97d73388c5377d9ced478a2212295ad

# HMAC-SHA512
echo -n "hello world" | openssl dgst -sha512 -hmac "my-secret-key"

# Verify a file signature
openssl dgst -sha256 -hmac "my-secret-key" release.tar.gz

# HMAC with hex key (e.g. from a webhook secret)
echo -n "payload" | openssl dgst -sha256 -hmac "$(echo -n '736563726574' | xxd -r -p)"

Foire aux questions

Quelle est la différence entre HMAC et un hachage simple ?
Un hachage simple (SHA-256, MD5) ne prend qu'un message en entrée et produit un condensat que n'importe qui peut calculer. HMAC prend à la fois un message et une clé secrète, produisant une signature que seule une personne possédant la clé peut générer ou vérifier. Cela signifie que HMAC fournit l'authentification (preuve de l'identité de l'expéditeur) en plus du contrôle d'intégrité. Un hachage simple prouve seulement que les données n'ont pas changé, pas qui les a produites.
HMAC-SHA256 est-il sécurisé ?
Oui. HMAC-SHA256 est considéré comme sécurisé en 2026. Sa sécurité repose sur les propriétés pseudo-aléatoires de SHA-256 et la construction HMAC elle-même (RFC 2104). Aucune attaque pratique contre HMAC-SHA256 n'a été démontrée. Même HMAC-MD5 et HMAC-SHA1 restent sécurisés en pratique car la sécurité de HMAC ne nécessite pas une résistance totale aux collisions de la fonction de hachage sous-jacente, bien que les variantes SHA-2 soient recommandées pour les nouveaux systèmes.
Pourquoi les webhooks utilisent-ils HMAC plutôt que de chiffrer la charge utile ?
Les charges utiles de webhook contiennent généralement des données que le récepteur attend déjà — détails de commande, notifications d'événements, mises à jour de statut. L'objectif n'est pas de masquer les données (confidentialité) mais de prouver qu'elles proviennent de l'expéditeur légitime et n'ont pas été modifiées en transit (authenticité et intégrité). HMAC y parvient avec un overhead minimal : l'expéditeur calcule un HMAC de la charge utile avec un secret partagé et l'inclut dans un en-tête HTTP. Le récepteur recalcule le HMAC et compare. Le chiffrement ajouterait une complexité inutile et une charge de gestion des clés.
Comment comparer les signatures HMAC de manière sécurisée ?
Utilisez toujours une fonction de comparaison en temps constant. En Python, utilisez hmac.compare_digest(). En Node.js, utilisez crypto.timingSafeEqual(). En Go, utilisez hmac.Equal(). Les opérateurs d'égalité de chaînes standard (== ou ===) peuvent divulguer des informations de timing : un attaquant peut mesurer la durée de la comparaison pour déterminer combien d'octets de sa signature forgée correspondent à la signature correcte, puis forcer les octets restants un par un.
HMAC peut-il être inversé pour récupérer la clé secrète ?
Non. HMAC est basé sur une fonction de hachage à sens unique, il n'existe donc aucun raccourci mathématique pour extraire la clé d'une sortie HMAC. Un attaquant devrait forcer l'espace des clés par brute force, ce qui est infaisable pour des clés de 128 bits ou plus. Cependant, les clés faibles ou courtes (comme de simples mots de passe) peuvent être vulnérables aux attaques par dictionnaire — utilisez toujours des clés aléatoires cryptographiquement sûres d'au moins 256 bits pour HMAC-SHA256.
Que se passe-t-il si la clé HMAC est plus longue que la taille de bloc du hachage ?
Si la clé secrète est plus longue que la taille de bloc de la fonction de hachage (64 octets pour SHA-256, 128 octets pour SHA-512), l'algorithme HMAC hache d'abord la clé avec la fonction de hachage sous-jacente pour la réduire à la longueur de sortie du hachage, puis utilise ce hachage comme clé effective. Cela signifie que des clés très longues n'apportent pas de sécurité supplémentaire au-delà de la taille de sortie du hachage. Pour HMAC-SHA256, les clés de plus de 64 octets sont réduites à 32 octets et n'offrent aucune amélioration de sécurité par rapport à une clé de 64 octets ; les clés jusqu'à 64 octets sont utilisées dans leur intégralité.
Quand utiliser HMAC-SHA512 plutôt que HMAC-SHA256 ?
Utilisez HMAC-SHA512 lorsque le protocole l'exige (certaines fonctions de dérivation de clés comme HKDF-SHA512, génération de clés Ed25519), lorsque vous avez besoin d'une signature plus large pour une défense en profondeur, ou lorsque vous fonctionnez sur du matériel 64 bits où SHA-512 est en réalité plus rapide que SHA-256. Pour la plupart des applications web, la signature d'API et la vérification de webhook, HMAC-SHA256 offre une sécurité suffisante et est le choix le plus courant dans les différents écosystèmes.