Comparing Hash Algorithms: Security Margins, Speed and the Keccak Trap

How digest size maps to real security, why MD5 and SHA-1 fell, when SHA-512 beats SHA-256, and why a library called SHA3 may not give SHA-3 output.

2026-10-24 · 6 min read

Hash the three bytes abc with eight algorithms and you get eight hex strings between 32 and 128 characters long. The lengths look like the only difference, and longer looks safer. That instinct is half right. Output size sets a ceiling on security, but MD5 and SHA-1 fell far below their ceilings, SHA-512 is not always slower than SHA-256, and a function a library calls "SHA3" may not produce SHA-3 output at all.

This article compares the algorithms in the Hash Algorithm Comparison tool on the things that decide which one you should use: how much security each digest size actually buys, which ones are broken and how, what the speed numbers mean, and the naming trap around Keccak. For a gentler introduction to what hashes are for, read the hash generator guide first.

Digest size and the birthday bound

A hash with an n-bit output has two security levels, not one.

• Preimage resistance (given a digest, find an input that produces it) costs about 2^n attempts by brute force.
• Collision resistance (find any two inputs with the same digest) costs only about 2^(n/2), because of the birthday paradox. In a room of 23 people there is a better than even chance that two share a birthday, even though there are 365 possible days. Collisions are found the same way: generate digests and wait for any two to match.

So the useful number for signatures and certificates is half the output size.

The hex column is just bits divided by four, since each hex character carries four bits. The tool's Hash Length figure shows those character counts, which is a quick way to identify an unlabelled digest: 32 characters is almost always MD5, 40 is SHA-1, 64 is SHA-256.

How MD5 and SHA-1 broke

An algorithm is "broken" when an attack beats the birthday bound by a practical margin. Both MD5 and SHA-1 were broken by cryptanalysis of their internals, not by brute force.

MD5 (RFC 1321, 1992) fell in 2004, when Xiaoyun Wang and colleagues published collisions that took hours on ordinary hardware. By 2008 researchers had used MD5 collisions to forge a certificate authority certificate, and in 2012 the Flame malware used one to fake a Microsoft code-signing certificate. Today an MD5 collision takes seconds on a laptop.

SHA-1 (1995) was weakened on paper in 2005. In February 2017, Google and CWI Amsterdam published SHAttered: two different PDF files with the same SHA-1 digest, at a cost of roughly 2^63 operations. In 2020 Gaëtan Leurent and Thomas Peyrin showed a chosen-prefix collision, the kind that lets an attacker forge certificates and PGP keys, for about US$45,000 of GPU time.

Neither break helps an attacker reverse a digest or find an input that matches your existing file (a second preimage). That is why MD5 and SHA-1 still work as checksums against accidental corruption, cache keys and deduplication inside one trusted system. They are not acceptable anywhere an attacker can choose inputs: signatures, certificates, content addressing across trust boundaries, or integrity checks on downloads.

The SHA-2 family and length extension

SHA-224, SHA-256, SHA-384 and SHA-512 are all SHA-2, published by NIST and specified in FIPS 180-4. SHA-256 works on 32-bit words and 64-byte blocks; SHA-512 works on 64-bit words and 128-byte blocks. SHA-224 and SHA-384 are the same functions with different starting constants and a truncated output.

Truncation matters for one specific attack. MD5, SHA-1, SHA-256 and SHA-512 are Merkle-Damgård constructions: the digest is the internal state after the last block. If a system computes hash(secret + message) as a signature, an attacker who knows the digest and the length of the secret can append data and compute a valid digest for secret + message + padding + extra without knowing the secret. This length-extension attack has hit real APIs, including Flickr's in 2009.

SHA-384 discards 128 bits of state, so the attacker cannot resume from the output. SHA-224 discards only 32 bits, which can be guessed. SHA-3 is immune by design. The real fix for all of them is not to build a MAC by hand: use HMAC, which is safe with any of these hashes.

Speed: what the timings mean

The tool times each algorithm over 1 to 100 runs and reports the average or a P50, P95 or P99 percentile. A quick experiment:

1. Pick File Content as the Data Type and set Iterations to 100.
2. Set Statistical Metric to P50 and click Compare Hash Algorithms.
3. Run it again with P99 and compare.

You will see that P50 is steady from run to run while P99 jumps around. Microsecond timings in a browser are dominated by noise: JIT warm-up, garbage collection and deliberate timer coarsening that browsers apply to limit timing attacks. Use the median for comparisons and ignore differences under a few microseconds.

Also remember what is being timed. The tool uses crypto-js, a pure-JavaScript library. Native code behaves differently:

• On 64-bit CPUs without hardware SHA instructions, SHA-512 often hashes long inputs faster than SHA-256, because it moves twice as many bytes per round.
• On CPUs with SHA extensions (many recent Intel and AMD chips, and ARMv8), SHA-256 is hardware-accelerated and usually wins.
• MD5 and SHA-1 are fast everywhere, which is part of why they were popular.

For passwords, speed is the enemy. None of these functions is suitable on its own; use a deliberately slow, salted function. The bcrypt guide explains why, and the Bcrypt Hash Generator lets you try cost factors.

The Keccak trap

NIST ran an open competition for a new hash standard from 2007 to 2012, and Keccak won. When NIST published SHA-3 as FIPS 202 in August 2015, it changed the padding rule: SHA-3 appends domain-separation bits before the usual Keccak padding. Same permutation, same security, different output.

Some libraries were written against the original submission and never updated. crypto-js is one of them: its SHA3() function returns Keccak output. Ethereum also standardised on original Keccak-256 before FIPS 202 existed, which is why Solidity's keccak256 does not match sha3-256 in OpenSSL or Python's hashlib.

The empty string shows the difference:

Keccak-256("")  c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470
SHA3-256("")    a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a

That is why the comparison tool labels its row Keccak-512, not SHA-3. If a digest from your code does not match a published SHA-3 test vector, check which padding your library implements before debugging anything else.

Choosing, in practice

• New systems, general integrity and signatures: SHA-256. It is everywhere, hardware-accelerated and has a 128-bit collision margin.
• Larger margin or truncation for length-extension safety: SHA-384 or SHA-512/256.
• A different design as a hedge: SHA-3 or BLAKE2/BLAKE3 from a native library.
• Interoperating with legacy formats: MD5 or SHA-1 only where the format demands it, and never for trust decisions.
• Passwords: bcrypt, scrypt or Argon2, never a plain hash.

To check a downloaded file against a published checksum, use the Hash File Verifier; for one-off digests of text, the Hash Generator is quicker. When you compare outputs between tools, hash the exact same bytes: a trailing newline or a CRLF line ending changes every digest, and it is still the most common reason two "identical" hashes disagree.

Open the Hash Algorithm Comparison