HMAC vs Plain Hash: Why Keys Matter

HMAC vs Plain Hash

A common question in cryptography is why you need HMAC when you already have hash functions like SHA-256. The answer lies in a fundamental security property: plain hashes provide integrity but not authentication, while HMACs provide both.

The Problem with Plain Hashes

A plain hash like SHA256(message) proves that a message has not been accidentally modified, but it cannot prove who created the hash. Anyone can compute SHA256("transfer $1000 to Alice") — there is no secret involved. An attacker who intercepts a message can modify it, recompute the hash, and the recipient has no way to detect the tampering.

Why Not Just Hash the Key with the Message?

A naive approach is to concatenate the key and message: SHA256(key || message). This seems secure but is vulnerable to length extension attacks. SHA-256 and other Merkle-Damgard hash functions process data in blocks, and the internal state after processing the original message can be used to continue hashing additional data without knowing the key. An attacker who sees SHA256(key || "amount=100") can compute SHA256(key || "amount=100&admin=true") without knowing the key.

How HMAC Solves This

HMAC uses a two-layer hashing construction:

HMAC(K, m) = SHA256((K XOR opad) || SHA256((K XOR ipad) || m))

This construction is provably secure as long as the underlying hash function has certain properties. The inner hash processes the message, and the outer hash processes the result, preventing length extension attacks and ensuring that the output depends on the entire key in a non-extractable way.

Practical Differences

Property	Plain Hash	HMAC
Integrity	Yes	Yes
Authentication	No	Yes
Requires secret key	No	Yes
Resists length extension	No	Yes
Resists forgery	No	Yes

Always use HMAC when you need to verify both the integrity and the authenticity of a message.