Hashing & Integrity

You download an installer and the project's website publishes a SHA-256 next to the link. You run the hash, the strings match, and you feel reassured. Now ask the awkward question: what exactly did that prove? If an attacker replaced the file, could they not also have replaced the checksum on the page? What you have actually verified is that the file matches what that page says — which is a statement about the page's integrity, not the file's. Getting from there to a guarantee that holds even when the channel is hostile is what this track is for.

It starts with the hash as a fingerprint: a fixed-size digest of any input, where changing a single bit changes the output completely and finding two inputs that collide is meant to be infeasible. You will use that property directly — deduplication, change detection, content addressing — and then run into its limit, which is that a hash is a public function. Anybody can compute it, so it proves nothing about who produced the message. The fix is a key: HMAC is a hash you can only compute if you hold the secret, which turns a fingerprint into evidence of authorship.

The track then handles the two places this goes wrong in practice. Passwords must not be hashed the way files are — the very speed that makes SHA-256 good for a checksum makes it terrible for a password table, and the whole point of a password hash is to be slow and salted so that a leaked database resists offline cracking. And comparison itself can leak: a naive equality check on a MAC or a reset token returns faster when the first byte is wrong, and an attacker who can time your responses recovers the value one byte at a time. Constant-time comparison closes that, and you will write both versions to see the difference rather than take it on faith.