Hash Generator

A cryptographic hash function takes an input of any size and produces a fixed-size output — 128 bits for MD5, 160 for SHA-1, 256 for SHA-256, 512 for SHA-512 — with three properties that make it useful: it's deterministic (the same input always produces the same output), it's a one-way function (there's no way to reconstruct the original input from just the hash, other than trying inputs until one matches), and it exhibits the avalanche effect, where changing even a single character of the input produces a completely different, unpredictable hash rather than a similar one.

That avalanche effect is exactly what makes a hash useful for integrity checking: if you hash a file before and after downloading it and the two hashes differ by even one bit, you know with near-certainty that even a single byte changed somewhere — whether from corruption in transit or deliberate tampering. You don't need to compare the files byte by byte; a mismatched 64-character hash is proof enough that something is different.

"Broken" here has a specific technical meaning: researchers found practical ways to produce a collision — two different inputs that hash to the exact same output — faster than brute force should theoretically allow. MD5 collisions became practically achievable starting around 2004, and by 2017 Google and CWI Amsterdam publicly demonstrated a full SHA-1 collision (two different PDF files with identical SHA-1 hashes), which pushed major software vendors to deprecate SHA-1 for anything security-sensitive.

This doesn't mean MD5 or SHA-1 are useless — for detecting accidental corruption (a partial download, a bit flip on disk), where nobody is deliberately trying to construct a matching file, they still work fine, and MD5 checksums remain common for exactly that reason. What they can no longer be trusted for is anything where an adversary might deliberately craft a malicious file that hashes identically to a legitimate one — digital signatures, certificate fingerprints, or any scenario where a forged collision would actually benefit an attacker.

Unlike encryption or Base64 encoding, a hash cannot be reversed to recover the original input — the operation is fundamentally one-directional, and any tool claiming to "decrypt" a hash is actually doing a lookup against a precomputed table of common inputs and their hashes (a rainbow table), not reversing the math. If your input isn't in some precomputed table, there is no shortcut back to it.

This is also precisely why a hash is the wrong tool for anything you need to get back later, like encrypted storage — a hash's whole purpose is proving two things are the same without ever needing to reveal what the original thing was, which is a fundamentally different job from encryption's purpose of protecting data you intend to recover.

MD5 and SHA-256 are both designed to be fast — that's exactly what makes them good for checksums and exactly what makes them dangerous for passwords. A modern GPU can compute billions of SHA-256 hashes per second, which means an attacker with a stolen password database of plain SHA-256 hashes can brute-force short or common passwords by simply trying billions of candidates per second until one matches, no cleverness required.

Purpose-built password hashing functions like bcrypt, scrypt and Argon2 solve this by being deliberately slow and, for scrypt and Argon2, deliberately memory-hungry — properties that cost a legitimate login almost nothing (a fraction of a second, once) but make brute-forcing millions of candidates prohibitively expensive. They also incorporate a random salt per password automatically, which defeats rainbow tables by ensuring two users with the identical password get completely different stored hashes.

Software projects commonly publish a SHA-256 (or occasionally MD5) checksum alongside a download precisely so anyone can confirm the file they received matches what the maintainers actually built, with no relationship to secrecy at all — the checksum is meant to be public. After downloading, hash the file yourself and compare it character-by-character against the published value; any difference at all means the file was altered or corrupted somewhere between the source and your machine, and you shouldn't run it.

This is a genuinely different threat model from password hashing: here the hash is public by design, there's no secret to protect, and the entire value comes from the avalanche effect making tampering detectable. A mismatch doesn't tell you what changed or why — only that something did, which is exactly the signal you want before installing an executable you downloaded from a mirror rather than the original source.