Hashing – How a Number Proves a File Has Not Changed

Downloading a file, verifying a backup, storing a password, confirming a document is the one that was signed — all of these rely on the same tool. A cryptographic hash function takes an input of any size and produces a fixed-length number, and does so in a way that makes that number a reliable fingerprint.

What the function does

Feed a hash function a single character or an entire film and it returns an output of the same fixed length — 256 bits for SHA-256, usually written as 64 hexadecimal characters.

The same input always produces the same output. The calculation is fast. And it works in one direction only: from the output, there is no practical way to recover the input.

The property that makes it useful is the avalanche effect. Change one bit of the input — a single character in a document, one pixel in an image — and roughly half the output bits change. There is no partial similarity. Two nearly identical files produce hashes with no visible relationship whatsoever.

Why it cannot be reversed

Hash functions destroy information deliberately. An input of any length maps to a fixed-length output, so there are infinitely many inputs and a finite number of outputs. Multiple inputs must therefore map to the same output.

Reversal is impossible in principle rather than merely difficult, because the information required is not present. The design goal is to make the function behave as though outputs were assigned to inputs at random, so that knowing one tells you nothing about any other.

Collisions and why they matter

Since multiple inputs share outputs, collisions exist. A secure hash function is one where nobody can find them.

With 256 bits there are about 10^77 possible outputs — comparable to the number of atoms in the observable universe. Finding a collision by chance is not a practical concern. Finding one by clever mathematics is, and this is how hash functions are broken.

MD5 was widely used until researchers demonstrated they could construct colliding inputs at will, which meant two different documents could share a hash — destroying its value as proof of integrity. SHA-1 followed the same path. Both remain in use in legacy systems where they should not be, which is a recurring finding in security assessments.

Verifying integrity

The most direct use is confirming that data has not changed. Publishers of software list the hash of each file; you compute the hash of what you downloaded and compare. If they match, your copy is bit-for-bit identical.

The same principle underpins backup verification, digital forensics, and version control systems, which identify every version of every file by its hash. It is also the mechanism behind blockchains, where each block contains the hash of the one before it, so altering an old block invalidates everything after it.

Storing passwords

The other major use is password storage, and it is where implementations most often go wrong.

A system should never store passwords. It stores their hashes, and checks a login by hashing what was typed and comparing. If the database is stolen, the passwords are not directly in it.

Two refinements are essential. A salt — a unique random value added to each password before hashing — ensures identical passwords produce different hashes and defeats precomputed lookup tables. And password hashing should use a function deliberately made slow, such as bcrypt or Argon2, because the speed that makes SHA-256 good for file verification makes it bad here: an attacker with a stolen database can try billions of ordinary hashes per second.

A system storing unsalted fast hashes is barely better than storing the passwords themselves. Whether the systems holding your organisation’s credentials do this correctly is not usually something you can see from outside, which is one of the specific things a structured security assessment is designed to surface.

What hashing does not do

A hash proves a file matches a known value. It does not prove who produced it. Anyone who alters a document can also publish the hash of the altered version, and a reader comparing the two will find them consistent.

Proving origin requires digital signatures, which combine hashing with public-key cryptography. Hashing establishes that something has not changed; signing establishes who vouched for it. The two are frequently confused, and they answer genuinely different questions.