compute
guide
16 Oct 2026
Eight ways to checksum 2 GiB, and the 5.3x between two that agree exactly
sha256sum and openssl dgst produce the identical digest for the identical file. One of them took 11.05 seconds and the other took 2.09, on the same CPU, in the same shell.
By Purvansh Parmar
Checked 2026-10-21
Read 7 min
Entries 8
The advice is decades old and still repeated: if you only need a content check and not a security property, use MD5, because the cryptographic hashes are slow. I measured it on a 2 GiB file and the advice held. MD5 did 536 MB/s against SHA-256's 185, almost three times faster. Then I ran SHA-256 again through a different binary on the same machine, against the same file, producing the same digest, and it did 966 MB/s. The algorithm was never the thing being measured.
How this was checkedHashed the same 2 GiB file from page cache with eight different commands on a CPU that reports sha_ni, best of three each. The folk wisdom that MD5 is faster than SHA-256 held, at 536 MB/s against 185, right up until SHA-256 was run through openssl instead of coreutils, where it reached 966 MB/s and beat MD5 by 1.8x. Both tools print the same digest. The gap is entirely in whether the implementation reaches the instruction the processor already has.
What I compared on
- throughput in MB per second over the same cached 2 GiB
- whether the implementation uses the CPU's hash instructions
- what the output is actually good for
SHA-256 through the OpenSSL command line tool, which dispatches to a SHA-NI implementation at runtime.
Wins
Fastest thing measured, and it is a cryptographic hash, so you are not trading collision resistance for speed. On this hardware there is no reason to pick a weaker algorithm to go faster.
Loses
The output format is openssl specific, so piping it into anything that expects the coreutils layout needs a cut or an awk. It is also a larger dependency to assume in a minimal container image.
966 MB/s2.09 s5.3x faster than sha256sum
BLAKE2b through coreutils, a modern cryptographic hash designed to be fast in software without special instructions.
Wins
It is the best answer when openssl is not available: a real cryptographic hash, faster than MD5, and already in coreutils, so it needs nothing installed on any ordinary Linux box.
Loses
Still 37 percent slower than hardware accelerated SHA-256, and BLAKE2b digests are far less recognised, so anything downstream comparing against a published checksum will probably want SHA-256 anyway.
610 MB/s3.3x faster than sha256sum14 percent faster than md5sum
The same BLAKE2b algorithm through openssl rather than coreutils, as a control on the implementation question.
Wins
It is the control that proves the point. Where no special instruction exists, the two projects land within one percent of each other, so the 5.3x elsewhere is not openssl simply being a better optimised codebase.
Loses
It offers nothing over b2sum except a worse output format, and like all of BLAKE2 here it is comfortably behind accelerated SHA-256 on this processor.
603 MB/swithin 1 percent of b2sum37 percent slower than openssl sha256
The hash everyone reaches for when they want speed and have decided they do not need collision resistance.
Wins
It is universally available, every tool can parse its output, and for a non adversarial integrity check on a machine with no SHA extensions it is still a sensible default.
Loses
It is not collision resistant, and on this hardware it is not even fast: you are giving up a security property to go 1.8x slower than the accelerated cryptographic option.
536 MB/s3.82 s1.8x slower than openssl sha256
The middle option people pick when MD5 feels too broken and SHA-256 feels too slow.
Wins
There is one real use: git object names are SHA-1, so this is the tool that reproduces an identifier you already have, and nothing else here can do that.
Loses
It is the worst position on the curve: a practically broken hash that is also slower than MD5 on this machine, so it buys neither security nor speed.
462 MB/s14 percent slower than md5sum2.1x slower than openssl sha256
The 64 bit variant of SHA-2, which on 64 bit hardware is normally faster than SHA-256 in pure software.
Wins
It is the quickest SHA-2 available from coreutils, so if you are restricted to that package and want SHA-2 specifically, this is the one to pick rather than the 256 bit variant.
Loses
Being beaten 3.4x by a shorter hash of the same family is a strong argument that you should not be restricted to that package. The longer digest is rarely what anyone actually wanted.
288 MB/s1.6x faster than sha256sum3.4x slower than openssl sha256
The POSIX CRC32 checksum, the oldest and in principle the least work per byte of anything here.
Wins
Its output is a short number that fits anywhere, and for detecting accidental corruption in a pipeline on an old machine it is adequate and universally present.
Loses
This implementation does not use the hardware CRC instruction, so you get the weakest guarantee on the list at half teh speed of a real cryptographic hash. There is no scenario where it is the best choice here.
277 MB/sslower than md5sum3.5x slower than openssl sha256
The default way almost everyone computes a SHA-256 on Linux, from a script, a Dockerfile or a release checklist.
Wins
Its output is the canonical format every verification script expects, and reading a checksums file with the -c flag is a one liner that nothing else here matches.
Loses
It is leaving a 5.3x factor on the floor on any CPU with SHA extensions, which is most of them now, and it does so silently. Nothing in the output indicates you took the slow path.
185 MB/s11.05 sslowest of the eight
Side by side
| Throughput | 2 GiB | vs sha256sum |
|---|
| openssl dgst -sha256 | 966 MB/s | 2.09 s | 5.3x |
| b2sum (BLAKE2b) | 610 MB/s | 3.36 s | 3.3x |
| openssl blake2b512 | 603 MB/s | 3.40 s | 3.3x |
| md5sum | 536 MB/s | 3.82 s | 2.9x |
| sha1sum | 462 MB/s | 4.44 s | 2.5x |
| sha512sum | 288 MB/s | 7.11 s | 1.6x |
| cksum (CRC32) | 277 MB/s | 7.38 s | 1.5x |
| sha256sum | 185 MB/s | 11.05 s | baseline |
Verdict
Pipe large files through openssl dgst -sha256 rather than sha256sum and take the 5.3x for free, since the digest is identical and the only thing that changes is the output format. The wider lesson is that the question people argue about, which algorithm is fastest, is the smaller term: the same algorithm varied by 5.3x across two implementations on one machine, while the gap between MD5 and SHA-256 within one implementation was 1.8x in the other direction. Check what your CPU flags say, then check whether your tool is using them, and only then worry about the algorithm.
Sources