Skip to content

07-03: Exercises

Question

You have the message "Pay Bob $100" and want to send it along with a way for the receiver to detect tampering.

  1. If you only send a plain hash of the message alongside it, why can't the receiver trust that the message wasn't tampered with in transit?
  2. Explain how an HMAC (shared secret + message) fixes this problem.
  3. Suppose the message is changed to "Pay Bob $900". What happens to the hash/HMAC value, and why?

Solution

Step 1: Why a plain hash isn't enough

A cryptographic hash function (see 07-06: Hashing & Message Integrity) is a public, well-known algorithm — anyone can compute SHA-256 of any input, with no secret involved at all.

If you send "Pay Bob $100" plus SHA256("Pay Bob $100"), an attacker who intercepts and modifies the message in transit can simply:

  1. Change the message to "Pay Bob $900".
  2. Recompute SHA256("Pay Bob $900") themselves (nothing stops them — the algorithm is public).
  3. Replace both the message and the hash with their modified versions.

The receiver checks "does the hash match the message?" — and it does, because the attacker recalculated it correctly for their modified message. A plain hash only proves the message wasn't accidentally corrupted (e.g., by a transmission error); it proves nothing about who produced it or whether it was deliberately tampered with, because there's no secret an attacker doesn't also have access to.

👉 (1) A plain hash can be recalculated by anyone, including an attacker who alters the message — so matching hashes alone don't prove the message came from a trusted sender unmodified.

Step 2: How HMAC fixes this

HMAC (Hash-based Message Authentication Code) combines the hash function with a secret key that only the legitimate sender and receiver know:

HMAC = Hash( secret_key, message )   (simplified — real HMAC nests the hash calls for security reasons)

Now, to forge a valid HMAC for a modified message, an attacker would need to know secret_key — which they don't have. They can still change the message in transit, but they cannot produce the matching HMAC value for their modified version, since they lack the one input (the key) required to compute it.

The receiver, who also holds secret_key, recomputes the HMAC over whatever message they received and compares it to the HMAC that came with it. If the message was altered in transit without knowledge of the key, the recomputed HMAC won't match, and the tampering is detected.

👉 (2) HMAC requires a secret the attacker doesn't have, so they can alter the message but cannot produce a matching, valid authentication code for their altered version.

Step 3: What happens with the modified message

Changing even one character — $100 → $900 — is a small change to a human reader, but hash functions are designed with the avalanche effect: a tiny input change produces a completely different, unpredictable-looking output, not a "slightly different" one.

  • SHA256("Pay Bob $100") and SHA256("Pay Bob $900") share no meaningful resemblance — roughly half of all output bits differ on average, purely from that single-character change.
  • Likewise, HMAC(key, "Pay Bob $100") and HMAC(key, "Pay Bob $900") would be completely different values.

This is precisely why hash/HMAC values are useful for integrity checking at all: any modification, no matter how small, is guaranteed to produce a detectably different value — there's no way to make a "small" change to the message that produces only a "small," easily-overlooked change to the hash.

👉 (3) The hash/HMAC value changes completely and unpredictably — this is the avalanche effect, and it's what makes even a one-character tampering attempt detectable.

Final Answer

  • A plain hash doesn't protect against tampering because it can be recomputed by anyone, including the attacker who made the change.
  • HMAC fixes this by requiring a shared secret key that only sender and receiver know — an attacker without the key can't produce a valid HMAC for a message they altered.
  • Any change to the message (even one character) produces a completely different hash/HMAC value due to the avalanche effect, which is exactly what makes tampering detectable.