MD5, SHA-256, and Why Hashing Isn't Encryption

The Downloaded File I Almost Didn't Verify

Late 2023. I'm downloading a Linux distro ISO—Ubuntu, nothing exciting. The mirror page shows an SHA256 checksum next to the download link. I almost skip it. Who actually checks these, right?

Two weeks later, news drops that a mirror got compromised. Attackers had replaced the ISO with a modified version containing some lovely malware. Anyone who downloaded from that mirror and didn't verify the hash... well, they had a bad time.

I happened to use a different mirror. Pure luck. But now I check hashes religiously. Takes 10 seconds. Could save you from a rootkit.

What's a Hash? (No, Not That Kind)

A hash function takes input—any input, any size—and spits out a fixed-length output. Same input always produces the same output. But you can't reverse it. Given the output, you can't figure out the original input.

MD5("hello")    → 5d41402abc4b2a76b9719d911017c592
SHA256("hello") → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c...

Change literally one character:

MD5("Hello")    → 8b1a9953c4611296a827abf8c47804d7

Completely different. This is the "avalanche effect"—tiny input changes create totally different outputs. That's what makes hashes useful for detecting modifications.

The Alphabet Soup of Hash Algorithms

MD5 — 128 bits, fast, broken. You can manufacture collisions (different inputs producing same hash) with consumer hardware. Still fine for non-security stuff like file integrity checks, but never use it for passwords or authentication.

SHA-1 — 160 bits, also broken. Google demonstrated a practical collision in 2017. Chrome started rejecting SHA-1 certificates that same year. Dead algorithm walking.

SHA-256 — 256 bits, part of the SHA-2 family. Currently the standard for most things. No practical attacks known. This is probably what you want.

SHA-3 — Different algorithm entirely (Keccak internally). Considered more "future-proof" because it's architecturally different from SHA-2. Not widely deployed yet because SHA-256 works fine and nobody's panicking.

bcrypt, scrypt, Argon2 — These are specifically for password hashing. They're intentionally slow—running them takes time on purpose to prevent brute-force attacks. If someone says they hash passwords with SHA-256, that's... technically functional but not ideal. Use the password-specific ones.

When You'll Actually Use Hashing

Verifying downloads. Hash the file you downloaded, compare to published hash. If they match, file wasn't corrupted or tampered with. If they don't match, something's wrong.

Password storage. Store hashes, not passwords. When someone logs in, hash their input and compare to the stored hash. If it matches, they're in. If your database leaks, attackers get hashes—not passwords. (Use bcrypt or Argon2 though, not raw SHA.)

Finding duplicates. Got 50,000 files and want to find duplicates? Hash them all. Same hash = same file. Way faster than comparing byte-by-byte.

Git commits. Every commit is identified by its SHA-1 hash. (Yes, that's the broken one. Git is slowly migrating to SHA-256. Slowly.)

Blockchain stuff. Every block contains a hash of the previous block. That's the "chain" part. Modifying old data would change the hash, breaking the chain. I'm not a crypto bro but the cryptography is actually clever.

Hashing Is Not Encryption

I'm going to say this louder for the people in the back: hashing is not encryption.

Encryption: reversible with the right key. Put data in, get scrambled data out. Put scrambled data + key in, get original data back.

Hashing: one-way. Put data in, get hash out. That's it. No key. No way to get the original data from the hash. You can only guess inputs and check if they produce matching outputs.

If someone tells you they "encrypted" data with MD5, they don't understand what they're doing. Run.

The Tool

Hash Generator — paste text, get MD5, SHA-1, SHA-256, and SHA-512 hashes instantly. Runs in your browser. We never see your input.

I use this mostly for verifying file checksums and occasionally generating deterministic IDs from strings (SHA-256 of a URL makes a decent unique key).

Common Screwups

MD5 for passwords. Rainbow tables exist—precomputed hashes for common passwords. MD5 without salting is instantly crackable. Use proper password hashing algorithms with salts.

Assuming hash = secure. If someone can try millions of inputs per second, they'll find matches eventually. That's why password hashes need to be slow on purpose.

Case sensitivity. ABC123 and abc123 as hex strings represent the same value. Always normalize to lowercase before comparing. I've seen bugs from this exact issue.

Ignoring the algorithm. "Verify the hash" means nothing if you don't know which algorithm was used. MD5 and SHA-256 hashes look different—MD5 is shorter. Always check.

Generate hashes now and maybe go verify that ISO you downloaded last month. Just in case.