A common exercise is to build a toy hash function that turns 4 characters into an 8-digit code. What two requirements must it satisfy, and what do they teach about real hashes?
It must be deterministic-but-collision-avoiding (only identical inputs give the same code) and position-sensitive (Laus and aLus must differ) — mirroring the uniqueness property of real hashes.
The exercise:
Write a function (in Excel, Python, etc.) that maps any 4-character string to an 8-digit number, and use it to hash Haus, Maus, Raus, Laus, aLus.
Requirement 1 — uniqueness:
Only the same 4 characters should produce the same code; no two different passwords should collide. This is the uniqueness property: a good hash gives every distinct input a distinct output.
Requirement 2 — position matters:
Laus and aLus use the same letters but must produce different codes. So you can't just sum the letter values — you have to weight each character by its position (e.g. multiply by a power of the position).
Why this matters:
These two toy rules are baby versions of what real cryptographic hashes guarantee at scale: every input maps to its own fingerprint, and reordering or changing even one character changes the result. Building one yourself makes you feel why a naive "add up the letters" scheme fails (it ignores order and collides easily).
Tip: A simple position-aware scheme is sum(letter_value(c) * 31^i for i, c in enumerate(pw)) then take 8 digits — the 31^i factor makes position count, exactly the trick real hashes use to spread input bits.
Go deeper:
Cryptographic hash function (Wikipedia) — deterministic + collision-resistant are the real-hash requirements the toy version approximates.