SkillGridLearn computer science by doing

Hashing, encryption and signatures

One tool hides data, another only fingerprints it, and a third proves who sent it. Mixing them up breaks real systems.

15 min · 45 XP

Three tools get confused constantly, and the confusion causes real breaches. A hash is a fingerprint: it proves two things are identical without showing the original. Encryption is a locked box: it hides data so the right person can open it later. A digital signature is a wax seal: it proves who wrote something and that nobody changed it on the way. Different jobs, different tools.

A hash function takes any input and produces a fixed-length value, always the same for the same input. Change one character and the result changes completely, with no way to predict how. And it does not run backwards: from the hash you cannot recover the input. That last property is the whole reason passwords are stored as hashes instead of as text.

input            hash of the input
---------------  --------------------------------
hello            2cf24dba5fb0a30e26e83b2ac5b9e29e...
HELLO            5d41402abc4b2a76b9719d911017c592...
hello!           ce06092c8f0e3f0e2b8f6ec9c8f4b1f2...

one character changed  ->  a completely different hash
same input every time  ->  the same hash, alwaysA hash is a fingerprint, not a locked box: it proves the input was the same, and it never reveals the input.

Encryption is the opposite of hashing: it is meant to be reversible. A key turns readable text into scrambled bytes, and the right key turns them back. That reversibility is exactly why you never store passwords this way — if the server can decrypt them, so can anyone who steals the key. Encryption is for data in transit and for files that must later be read again.

BrowserShop serverHTTPS: here is my card numbereverything below happens inside TLSlock and key agreed oncescrambled bytesanyone reading the cable sees noise, not the card

A digital signature answers a different question: not "what does this say" but "who wrote it, and is it unchanged". You sign with a private key that never leaves your machine; anyone can check the signature with the matching public key. This is what HTTPS certificates rest on, and why a download page can let you verify that the file you got is the file the developers published.

openssl dgst -sha256 -sign release.key -out app.sig app.bin
openssl dgst -sha256 -verify release.pub -signature app.sig app.binThe pattern in one line each: signing produces a small .sig file, verification either accepts or rejects it.

Practice

  1. Match each tool with the job it is actually designed for.

    Hints
    • Ask of each tool: can it be turned back into the original text?
    • A fingerprint identifies, a locked box hides, a signature proves who wrote it.

    15 XP

  2. Two users pick the same password. Their hashes stored in the database look completely different. What made that happen?

    Hints
    • Salt is stored next to the hash, so it is not a secret.
    • Its job is to make sure two people with the same password do not end up with the same stored value.

    14 XP

  3. Why does TLS use a key exchange instead of simply shipping one shared secret key to both sides?

    Hints
    • A shared secret has to reach both sides first — and that trip is the weak point.
    • Signing works the other way round: the key that proves authorship never leaves its owner.

    16 XP