Hashing, hands on

A hash function takes an input of any size and returns an output of one fixed size. SHA-256 returns 256 bits, written as 64 hexadecimal characters. It holds no state, it stores nothing, and it has no key. Give it the same bytes and it gives you the same 64 characters on any machine, in any language, in any year.

That is the whole interface. What makes it useful for a register is not the interface but four properties of the mapping underneath, and one of those four is the load bearing one.

• Digest. The output. Also called a hash or a fingerprint. Always 64 hexadecimal characters here.
• Test vector. A published input and the digest every correct implementation must return for it.
• Self test. Running the vectors at load time instead of hoping. CHAIN.selfTest() does it in this page.
• Avalanche. A tiny change to the input producing an unrecognisable digest.
• Preimage. An input that produces a given digest. Finding one has no method better than guessing.
• Collision. Two different inputs with the same digest. They must exist by counting, and none is known for SHA-256.
• Block hash. The digest of a whole assembled block rather than of its entry text. Session 2.
• Key management. Who holds which secret and how it is rotated. A discipline of its own, in the security courses.

Suppose digests behaved sensibly, so that similar inputs produced similar outputs. Forging an entry would become a hill climb. Write the line you want, compare its digest with the one you need to match, nudge a character, compare again, keep whatever got you closer. Any search with feedback finishes eventually.

The absence of a gradient turns that into a blind lottery. Each attempt is independent, nothing carries over, and there is no signal to follow. This is also the reason a hash is called one way. Forwards costs one pass. Backwards has no known method better than trying inputs until one lands.

Inputs are unlimited and outputs are not, so different inputs must share digests somewhere. That is arithmetic, not a defect, and it is true of every hash function that has ever existed. The engineering claim is narrower: no two colliding inputs for SHA-256 have been found, and nobody has a method for constructing a pair.

Keep the distinction handy, because the two sentences get merged in conversation. Collisions exist. Nobody can produce one. Only the second sentence is a property of SHA-256, and only the second sentence can expire.

Speed is what lets a buyer recompute a six block register in the time it takes to read this sentence. It is also what lets an attacker try a very large number of inputs, because their guesses cost the same as your checks. For a register that is fine, since the attacker still has no gradient and no shortcut.

It stops being fine the moment the input is small and predictable, which is why storing short human chosen secrets under a fast hash is a different problem with different tools. That problem belongs to the security courses, and the register does not have it.

Press the second button and look at the digests before you look at the verdicts. They are 64 characters, they are hexadecimal, they are different for different inputs, and they are stable across reloads. Every property you can see by eye is satisfied. The function behind them is not a hash function in any useful sense and nothing on screen says so.

That is the argument for shipping vectors inside the implementation and running them at load time rather than in a test suite somebody remembers to run. A digest that is wrong is indistinguishable from a digest that is right, right up until somebody else recomputes it and disagrees with you in public.

They are published alongside the specification, which is the point of them. The digest of abc is not an opinion held by this engine, it is the value any conforming implementation must return, and it has been the same value since SHA-256 was standardised. Three inputs were chosen to exercise different paths: a short input, an empty one, and one long enough to force a second compression block.

The empty string is the one people leave out, and it is the one that catches padding bugs, because it is entirely padding.

One camp holds a firm rule: never write your own implementation of a cryptographic primitive. Use the platform's, which is reviewed by specialists, hardened against timing attacks and maintained by people whose job it is. A hand written SHA-256 in a page like this one is, on that view, exactly the practice that produces the silent failures the vectors are there to catch.

The other camp holds that an implementation you can read end to end and check against published vectors is worth more, in a teaching or auditing setting, than a platform call whose behaviour you take on faith. The vectors are what make the claim checkable by the reader rather than by reputation, and reputation is not evidence.

The engine on these pages sits squarely in the second camp and is honest about which camp that is. Both positions are held by people who have shipped real systems, and the sides do not even fully disagree: the first camp's rule is about production and the second camp's rule is about understanding. Where they genuinely collide is the system that quietly grows from a demonstration into production, which is most of them.

Two unrelated digests agree at any given position about one time in sixteen, because there are sixteen hexadecimal characters. Across 64 positions that predicts roughly four accidental matches, which is why measured counts sit near 60 rather than at 64. A pair that differed in all 64 positions every time would be the suspicious result, not the reassuring one.

So the honest reading of 58 and 60 is not "almost everything changed". It is "the second digest looks like a digest drawn at random with no relationship to the first", which is the property the register needs.

Someone rewriting a custody entry needs a different sentence with the same digest. The measurement says the nearest possible sentences, the ones differing by a single character, land nowhere near the target. There is no sequence of small edits that walks a digest towards a value, because each edit throws the digest somewhere unrelated.

What is left is guessing, and the space is 64 hexadecimal characters wide. That is the whole of the defence, and it is enough, which is why sessions 3 and 4 are about a completely different attack: not breaking the hash, but recomputing everything downstream of the edit.

Counting differing hexadecimal characters is easy to see and easy to explain, and it is not the measure a cryptographer would use. The proper statement of avalanche is at the bit level: flipping one input bit should flip each of the 256 output bits with probability one half. A character counts as differing if any of its four bits moved, which inflates the visible ratio.

The character count is used here because it is checkable on screen in a page anyone can open. Take 58 and 60 as demonstrations of the shape of the property, not as its definition.