Whenever you download a Linux ISO, verify a software signature, or store a password in a database, a hash function is doing the work. But “hashing” is not one thing: there are five commonly deployed algorithms (MD5, SHA-1, SHA-256, SHA-384, SHA-512) with very different security properties, and picking the wrong one for a security-sensitive task is a classic source of vulnerabilities.

What a Hash Function Does

A cryptographic hash function takes an input of any length — a single character, a 10 GB file, the entire contents of Wikipedia — and produces a fixed-size output called a digest. The same input always produces the same digest. A one-character change to the input produces a completely different digest. And given only the digest, you cannot recover the input, even with unlimited compute.

Three properties make a hash function safe to use:

  • Pre-image resistance: given a digest H, it is computationally infeasible to find any input M with hash(M) = H.
  • Second pre-image resistance: given an input M1, it is infeasible to find a different M2 with hash(M1) = hash(M2).
  • Collision resistance: it is infeasible to find any two inputs with the same digest.

When any of these properties break, the algorithm is no longer safe for security use. That is what happened to MD5 in 2004 and to SHA-1 in 2017, as we will see below.

MD5: The 1992 Default, Now Broken

MD5 (Message Digest 5) was published by Ronald Rivest in 1992 as a 128-bit hash. It became the default checksum format for the entire internet — file downloads, software distribution, version control. By 2004, a team of Chinese researchers demonstrated the first practical collision: two different inputs with the same MD5 digest. By 2008, researchers had used collision attacks to forge a valid CA certificate, undermining the trust system that HTTPS depends on.

MD5 is no longer safe for any use where an attacker might craft a colliding input. That rules out digital signatures, certificate fingerprints, and software update verification. MD5 is still fine for accidental corruption detection (catching a corrupted download), because its sensitivity to single-bit changes is unimpaired. The Hash Generator still includes MD5 because users need it to verify legacy checksums against published MD5 sums.

SHA-1: The Successor, Also Broken

NIST published SHA-1 in 1995 as a 160-bit replacement. SHA-1 was supposed to be the secure choice for the next decade. It was adopted everywhere: TLS, PGP, Git, code signing, certificate fingerprints. Then, in February 2017, Google and CWI Amsterdam announced SHAttered: the first practical SHA-1 collision, produced at a cost of roughly $110,000 of compute. They released two PDF files with different content but the same SHA-1 digest.

Git still uses SHA-1 internally for object identity, but it now includes a collision detection layer (the hash-object --literally workaround) and the project is migrating to SHA-256. Browsers have rejected SHA-1 certificates since 2017. NIST formally retired SHA-1 in 2011. The Hash Generator includes SHA-1 for completeness and for verifying older Git commit hashes, but you should not use it for new security applications.

SHA-256: The Current Standard

SHA-256 is the workhorse of modern cryptography. It produces a 256-bit (32-byte) digest, rendered as 64 hex characters. It is the hash function used in TLS 1.2/1.3, Bitcoin mining, SSL certificate signatures, code signing, software distribution (Ubuntu, Debian, Fedora, npm), and the Subresource Integrity standard that protects every CDN-loaded script on the web.

No practical collision attack has been demonstrated against SHA-256. The best known theoretical attack, published in 2011, reduces the security by roughly a factor of two relative to the 128-bit birthday bound — still 2128 operations, which is beyond the reach of any classical computer. Quantum computers would reduce security further (Grover’s algorithm gives a quadratic speedup), but the consensus is that SHA-256 will remain secure against quantum adversaries for the foreseeable future.

For new projects, default to SHA-256 unless you have a specific reason to choose otherwise.

SHA-384 and SHA-512: Stronger, Faster on 64-bit Hardware

SHA-384 is a truncated form of SHA-512: it takes the same internal state but emits only 384 bits (96 hex characters). SHA-512 produces the full 512-bit (128-character) digest. Internally, both use 64-bit operations — on a 64-bit CPU, SHA-512 is faster than SHA-256 because it processes wider chunks per round.

Is SHA-512 “more secure” than SHA-256? On paper, the answer is yes: 256 bits of pre-image security is already beyond the reach of any classical computer, but the 512-bit variant offers a deeper margin. In practice, SHA-256 is what deployment tooling supports, and changing the algorithm is rarely the cheapest way to harden a system. Use SHA-512 when:

  • You are signing long-lived documents (legal records, code-signing roots) that must remain verifiable for decades.
  • Your platform has native 64-bit SHA-512 acceleration (modern ARM and x86 CPUs include it).
  • You are matching an external protocol that mandates SHA-384 or SHA-512 (DNSSEC NSEC3, some CMS configurations).

Real-World Algorithm Choices

The decision tree, in priority order:

  1. New security application with no legacy constraint: SHA-256. The default.
  2. New security application with long retention (10+ years): SHA-512 or SHA-384. Deeper margin against future attacks.
  3. Verifying existing signatures, checksums, or Git hashes: Use the algorithm the publisher used. SHA-1 in Git is fine because Git now detects collisions.
  4. Non-security checksums (catching accidental corruption, deduplication, cache keys): MD5 is acceptable. SHA-256 is safer against malicious inputs but slower.
  5. Password storage: Never use a plain hash. Use a memory-hard KDF like Argon2id, bcrypt, or scrypt. Plain SHA-256 of "password123" is in every rainbow table.

How Hashes Are Actually Used

Hashes are everywhere because they are fast, deterministic, and one-way. Common use cases:

  • File integrity: Ubuntu publishes SHA-256 sums for every ISO. After downloading, you compute the hash locally and compare. If it matches, the file is byte-for-byte identical to the publisher’s version.
  • Digital signatures: Signing a 1 GB file with RSA is slow. Signing the SHA-256 of the file is fast, and the signature proves the file has not changed.
  • Password storage: Servers store hash(password + salt) instead of the password itself. On login, the server hashes the input and compares. A breach exposes only hashes, which are hard to reverse (with a memory-hard KDF, almost impossible).
  • Content-addressed storage: Git, IPFS, and many CDNs name files by their hash. Two identical files share one name; one tampered file has a different name.
  • Deduplication: Backup systems compute hashes of file blocks to identify identical data and store it only once.

Verifying a Hash in Practice

You can verify a file with the standard tools on every operating system:

# Linux / macOS
sha256sum ubuntu-24.04.iso

# Windows PowerShell
Get-FileHash -Algorithm SHA256 .\ubuntu-24.04.iso

# macOS (shasum is just an alias)
shasum -a 256 ubuntu-24.04.iso

Compare the output against the checksum the publisher posted. If they match — byte-for-byte hex-identical — the file is authentic. If they differ by even one character, the file is corrupted or has been tampered with. Do not skip this step for high-stakes downloads (operating system ISOs, financial software, security tooling).

Beyond SHA-2: SHA-3 and BLAKE3

Two newer algorithms deserve a mention. SHA-3 (Keccak) was standardized by NIST in 2015 after a public competition. It uses a different internal construction (a sponge, not a Merkle–Damgård compression function) and is the recommended fallback if SHA-2 ever falls to a structural attack. BLAKE3 is a 2020 hash function that is faster than SHA-256 on modern hardware (often 5–10×), parallelizable, and increasingly used in software supply chains (Rust crate registry, Solana, npm). SHA-3 and BLAKE3 are not yet exposed by the Hash Generator because browser support is uneven, but they are worth knowing about.

The Bottom Line

Use SHA-256 for new security applications. Use SHA-512 when you need a deeper margin or are on 64-bit hardware. Avoid MD5 and SHA-1 for anything security-sensitive, but use them freely when verifying existing artifacts or detecting accidental corruption. Never store passwords as plain hashes — use a memory-hard KDF. And when verifying downloads, always compute the hash locally and compare against the publisher’s published checksum.

Further Reading

  • NIST FIPS 180-4 — the Secure Hash Standard, the formal specification of SHA-1, SHA-256, SHA-384, and SHA-512.
  • NIST FIPS 202 — the SHA-3 Standard, introducing the Keccak-based sponge construction.
  • RFC 6234 — US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF).
  • SHAttered.io — the 2017 SHA-1 collision announcement and the proof-of-concept files.
  • Have I Been Pwned — the canonical service for checking whether a credential has appeared in a public breach.

Frequently Asked Questions

Which algorithm should I use for a download checksum? The publisher’s algorithm. If Ubuntu publishes SHA-256 sums, verify with SHA-256. If a legacy system publishes MD5 sums, MD5 is fine for that use case (no one is trying to forge a colliding Ubuntu ISO).

Is SHA-256 quantum-safe? A sufficiently large quantum computer running Grover’s algorithm would reduce SHA-256’s effective security to roughly 128 bits — still infeasible. For long-term post-quantum security, NIST has standardized SLH-DSA (formerly SPHINCS+) and is evaluating other hash-based signature schemes.

Why do some systems still use SHA-1? Git’s object format is frozen for backward compatibility. Older TLS certificates were signed with SHA-1 before its retirement. If you control a new system, do not introduce SHA-1.

Can two different files have the same SHA-256 hash? In theory, yes (the pigeonhole principle guarantees collisions exist), but no one has ever produced one. The expected number of files you would have to hash before finding a collision is 2128 — more than the number of atoms in the observable universe.