Cryptographic Hashing Algorithms Explained

What a cryptographic hash function actually does

Cryptographic hashing algorithms take an input of any size at all, a single word or an entire hard drive image, and produce a fixed-length output called a digest. Change one bit of the input and the digest changes completely and unpredictably; feed the same input in twice and the digest is always identical. That combination of determinism and unpredictability is what makes hashing useful for verifying file integrity, storing passwords, anchoring blockchain blocks, and generating digital signatures, all without ever needing to store or transmit the original input itself.

Why SHA-1 was deprecated

SHA-1 was once the workhorse cryptographic hash function across TLS certificates, Git commit identifiers and countless software integrity checks. NIST deprecated SHA-1 in 2011 after cryptanalytic research steadily eroded confidence in its collision resistance, meaning researchers found ways to generate two different inputs that produced the same digest far faster than the algorithm’s design strength implied should be possible. Collisions were later demonstrated in practice, which is exactly the failure mode that makes a hash function unsafe for anything security-sensitive, since an attacker able to engineer a collision can substitute a malicious file for a trusted one without changing its fingerprint at all.

SHA-2: the current default

FIPS 180-4 specifies the SHA-2 family: SHA-224, SHA-256, SHA-384, SHA-512, and two truncated variants, SHA-512/224 and SHA-512/256. SHA-2 processes data through the Merkle-Damgård construction, feeding fixed-size blocks through a compression function iteratively. SHA-256 in particular remains the single most widely deployed cryptographic hash function in production systems today, securing Bitcoin’s proof-of-work puzzle, TLS certificate chains, and software package integrity checks across most major operating systems and package managers in daily use worldwide right now.

SHA-3: a structurally different backup

FIPS 202 specifies the SHA-3 family, comprising four fixed-length hash algorithms, SHA3-224, SHA3-256, SHA3-384 and SHA3-512, plus two extendable-output functions, SHAKE128 and SHAKE256. Unlike SHA-2, SHA-3 uses a sponge construction built on the Keccak permutation, which absorbs input and squeezes out output through a fundamentally different internal process than Merkle-Damgård. That structural independence is deliberate: NIST standardized SHA-3 specifically so a weakness discovered in SHA-2’s construction would not simultaneously compromise every approved cryptographic hash function, giving implementers a genuinely different fallback rather than a superficial variant of the same design philosophy carried over from before.

The three properties that make a hash secure

A cryptographic hash function is only as useful as three properties holding true. Preimage resistance means it should be computationally infeasible to reconstruct the original input from its digest alone. Second preimage resistance means that given one input, finding a different input with the same digest should be infeasible. Collision resistance, the property SHA-1 lost, means finding any two different inputs that share a digest should be infeasible, even without starting from a specific target in mind. SHA-3 provides collision resistance ranging from 112 to 256 bits depending on the variant chosen, matching or exceeding SHA-2’s equivalent security levels at comparable digest sizes.

Hashing is the wrong tool for passwords alone

A common and costly mistake is treating general-purpose cryptographic hashing algorithms like SHA-256 as sufficient for storing passwords. SHA-256 is deliberately fast, which is exactly the wrong property for password storage: an attacker with a leaked database of plain SHA-256 hashes can test billions of guesses per second on modern consumer hardware. Password storage instead calls for a dedicated, deliberately slow key-derivation function such as bcrypt, scrypt, or Argon2, each of which wraps repeated hashing rounds in mechanisms that consume significant time and memory per guess, making large-scale offline cracking economically impractical even when the hash database itself has already been stolen by an attacker.

Which algorithm to use where

For most new systems, SHA-256 remains the sensible default among cryptographic hashing algorithms: it is fast, extensively battle-tested, supported natively by essentially every programming language and hardware platform, and sufficient for file integrity, digital signatures and general-purpose fingerprinting. SHA-3 is worth choosing specifically when an application benefits from its sponge-based flexibility, such as needing an extendable-output function via SHAKE, or when an organization wants deliberate cryptographic diversity alongside SHA-2 as a hedge against future cryptanalysis. What should never happen in new development is reaching for SHA-1 out of habit or legacy compatibility, since NIST’s deprecation was not precautionary, it followed real, demonstrated collision attacks that broke the trust model entirely and left no room for ambiguity about the risk involved.