Cryptographic hash
Also known as: hash function, cryptographic hash function, message digest
A cryptographic hash function takes any input, such as a password, file, or message, and produces a fixed-length string of characters, often called a hash or digest, that acts like a digital fingerprint.
The same input always gives the same hash, but even a tiny change produces a completely different result, and you can't work backward from the hash to the original. While hashes underpin password storage, file integrity checks, digital signatures, and blockchains, older algorithms such as MD5 and SHA-1 are now broken and shouldn't be used for security.
Cryptographic hash, explained at three levels
At home
A hash is like a fingerprint for data. A hash function reads a file, message, or password and produces a short code that is always the same length. The same data always gives the same fingerprint, but changing even one letter gives a completely different one, and you can't rebuild the original from the fingerprint. That lets you check a download is genuine by comparing fingerprints.
At work
A cryptographic hash turns any data into a short, fixed-length fingerprint that changes completely if even one character changes and can't be reversed. Businesses rely on hashes to confirm software and files haven't been tampered with, to store passwords without keeping the passwords themselves, and as a building block for digital signatures. Old algorithms such as MD5 and SHA-1 are broken and should be replaced.
At home
A hash function reads any amount of data and produces a short fingerprint, always the same length. Change a single letter in the input and the fingerprint changes completely. That makes hashes useful for checking files: a download page lists the file's SHA-256 hash, and you can calculate the hash of what you downloaded. If the two match, the file is exactly what the publisher released. If even one bit changed, they will not match.
At work
A cryptographic hash must resist three things: finding an input from its output, finding a second input with the same output as a given one, and finding any two inputs that collide. SHA-256 and SHA-3 meet these today, while MD5 and SHA-1 have practical collision attacks. Fast hashes are wrong for passwords because attackers can test billions of guesses per second, so password storage uses deliberately slow, salted algorithms such as bcrypt, scrypt or Argon2.
At home
Hashing is often confused with encryption, but they solve different problems. Encryption scrambles data so someone with the key can turn it back. A hash is one-way: there is no key, and no way to rebuild the original. Websites hash your password, then hash whatever you type at login and compare the two. In my view, mixing these up is one of the most common misunderstandings in security, and it leads to bad advice.
At work
Hashes underpin digital signatures, which sign a digest rather than the whole message, as well as code signing, certificate transparency, Git commits and software supply-chain attestations. Use HMAC when a hash must also prove who created it, since a plain hash can be recomputed by anyone. Retire MD5 and SHA-1 everywhere security depends on collision resistance, and design for crypto agility so algorithms can be swapped. Length-extension attacks affect SHA-256 in naive constructions, another reason to use HMAC.
Real-world examples
At home
Thomas downloaded a Linux installer and compared its SHA-256 hash with the one on the official website. They matched, so he knew the file hadn't been tampered with.
At work
Lena is a security engineer at an Ottawa software firm. She replaced an old MD5-based file integrity check with SHA-256 after an audit flagged MD5 as broken.
How it compares
| feature | Cryptographic hash | Encryption (beginner version) |
|---|---|---|
| Reversible | No | Yes, with the key |
| Output size | Fixed length | Similar to input size |
| Main use | Integrity and password storage | Keeping data confidential |
| Needs a key | No | Yes |
Hashing proves data is unchanged. Encryption keeps data secret.
For analysts
I'd ask any software vendor how they store passwords. If the answer is MD5, SHA-1, or plain SHA-256 without salting and slow hashing, that's a red flag.
History & origin
Hash functions were studied in computer science from the 1950s, and cryptographic versions developed in the late 1970s and 1980s. Ron Rivest designed MD5 in 1991, and the US National Security Agency designed SHA-1, published in 1995. In 2004, Chinese researcher Wang Xiaoyun and colleagues demonstrated practical collisions in MD5, meaning two different inputs could produce the same hash. In 2017, Google and the CWI institute in Amsterdam announced 'SHAttered,' the first practical SHA-1 collision. The SHA-2 family, published in 2001, became the standard, and SHA-3, selected through a public competition, was standardized in 2015. In my view, the slow death of MD5 and SHA-1 shows that cryptography ages, and systems need to be ready to swap algorithms.