Hashing, MACs, and Integrity

A cryptographic hash turns any input into a fixed-length fingerprint that is infeasible to reverse or to collide — the tool for integrity, not secrecy. But a bare hash proves nothing about who produced it. A MAC — a message authentication code such as HMAC — adds a secret key, so the recipient knows the data is both unaltered and from someone who holds the key.

This topic separates three jobs people constantly conflate: hashing for integrity, MACs for authenticated integrity, and — in the next topic — hashing for password storage, which has entirely different rules. Getting the wrong one is a recurring source of real vulnerabilities.

What a Cryptographic Hash Guarantees

A cryptographic hash is deterministic, fixed-length, one-way, and collision-resistant: the same input always gives the same digest, you cannot feasibly work backward to the input, and you cannot feasibly find two inputs with the same digest. SHA-256 is the workhorse. MD5 and SHA-1 are broken for security use — practical collisions exist — so they survive only as non-security checksums against accidental corruption.

Integrity Checking in the Wild

Publishing a file's hash lets a downloader verify it was not corrupted or swapped — but only if the hash itself arrives over a channel the attacker cannot touch. A hash posted on the same page as the download helps against accidental corruption, not against an attacker who simply changes both the file and the hash. Integrity is only as trustworthy as the delivery of the value you check against, which is where signatures come in later.

HMAC — Integrity Plus Authenticity

Combine a hash with a secret key and you get a tag that only key-holders can compute or verify. HMAC proves a message is both unaltered and from the right party, and it is the mechanism behind signed API requests and tamper-proof cookies. Critically, use HMAC rather than naively hashing "message plus secret," because that naive construction is vulnerable to length-extension attacks that HMAC is specifically built to resist.

# the client and api.meridian.example share a secret key
BODY='{"amount":500,"to":"acct-91"}'
SIG=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$SHARED_SECRET" -hex | awk '{print $2}')

# the client sends BODY plus the signature header:
#   X-Signature: <SIG>
# the server recomputes the HMAC over the received body and compares in CONSTANT TIME

The client signs the request body with the shared secret; the server recomputes the same HMAC over what it received and compares. If a single byte of the body was tampered with in transit, the recomputed tag will not match and the request is rejected. The one detail that voids the whole scheme is the comparison: it must be constant-time.

Constant-Time Comparison

Verifying a MAC with an ordinary string comparison leaks timing — a comparison that bails out on the first mismatched byte tells an attacker, through response timing, how much of their forged tag was correct, letting them recover it byte by byte. Secrets and tags must be compared with a constant-time function the library provides. It is a small detail that completely undoes the MAC if missed.