HMAC Signature

HMAC vs a raw hash: why you must not write hash(secret + message)

The problem HMAC solves

A plain cryptographic hash only proves that "the content has not changed". It says nothing about "who sent the content". A very tempting shortcut is to prepend a shared secret and hash the combination: hash(secret + message). That construction is not safe, and the reason is the length extension attack.

MD5, SHA-1 and SHA-256 all use the Merkle-Damgård structure. After the final block is processed, the algorithm's internal state is exactly the hash output. So if an attacker gets hold of hash(secret + message), they have the internal state and can keep computing from that point, forging hash(secret + message + padding + extra) without ever knowing secret. They have manufactured a message your server will accept as authentic.

How HMAC is constructed

HMAC (defined in RFC 2104) closes that gap with two nested hashes and two derived keys:

HMAC(K, m) = H( (K ⊕ opad) ‖ H( (K ⊕ ipad) ‖ m ) )

The outer hash means the final output is not an extendable internal state, so an attacker cannot work backwards from the output to the intermediate state. The key is padded out to the hash block size and XORed with two fixed constants, producing distinct inner and outer keys.

The payoff is important: even if the underlying hash develops a collision weakness, HMAC's security does not immediately collapse. That is precisely why HMAC-MD5 is still considered acceptable inside some protocols, while raw MD5 has been retired as a hash for well over a decade.

HMAC versus a digital signature

The key trade-off: with HMAC, whoever can verify a signature can also generate one, because they hold the same symmetric key. So it fits the relationship "between me and my own server", and it does not fit "I need to prove to a third party that this message originated from me".

Practical signing notes

• Key length: for HMAC-SHA256 use at least 32 random bytes as the key. Do not substitute a short passphrase.
• Compare in constant time. A naive byte-by-byte comparison returns at the first differing byte, so an attacker can time the responses and recover the correct signature one byte at a time. Use a constant-time comparison such as crypto.timingSafeEqual.
• Fold a timestamp into the signed content. Without it the signature can be replayed indefinitely. The server should enforce a window such as plus or minus 5 minutes.
• Sign every critical field, including the path, the HTTP method and a digest of the body. Leaving even one field unsigned is an open door for tampering.

This tool computes HMAC-MD5, SHA-1, SHA-256 and SHA-512, with hex or Base64 output. The key and the message never leave your device; the computation happens entirely inside your browser tab.