A hash does not come back
Encryption returns your text once you hold the key. A hash has no such key. It crushes any input, however long, into one fixed-length value, and nothing in that value lets you compute the original.
So hashes answer one question: are these two things the same? Does the file I downloaded match the value the publisher posted; does the password just typed match the one on record. If you need to hide something and read it again later, you want encryption, not a hash.
Which algorithm
- MD5 — a 1991 design. Producing two different inputs with the same hash takes seconds on a laptop. It survives only because publishers still post MD5 checksums, so you still need to check against them.
- SHA-1 — two colliding PDFs were published in 2017. There is no reason to pick it for anything new.
- SHA-256 — today’s default. Certificates, signatures and blockchains sit here.
- SHA-384 / SHA-512 — built on 64-bit operations, so on a 64-bit machine they can outrun SHA-256. Choose them when you want the longer digest.
For integrity checking, SHA-256 is enough. If the publisher only posted an MD5, compare against it — but judge separately whether the download came from somewhere you trust.
Passwords need more than this
Storing a password as SHA-256 beats storing it in the clear, and it is still a bad idea. Hash functions are built to be fast, which means an attacker tries billions per second, and every common password is already in a table.
Use a function designed to be slow: bcrypt, scrypt or Argon2. They let you dial up the cost and salt each user automatically. Don’t hand-roll one — reach for whatever your language ships.
Same file, different digest
This tool hashes the UTF-8 bytes of your input. When the result disagrees with a command-line tool, the difference is almost always invisible on screen.
- Line endings — Windows
\r\nand Unix\nare different bytes. - A trailing newline —
echoadds one by default. Tryecho -norprintf. - A BOM — some editors prepend three bytes to the file.