HMAC Generator

What this tool is used for

• Reproducing a webhook signature locally to work out why a provider's header does not match yours.
• Signing an API request for a service that specifies an HMAC over a canonical string.
• Verifying that a message you received carries a valid tag before you parse the body.
• Building a fixture for tests that exercise signature verification, including the failure path.
• Comparing tags across hash choices when a provider offers more than one.

Frequently Asked Questions

Why not just hash the secret and the message together?

Because SHA-256 is a Merkle-Damgård construction and hash(secret || message) is vulnerable to length extension — an attacker can append data and produce a valid tag without knowing the secret. HMAC's nested structure is specifically designed to prevent that.

How does HMAC actually work?

Two passes: H((K ⊕ opad) || H((K ⊕ ipad) || message)), where ipad and opad are the fixed constants 0x36 and 0x5C repeated. The nesting is what closes the length-extension hole, not the secret alone.

How is it different from a signature?

HMAC is symmetric — the same key both creates and verifies, so anyone who can verify can also forge. A digital signature is asymmetric, so a verifier holding only the public key cannot produce one. HMAC gives no non-repudiation.

Must comparison be constant-time?

Yes, and this is a real vulnerability when ignored. A normal string comparison returns early on the first differing byte, leaking timing information that lets an attacker recover a valid tag byte by byte. Use crypto.timingSafeEqual or equivalent.

How long should the key be?

At least as long as the hash output — 32 bytes for HMAC-SHA256. Longer keys are hashed down to block size first, so they add nothing; shorter ones are zero-padded and genuinely reduce security.

Which hash should back the HMAC?

SHA-256 unless something dictates otherwise. HMAC's construction is robust enough that HMAC-MD5 and HMAC-SHA1 are not broken by their hashes' collision weaknesses, but new systems have no reason to start there.

What has to be inside the signed message?

Everything an attacker could otherwise change — including a timestamp, and the identity of the intended recipient. A valid MAC only proves the bytes are unmodified; it says nothing about whether they are being replayed or redirected.

Common errors and gotchas

• Signing a string that omits something an attacker controls — the timestamp, the method, the path — leaving it swappable.
• Comparing tags with ordinary string equality, which leaks timing information an attacker can exploit.
• Disagreeing on canonicalisation. Header order, casing and trailing newlines all change the input and therefore the tag.
• Using a key shorter than the hash output, which throws away security the construction would otherwise give you.
• Confusing an HMAC with a signature. It proves possession of a shared secret, not the identity of one party.