HMAC vs. CRC-32: Authentication vs. Accident Detection
These two checksums solve genuinely different problems despite both producing a short fixed-size output from arbitrary input. CRC-32 detects accidental corruption — a bit flipped by a noisy network link or faulty storage — but it has no secret key, so anyone can recompute a valid CRC-32 for deliberately modified data; it offers zero protection against an intentional attacker.
HMAC (Hash-based Message Authentication Code) combines a cryptographic hash function (commonly SHA-256) with a secret key, so only someone holding that key can produce a valid HMAC for a given message — which is exactly what makes it suitable for verifying both the origin and the integrity of a message, not just accidental corruption. This is the mechanism behind API request signing, webhook payload verification, and JWT signature validation (in the HS256 algorithm variant) — anywhere a receiver needs to confirm a message genuinely came from someone holding the shared secret and wasn't altered in transit.
Choosing CRC-32 where HMAC is actually needed is a real security gap — CRC-32 was never designed to resist a deliberate attacker, only random noise.