How to Verify Data Integrity with Hashes

Problem

You need to confirm that data has not changed since a known-good state, using a previously recorded hash.

Prerequisites

• Understanding of hash functions
• Ability to store and retrieve a hash value

Steps

1. 1. Record the baseline hash

   Compute a hash (SHA-256 recommended) of the data in its known-good state. Store this hash in a secure, separate location. The hash serves as a compact fingerprint of the original data.

   Input

   original file

   Output

   SHA-256: a1b2c3...

2. 2. Re-hash the current data

   At a later time, compute the hash of the data again using the same algorithm and encoding. Any change — even a single bit — will produce a completely different hash due to the avalanche effect.

   Input

   current file

   Output

   SHA-256: d4e5f6...

3. 3. Compare and interpret

   If the hashes match, the data is unchanged. If they differ, the data has been modified. For accidental corruption (e.g., disk errors), this detects the problem. For intentional tampering, the hash must be stored somewhere the attacker cannot modify.

   Input

   a1b2c3... == d4e5f6...?

   Output

   DIFFERENT — data changed

Expected result

A definitive yes/no answer on whether the data has changed since the baseline hash was recorded.

Common errors

Using a weak hash like CRC32 for security

CRC32 detects accidental corruption but is trivial to collide. Use SHA-256 for tamper detection.

Storing the hash next to the data

If an attacker can modify the data, they can also recompute and replace the hash. Store the hash in a separate, trusted location.

Troubleshooting

• If hashes differ unexpectedly, check for encoding or line-ending changes before assuming corruption.
• Use a hash comparison tool that shows both values for easy inspection.

Security limits

• Hash comparison detects changes but cannot identify what changed. For that, use a diff tool.
• All hashing is local.