Hashing, encryption and encoding

Encoding, encryption and hashing get used interchangeably in conversation and they are not interchangeable at all. Each solves a different problem, and picking the wrong one is how credentials end up readable in a breach.

Three jobs, three tools

The "reversible" column is the one that matters. If you need the original back, hashing is wrong. If you need it kept secret, encoding is wrong. Most mistakes are one of those two.

Encoding: making data portable

Encoding changes how data is represented so it survives a channel that would otherwise mangle it. There is no key and no secret — the transformation is public and anyone can undo it instantly.

Base64 is the common one: it re-expresses binary using 64 text-safe characters so an image can travel inside an email. Percent encoding does the same job for URLs, turning a space into %20. The text to binary converter shows the same principle at the bit level, and the number base converter moves between hex, octal and decimal.

Encoding provides zero security. Base64-ing a password is equivalent to writing it backwards. This is worth repeating because it appears in real production systems: HTTP Basic authentication sends credentials as Base64, which is exactly why Basic auth over plain HTTP is unsafe. Our guide to what Base64 is covers this in detail.

Encryption: making data secret

Encryption transforms data so that only someone with the key can read it. Take the key away and the ciphertext is useless.

Two families. Symmetric encryption uses the same key to encrypt and decrypt — AES is the standard, and it is what the file encryptor uses in AES-GCM mode, deriving the key from your passphrase with PBKDF2 so a weak passphrase costs an attacker time. Asymmetric encryption uses a public key to encrypt and a private key to decrypt, which is what makes HTTPS and signed messaging possible without sharing a secret in advance.

The critical property: encryption is only as strong as key management. AES-256 has never been broken, but that is irrelevant if the passphrase is summer2024 or if the key sits in the same folder as the file. Test a passphrase with the password strength checker before you rely on it, and remember that a passphrase used with a file encryptor cannot be recovered — lose it and the data is genuinely gone.

Hashing: making data verifiable

A hash function turns any input into a fixed-length fingerprint. SHA-256 always produces 256 bits, whether you feed it one character or a gigabyte.

Three properties make it useful:

• Deterministic — the same input always gives the same hash.
• One-way — you cannot work backwards from the hash to the input.
• Avalanche — changing one bit of input changes roughly half the output bits, so similar inputs give completely unrelated hashes.

That last property is what makes hashes good for verification. Download a file, hash it with the hash generator, compare against the published value: if a single byte was corrupted or tampered with, the hashes will not resemble each other at all.

Because hashing is one-way, it is not storage. There is no "decrypting" a hash. If you need the data back, you needed encryption.

Is MD5 broken? It depends what for

"MD5 is broken" is repeated everywhere and is only half true. It matters which property broke.

MD5 is collision-broken: it is computationally cheap to construct two different inputs with the same MD5. This kills it for anything adversarial — digital signatures, certificates, deduplicating files an attacker controls. Real attacks have used this, including the Flame malware forging a Microsoft signature.

MD5 is not preimage-broken: given a hash, you still cannot practically find an input that produces it. So MD5 remains perfectly serviceable for detecting accidental corruption — a truncated download, a bad disk, a botched transfer. That is why so many projects still publish MD5 checksums, and why the MD5 and CRC32 tool exists.

The rule: MD5 and CRC32 for accidents, SHA-256 for adversaries. CRC32 is not even a cryptographic hash — it is an error-detecting code, fast and fine for spotting a flipped bit, trivially forgeable by anyone trying.

SHA-1 sits in the same category as MD5 and has been collision-broken since 2017. Use SHA-256 unless something forces your hand.

Why password hashing is its own thing

Here is the twist that catches competent engineers: SHA-256 is the wrong choice for passwords, and for an unexpected reason. It is too fast.

A general-purpose hash is designed for speed. That is a virtue when verifying a download and a disaster when storing passwords, because an attacker with a stolen database can try billions of guesses a second against a fast hash.

Password hashing needs functions deliberately built to be slow and memory-hungry: bcrypt, scrypt or Argon2. These have a tunable work factor, so you can make each guess cost milliseconds — imperceptible for one login, ruinous for an attacker making billions.

They also apply a per-user salt, a random value mixed in before hashing. Without it, identical passwords produce identical hashes, and attackers precompute rainbow tables once and crack everybody at once.

Since you cannot know which sites did this properly, assume none of them did — that is the assumption the password strength checker makes when it estimates crack times, and it is why length matters more than complexity.

Pikkit has the encoding, hashing and encryption tools, all running in your browser with nothing uploaded.