integrity

Overview

Beyond passwords, hashes have a second major job: proving that data has not changed. When you download a file, verify a message, or fingerprint evidence, a hash gives you a compact value you can recompute and compare. This is integrity verification. This lesson explains how hashes provide integrity, what they do and do not guarantee, and how HMAC and signatures add authenticity — all in a defensive, educational context.

Learning objectives

• Explain how a hash detects that data has changed.
• Distinguish integrity from authenticity.
• Describe checksums, HMAC, and hashes inside digital signatures.
• Explain why a weak hash undermines integrity guarantees.

Core concept

Integrity means data has not been altered — accidentally or maliciously — between two points. Because a hash is deterministic and exhibits the avalanche effect (any change flips the digest completely), you can verify integrity by publishing the hash of the original data and later recomputing it: if the two digests match, the data is unchanged; if they differ, something was modified. A hash used this way is often called a checksum or digest.

Integrity is not the same as authenticity. A plain published hash tells you whether data changed, but not who produced it. If an attacker can replace both the file and its published hash, a bare hash proves nothing. Authenticity requires a secret key or a signature, which the next sections cover.

How it works

• File and download verification. A publisher computes, say, the SHA-256 of a release and posts the digest. After downloading, you recompute the SHA-256 of your copy and compare. A match means your copy is bit-for-bit identical to what was hashed; a mismatch means corruption in transit or tampering. This only defends against an attacker who cannot also alter the trusted digest, which is why digests are published over a trusted channel.

• HMAC (keyed integrity + authenticity). An HMAC combines a hash function with a secret key to produce a keyed digest. Only someone with the key can compute or verify a valid HMAC, so it proves both that the message is unchanged and that it came from a party holding the key. HMAC is used to protect messages, API requests, and tokens against tampering by attackers who do not know the key. Unlike a bare hash, an attacker cannot recompute a matching HMAC after changing the data, because they lack the key.

• Hashes inside digital signatures. Signing large data directly is impractical, so signature schemes hash the data first and then sign the digest with a private key. Anyone can verify with the corresponding public key. This provides integrity and authenticity: the signature covers the hash, so any change to the data changes the hash and breaks the signature. This is exactly why collision resistance matters here — if an attacker could find two files with the same hash, a signature over one would also validate the other.

Practical example

In an isolated lab you verify a downloaded archive:

Published (trusted channel):  SHA-256 = 3ba3...e91  (the vendor's stated digest)
Your download:                sha256sum archive.tar.gz
  -> 3ba3...e91   MATCH   => file is intact and unmodified
  -> 9f77...a02   DIFFERS => file is corrupted or tampered; do not trust it

A single flipped bit anywhere in the archive would produce a completely different digest (the avalanche effect), so the comparison reliably detects any change. Now suppose the vendor instead published an HMAC or a digital signature rather than a bare hash: an attacker who tampered with the archive could not forge a matching value without the secret or private key, so you would gain authenticity on top of integrity. The bare digest alone only defends integrity, and only if the published digest itself is trustworthy.

Cybersecurity relevance

Integrity verification is everywhere in security: software supply-chain protection (verifying releases and packages), forensics (hashing evidence so its integrity can be proven later), secure protocols (TLS uses HMAC-style integrity), tokens and API request signing, and code signing. Choosing a collision-resistant hash is essential wherever an attacker chooses the data — using MD5 or SHA-1 for signatures or code integrity is dangerous precisely because practical collisions exist, letting an attacker craft a malicious file with the same digest as a benign one. Defenders verify digests over trusted channels, prefer HMAC or signatures when authenticity is needed, and use modern hashes (SHA-256 or stronger). In CTFs, integrity concepts appear in forensics (file fingerprinting) and crypto (signature and HMAC challenges).

Common mistakes

• Confusing integrity with authenticity — a bare hash detects change but does not prove origin.
• Trusting a hash published on the same untrusted channel as the file, so an attacker can swap both.
• Using MD5 or SHA-1 for signatures or integrity of attacker-influenced data, where broken collision resistance enables forgery.
• Forgetting the key — treating a plain hash as if it provided the tamper-proofing that only HMAC or a signature gives.

Key takeaways

• Hashes verify integrity because they are deterministic and any change flips the digest completely; recompute and compare.
• Integrity (data unchanged) is distinct from authenticity (who produced it); a bare hash gives only integrity, and only if the digest is trusted.
• HMAC adds a secret key for keyed integrity and authenticity; digital signatures sign a hash of the data with a private key.
• Collision resistance is critical for signatures and integrity of attacker-chosen data, so use modern hashes, not MD5 or SHA-1.

Check your understanding

• Why does a bare published hash not prove who created a file, and what adds that guarantee?
• Why is collision resistance essential when a hash is used inside a digital signature?