MD5, SHA-1, SHA-256 and CRC32: Choosing the Right Hash

Checksums, fingerprints and integrity checks all use hashes, but not the same ones. Here is what each algorithm is good for and which ones you should retire.

A hash function takes input of any size and produces a fixed-size output, the digest, that changes completely if even one bit of the input changes. That simple property powers file integrity checks, Git commit IDs, digital signatures, cache keys and deduplication.

But "hash" covers very different algorithms, and picking the wrong one is a common mistake, either using something broken for security or something slow and heavy where a simple checksum would do. This guide covers the algorithms in the Hash Generator and when to use each.

What makes a good hash

A cryptographic hash function is expected to have three properties:

  • Pre-image resistance. Given a digest, you cannot find an input that produces it.
  • Second pre-image resistance. Given an input, you cannot find a different input with the same digest.
  • Collision resistance. You cannot find any two inputs with the same digest.

Collision resistance is the first to fall as an algorithm ages, and it is the one that matters for signatures and certificates.

Hashes also show the avalanche effect. Hash hello and Hello with SHA-256 and the two digests share nothing recognizable. Try it in the tool: change one character and watch the whole output change.

The algorithms

AlgorithmOutputPublishedStatus
CRC3232 bits1960s–70sError detection only, not cryptographic
MD5128 bits1992Broken for security; fine as a checksum
SHA-1160 bits1995Broken for security; being phased out
SHA-256256 bits2001Current standard
SHA-384384 bits2001Truncated SHA-512 variant
SHA-512512 bits2001Current standard, faster on 64-bit CPUs

CRC32

A cyclic redundancy check is not a cryptographic hash at all. CRCs were designed to detect accidental errors in transmission and storage, and they are very good at it, catching all burst errors up to 32 bits. You find CRC32 in ZIP archives, PNG image chunks, gzip and Ethernet frames.

What CRC32 cannot do is resist a deliberate attacker. It is linear, so it is easy to modify data and fix up the CRC to match. Use it to catch corruption, never to detect tampering.

MD5

Ron Rivest published MD5 in 1992 (RFC 1321). By 2004 researchers led by Xiaoyun Wang demonstrated practical collisions, and in 2008 a team used MD5 collisions to create a rogue certificate authority certificate. In 2012 the Flame malware used an MD5 collision to forge a Microsoft code-signing certificate.

MD5 is still everywhere for non-security purposes: checking downloads against accidental corruption, cache keys, deduplicating files, ETags. Those uses are fine, because no adversary is crafting colliding inputs. Anything involving trust, such as signatures, certificates or verifying software from an untrusted mirror, needs SHA-256.

SHA-1

SHA-1 was designed by the NSA and published by NIST in 1995. Theoretical weaknesses appeared in 2005. In 2017, Google and CWI Amsterdam announced SHAttered, two different PDF files with the same SHA-1 hash. Browsers had already stopped trusting SHA-1 TLS certificates by then.

Git historically identified objects with SHA-1, and responded to SHAttered by adding collision detection, and later support for SHA-256 repositories. NIST has announced that SHA-1 should be phased out completely by 2030.

SHA-2: SHA-256, SHA-384, SHA-512

The SHA-2 family, published in 2001 and specified in FIPS 180-4, is the current workhorse. SHA-256 secures TLS certificates, Bitcoin's proof of work, code signing, Subresource Integrity in HTML and countless file checksums.

A useful performance fact: SHA-512 works on 64-bit words and is often faster than SHA-256 on 64-bit CPUs without hardware SHA extensions. SHA-384 is SHA-512 with different initial values and a truncated output.

In the RedBison tool, the SHA family is computed with the browser's Web Crypto API (crypto.subtle.digest), the same native implementation browsers use for their own cryptography.

Choosing an algorithm

  • Integrity against attackers (signatures, release checksums, content addressing): SHA-256 or SHA-512.
  • Detecting accidental corruption in storage or transfer: CRC32 or MD5 are fine and fast.
  • Cache keys and deduplication: MD5 or SHA-256; collisions are not a realistic concern for random data.
  • Storing passwords: none of the above.

Why plain hashes are wrong for passwords

This deserves its own section because it is still a common mistake. SHA-256 is designed to be fast; a modern GPU can compute billions of SHA-256 hashes per second. If an attacker steals a table of unsalted SHA-256 password hashes, they can try every common password against every hash very quickly, or look them up in precomputed tables.

Password storage needs a function that is deliberately slow and salted: bcrypt, scrypt or Argon2. The Bcrypt Hash Generator and the bcrypt guide cover that in detail.

Why your hash does not match

You compute a SHA-256 and it differs from the one on the download page. The algorithm is almost never wrong; the input is. Hash functions operate on bytes, so anything that changes the bytes changes the hash:

  • A trailing newline. echo "hello" | sha256sum hashes hello\n. Use echo -n.
  • Line endings: Windows CRLF versus Unix LF.
  • Text encoding: UTF-8 versus UTF-16, or a byte order mark.
  • Leading or trailing spaces copied from a web page.
  • Hex case: AB12 and ab12 are the same digest written differently.

On the command line, sha256sum file (Linux), shasum -a 256 file (macOS) and Get-FileHash file (PowerShell) are the usual tools for files.

HMAC: hashes with a key

If you need to prove a message came from someone holding a secret, a plain hash is not enough, because anyone can compute it. HMAC (RFC 2104) combines a hash with a secret key. Webhook signatures from Stripe, GitHub and Slack are HMAC-SHA256 values your server recomputes and compares. Compare them with a constant-time function to avoid timing attacks.

Related tools

Launch Hash Generator