Cryptographic Hashing

Learning outcomes

A cryptographic hash function is one of the most useful tools in computing, and one of the most misunderstood. This page builds the real mental model so the everyday uses (download checks, password storage, blockchains, digital signatures) stop being magic and start being obvious.

After studying this page, you can:

• Explain what a cryptographic hash function computes and the four properties that make it useful: it is deterministic, fixed-size, fast to compute, and practically impossible to reverse.
• Describe the avalanche effect and why changing a single bit of input rewrites the entire output.
• Tell apart the three security properties (preimage, second-preimage, and collision resistance) and say which one a given attack tries to break.
• Judge why a chain of records becomes tamper-evident once each record includes the hash of the one before it.
• Reason about why brute force fails, using the size of the output as the work factor.

Before we dive in

You need almost nothing to start: an input can be any string of bytes (a word, a file, a whole disk image), and the output is a short, fixed-length string of bytes that we usually write in hexadecimal. We will call the input the message and the output the digest (also called the hash). Nothing here requires encryption, keys, or passwords. A hash function takes data in and produces a fingerprint out, and that is the whole interface.

Try the real thing first. Type anything below and watch its SHA-256 digest. Change one letter and watch the whole digest change, then switch the transform to see the same input encoded other ways (the hash is the one you cannot run backwards).

Mental Model

The most common wrong model is that a hash is a kind of encryption you can undo with the right key. It is not. Encryption is a two-way door: what goes in can come back out. A cryptographic hash is a one-way door, more like a fingerprint than a lockbox.

A fingerprint is a small, fixed-size summary that is practically unique to a person, that you can take quickly, and that you cannot use to reconstruct the person. A cryptographic hash is the same idea for data: a small, fixed-size summary that is practically unique to the input, fast to compute, and useless for reconstructing the input. Hold that picture and every use later in the page falls out of it.

Breaking it down

The core teaching is in seven steps. Each one adds a property or a use, and each one has something you can try.

1. A hash is a fingerprint for data

A cryptographic hash function maps an input of any size to an output of fixed size. SHA-256, the function in the box above, always returns 256 bits (64 hexadecimal characters), whether you feed it one letter or a gigabyte. Four properties define it:

• Deterministic. The same input always gives the same digest. This is what lets two people compare a file without sending it.
• Fixed-size. The output length never changes, so a digest is a cheap, uniform handle for data of any size.
• Fast. Computing a digest is cheap, so it is practical to hash every file, every record, every block.
• One-way. Given a digest, there is no practical way to recover an input that produced it. You can only go forward.

One more property hides inside the box above. Change “hello” to “Hello” and the output does not change a little, it changes completely. That is the avalanche effect, and it is the next step.

2. Inside the function

You do not need the internal mathematics to use a hash, but a faithful picture of the shape explains the avalanche effect and the fixed output size. A function like SHA-256 pads the message and splits it into fixed 512-bit blocks. It then mixes each block, one after another, into a small internal state. After the last block, that internal state is the digest.

The animation shows the whole shape at once, and it is yours to explore: drag to pan, zoom, or open it fullscreen to study the loop up close. The main path runs along the top; the compression detail sits below it as a subpath. Watch a block expand into a small working state, the round function stir that state and write the result back 64 times over, and the final state read out as the digest. Nothing is hidden, so you read the full structure before it moves. That repeated two-way stirring is what makes one flipped input bit cascade through the entire output.

Because every block runs through the same stirring and the output is read from a fixed-size state, two facts follow at once: the digest is always the same length, and a one-bit change early in the message is stirred into all 256 output bits.

3. The properties that make it useful

When cryptographers say a hash is “secure,” they mean three specific things are hard. They are easy to confuse, so open each one and notice exactly what an attacker is given and what they must find.

A quick way to keep them straight: preimage and second-preimage fix something for the attacker (a digest, or an input), while collision lets the attacker choose everything. More freedom for the attacker means an easier attack, which is why collision resistance breaks first.

4. Not all hashes are equal

Hash functions have a lifecycle. A function is published, studied for years, and eventually weakened or broken as researchers find shortcuts. Every function is on this clock:

flowchart LR
  P["Published"] --> S["Studied for years"]
  S --> W["Weaknesses found"]
  W --> B["Practical break"]
  B --> R["Retired from security use"]

Using a broken hash for security is a real vulnerability, so the choice matters. Compare the common ones.

The pattern is the lesson. Pick a function with a healthy margin (SHA-256 today), and plan to migrate, because every hash function is on a clock.

5. Tamper-evidence and hash chains

Here is where the one-way fingerprint becomes powerful. Put a list of records in order, and store in each record the hash of the record before it. Now every record depends on its entire history. Change any earlier record, even by one bit, and its hash changes, which breaks the link stored in the next record, which breaks the next, all the way to the end. This is the core idea behind commit histories, audit logs, and blockchains.

Watch the chain link up and verify, then watch a single edit break it and force the attacker into a parallel forgery of every record that follows.

Flip the tamper switch to feel it yourself. Editing one record does not quietly change one line, it visibly breaks the chain from that point on.

To rewrite history convincingly, an attacker would have to recompute the broken record and every record after it. When each link also requires expensive work to forge, that becomes practically impossible, which is exactly how a blockchain resists tampering.

6. Why you cannot brute-force a good hash

The one-way property is not a law of physics; it is a statement about effort. The defense is simply the size of the output. To reverse a digest by brute force you try inputs until one matches, which takes about 2 to the power of n attempts for an n-bit output, and each extra bit doubles that. Drag the output size below and watch the number of attempts, and the time to try them all at a billion per second, explode.

This is why 256 bits is not paranoia. Somewhere past 80 bits the attacker runs out of time and energy in any practical sense, and by 256 bits the count of attempts dwarfs the number of atoms in the observable universe. Collisions are easier to find (about 2 to the power of n over 2, so a 256-bit hash gives roughly 128-bit collision strength), which is why output sizes are chosen with that halving already built in.

Check your understanding before moving on.

7. Hashing in practice

The most everyday use ties it all together: checking that a file you downloaded is exactly the file the publisher released, with nothing corrupted or swapped in transit. Walk the steps.

In a terminal this is a single command, and the comparison is just reading two strings.

sha256sum ubuntu.iso

a1b2c3...  ubuntu.iso

Notice that the publisher never sends you the file privately and you never send it back. The short digest, computed independently on both ends, is enough. That is the fingerprint mental model paying off: a tiny, one-way summary that two parties can compare to agree on a large piece of data they never exchanged directly.

Mastery Questions

1. A website stores the SHA-256 digest of each user’s password instead of the password itself. An attacker steals the digest table. Why does this help, and why is it not the whole story?

   Answer. It helps because of preimage resistance: from a digest there is no practical way to recover an input that produced it, so the raw passwords are not simply sitting there. It is not the whole story because hashing is deterministic and fast, the very properties that make it useful here work for the attacker too. They can hash a huge dictionary of likely passwords once and look for matches, and identical passwords produce identical digests. That is why real systems also salt each password (hash it with a unique random value) and deliberately slow the function down. The hash is necessary but not sufficient.

2. SHA-256 always outputs 256 bits, but its input can be any size. Does that mean two different inputs must eventually share a digest, and if so why do we still trust it?

   Answer. Yes. There are infinitely many possible inputs and only 2 to the power of 256 possible digests, so by the pigeonhole principle collisions must exist. We still trust SHA-256 because existing is not the same as being findable. Collision resistance is about effort, and locating even one collision is estimated at about 2 to the power of 128 operations, which is far beyond any computer that could be built. The guarantee is practical infeasibility, not mathematical impossibility.

3. Two records sit in a hash chain. An auditor recomputes the hash of record 2 and finds it does not match the prev-hash stored in record 3. What can they conclude, and what can they not?

   Answer. They can conclude that record 2 (or the link itself) has been altered since the chain was built: a mismatch means the stored prev-hash no longer reflects the real content, which is exactly the avalanche effect catching a change. What they cannot conclude is who changed it, when, or what the original content was. A hash chain is tamper-evident, not tamper-proof and not a recovery mechanism. It tells you that history was edited and where the edit begins, which is often all you need to reject the data and investigate.