CH-J Server Managerserver management over SSH
Menu
All guides and articles →

SHA-256 vs. SHA-512 vs. BLAKE3: which checksum should you use?

How the three algorithms differ in security, speed and compatibility, what a checksum does not prove, and which to choose.

The short answer

Use the algorithm the publisher of the file gives you, because you need the same one to compare. For new work, SHA-256 is the most compatible choice and SHA-512 is a good one too. BLAKE3 is the fastest choice for your own large data, if the tool is available on every system involved. All three are considered secure today, and none has a known practical attack.

How they differ

SHA-256 and SHA-512 belong to the SHA-2 family standardised by NIST, and they are often required by compliance rules. BLAKE3 is newer and not a NIST standard, so it may not satisfy such rules. SHA-256 and BLAKE3 with default output give 256 bits, which means about 128 bits of collision resistance. SHA-512 gives 512 bits and about 256 bits of resistance. In practice both levels are far beyond what can be attacked.

Speed depends on your hardware

BLAKE3 is designed to use several CPU cores and modern vector instructions, so it usually wins clearly on large files. Between the SHA-2 variants the result varies: SHA-512 is often faster on 64-bit CPUs without special instructions, while CPUs with SHA extensions make SHA-256 faster. Measure on your own machine with a large file, because the cache and disk affect the result. b3sum may need to be installed separately.

time sha256sum large.iso
time sha512sum large.iso
time b3sum large.iso

What a checksum proves

A matching checksum shows that the file is identical to the one that the digest was calculated from. It does not show who made the file. If an attacker can change a download and the checksum on the same page, the comparison passes. To check the origin, you need a digest from a separate trusted channel or a signature, such as GPG.

sha256sum -c SHA256SUMS
gpg --verify SHA256SUMS.asc SHA256SUMS

What to avoid

MD5 and SHA-1 are broken for collision resistance and should not protect against deliberate tampering. They may still appear in old manifests, where they only detect accidental damage. Non-cryptographic functions such as CRC-32 and xxHash are built for speed and accidental errors, never for security.

Checksums in CH-J Server Manager

The Hash & Checksum module includes all three algorithms and marks SHA-256, SHA-512 and BLAKE3 as recommended and MD5 and SHA-1 as broken. It can calculate digests, compare files and check an expected value. The module cannot tell you whether the expected value itself is trustworthy, so take it from a source you trust. The app checks its own updates with SHA-512 and an OpenPGP signature together.

Detailed documentation

NIST FIPS 180-4 →

BLAKE3 specification →

Biometric unlock and security →