A hash function in cryptography is a deterministic algorithm that maps input data of any length to a fixed-length output, called a digest or hash value, in a way that is practically impossible to reverse or to forge. In cybersecurity, cryptographic hash functions underpin integrity checks, digital signatures, password storage, message authentication and many protocol designs.
The word also describes non-cryptographic hashes used in hash tables and checksums, but those are built for speed and even distribution, not for resistance against an attacker. This page concerns cryptographic hash functions, where the security properties are the whole point.
How a cryptographic hash function processes data
A cryptographic hash function compresses arbitrary input into a fixed-size digest through many rounds of mixing operations. Older designs such as SHA-1 and SHA-2 use the Merkle-Damgard construction, which pads the message, splits it into blocks and feeds each block into a compression function together with the running internal state.
SHA-3 instead uses a sponge construction based on the Keccak permutation: input is absorbed into a large internal state and the digest is squeezed out afterward. A key consequence is that SHA-3 is not vulnerable to length-extension attacks, which affect plain SHA-256 and SHA-512.
Every good hash shows the avalanche effect: changing a single input bit changes roughly half of the output bits, so similar inputs produce unrelated digests.
Security properties a hash function must provide
A cryptographic hash function is judged by three core resistance properties, each with a different attack cost. The cost depends on the digest length n, measured in bits.
| Property | Meaning | Generic attack cost |
|---|---|---|
| Preimage resistance | Given a digest, finding any matching input is infeasible | About 2 to the power n operations |
| Second-preimage resistance | Given one input, finding another with the same digest is infeasible | About 2 to the power n operations |
| Collision resistance | Finding any two inputs with the same digest is infeasible | About 2 to the power n/2 operations |
The halved cost for collisions comes from the birthday paradox. This is why a 256-bit digest gives about 128 bits of collision security, and why digest length must be roughly double the target security level. A function is considered broken when an attack is found that is meaningfully cheaper than these generic bounds.
Common hash algorithms and their status
Hash algorithms differ in digest size, internal design and current security status, and several once-standard functions are now broken. The table summarizes the algorithms most often encountered in practice.
| Algorithm | Digest size | Current status |
|---|---|---|
| MD5 | 128 bits | Broken, practical collisions exist |
| SHA-1 | 160 bits | Broken, practical collisions demonstrated |
| SHA-256 | 256 bits | Secure, the most widely deployed choice |
| SHA-512 | 512 bits | Secure, often faster on 64-bit processors |
| SHA3-256 | 256 bits | Secure, different design from SHA-2 |
| BLAKE2 and BLAKE3 | Variable, commonly 256 bits | Secure, optimized for high speed |
MD5 and SHA-1 must not be used for signatures, certificates or any purpose that depends on collision resistance. They still appear in legacy file checksums, where they detect accidental corruption but offer no protection against deliberate tampering.
Hash functions compared with other cryptographic primitives
A hash function is unkeyed and one-way, which separates it from encryption and from keyed constructions built on top of it. Confusing these primitives is a common source of design errors.
| Primitive | Uses a key | Reversible | Main purpose |
|---|---|---|---|
| Hash function | No | No | Integrity fingerprint of data |
| HMAC | Yes, shared secret | No | Authenticated integrity |
| AES encryption | Yes, shared secret | Yes, with the key | Confidentiality |
| RSA or ECDSA signature | Yes, key pair | Verifiable with the public key | Authenticity and non-repudiation |
| Password hashing function | Uses a salt | No | Slow verification of passwords |
A digital signature normally signs the hash of a message rather than the message itself, so the signature is only as strong as the hash. Key derivation and key exchange protocols also use hash-based functions such as HKDF to turn shared secrets into keys.
Choosing and applying hash functions correctly
The right hash depends on what the application must resist, and a fast general-purpose hash is the wrong tool for some tasks. The decision table below covers the most common cases.
| Task | Recommended choice | Reason |
|---|---|---|
| File integrity against tampering | SHA-256 or SHA3-256 | Strong collision resistance |
| Message authentication | HMAC-SHA-256 | Requires a secret key |
| Password storage | Argon2id, scrypt or bcrypt | Deliberately slow and salted |
| High-throughput deduplication | BLAKE3 | Very fast with strong security |
| Digital signatures | SHA-256 or stronger | Matches signature security level |
Plain hashes are unsuitable for passwords, because a modern GPU can compute billions of SHA-256 digests per second, making brute force against short passwords cheap. Dedicated password hashing functions add a unique salt and tunable memory and time cost to make each guess expensive.
Common mistakes when using hashes
Most real-world failures involving hash functions come from misuse rather than broken algorithms. The following mistakes recur in audits.
- Building a MAC as hash of key plus message, which allows length-extension forgeries with SHA-2; use HMAC instead.
- Storing unsalted password hashes, which lets attackers use precomputed tables and crack identical passwords at once.
- Comparing digests with ordinary string comparison, which can leak timing information; use constant-time comparison.
- Truncating digests too aggressively, which lowers collision resistance below the intended level.
- Treating a hash as encryption, even though anyone can recompute it for guessable inputs.
Explained without jargon
A hash function works like a fingerprint machine for data. You feed in a document, a photo or a whole program, and it produces a short code that represents exactly that input. Change even one letter and the fingerprint becomes completely different.
The machine only works in one direction. From the fingerprint alone, nobody can rebuild the original data. That makes hashes useful for checking that nothing has been altered without having to compare every byte of the original.
A typical use case
A software company distributes a 2 GB installer for its accounting application through several download mirrors. To let customers confirm they received the genuine file, the company publishes the SHA-256 digest of the installer and signs that digest with its code-signing key.
An IT administrator at a client firm downloads the installer and computes its SHA-256 value with a standard command-line tool. The digest matches the signed value exactly, so the administrator knows the file was not altered in transit or on the mirror. When one mirror is later compromised and serves a modified installer, the digest no longer matches and the tampered file is rejected before anyone installs it.