Hash Functions Explained: Verify File Integrity Simply

A hash function takes any input and produces a fixed-size output — SHA-256 always spits out exactly 256 bits (32 bytes) regardless of whether the input is a tweet or a 10 GB video. Change one bit of input, and roughly half the output bits flip. This one-way, deterministic property makes hashes the default tool for verifying file integrity: compute SHA-256(file) before sending, compute it again after receiving, and if the hashes match, the file arrived intact. It's how Linux distributions verify ISO downloads, how Git identifies commits, and how services like HexaTransfer confirm multi-gigabyte uploads complete without corruption.

What a hash function guarantees

Three properties define a cryptographic hash function:

• Deterministic. Same input always produces the same output. SHA-256("hello") is always 2cf24dba5fb0a30e....
• Pre-image resistance. Given a hash, you can't efficiently find an input that produces it.
• Collision resistance. You can't efficiently find two different inputs that produce the same hash.

Plus two useful behaviors:

• Avalanche effect. Changing one input bit flips roughly 50% of output bits. Makes hashes useless for searching but great for fingerprinting.
• Fixed output size. SHA-256 is 32 bytes, SHA-512 is 64 bytes, BLAKE2b is 64 bytes, regardless of input size.

Hashes are not encryption. They're one-way — you can't recover the input from the output. That's the point.

The SHA family

The Secure Hash Algorithm family, standardized by NIST in FIPS 180-4 and FIPS 202:

• SHA-1 — 160 bits, broken by Google's SHAttered attack in 2017. Don't use for security.
• SHA-2 (SHA-224, SHA-256, SHA-384, SHA-512). The workhorse of modern systems. SHA-256 dominates.
• SHA-3 (Keccak). Different construction (sponge, not Merkle-Damgård), standardized in 2015 as a hedge against SHA-2 weaknesses that haven't materialized.

SHA-256 is what TLS certificates sign, what Bitcoin mines, what Git uses (with a planned SHA-256 transition still in progress), and what file transfer services compute for integrity checks. Throughput on modern CPUs with SHA extensions: 2–4 GB/s per core.

Why MD5 and SHA-1 are dead for security

MD5 (1991) produces 128-bit hashes and was the standard until collisions were demonstrated in 2004. By 2012, the Flame malware forged Microsoft code-signing certificates using an MD5 collision attack. Today you can generate MD5 collisions in seconds on a laptop.

SHA-1 lasted longer but fell to Google's SHAttered attack in 2017, which produced two PDFs with identical SHA-1 hashes after 110 GPU-years of compute — now reproducible for under $100,000 on cloud GPUs.

Both are still fine for non-security uses: detecting accidental corruption, deduplicating storage, fingerprinting cache keys. They are not fine for digital signatures, password verification, or anything where an attacker benefits from forging a match.

BLAKE2 and BLAKE3: speed meets security

BLAKE2 (2012) and BLAKE3 (2020) offer SHA-3-level security at 2–10x the speed of SHA-256. BLAKE3 hits roughly 6 GB/s single-threaded and parallelizes linearly across cores — a 16-core machine can hit 100+ GB/s.

Adoption is growing: WireGuard uses BLAKE2s for authentication, Zcash uses BLAKE2b, and b3sum is becoming a common replacement for sha256sum in developer tooling. File transfer services that process multi-gigabyte uploads increasingly use BLAKE3 to avoid hash computation becoming the bottleneck.

Browsers don't expose BLAKE3 through Web Crypto API yet, so JavaScript implementations rely on WASM-compiled reference code at roughly 500 MB/s in the browser.

Hashes in file transfer workflows

Several places hashes earn their keep:

• Post-upload integrity check. Client computes SHA-256 during upload, server computes on arrival, mismatches trigger re-upload. S3 uses MD5 for this since speed matters more than collision resistance against passive corruption.
• Chunked upload verification. Large files split into 4 MB or 5 MB chunks; each chunk gets a hash, and a tree of hashes (Merkle tree) produces a single root hash for the whole file.
• Deduplication. If two users upload the same file, hashes match, storage stores once. Used by Dropbox's block-level dedup and CDN caching.
• Download verification. Some services display the SHA-256 on the download page so recipients can verify.
• Version identification. Git uses SHA-1 (migrating to SHA-256) for commit IDs — a file's content determines its identity.

The HMAC extension

Plain hashes can verify integrity but not authenticity — anyone can compute SHA-256(file). Adding a secret key turns a hash into a Message Authentication Code (MAC): only someone with the key can produce or verify the MAC.

HMAC (RFC 2104) is the standard construction: HMAC(key, msg) = SHA-256(key' ⊕ opad || SHA-256(key' ⊕ ipad || msg)). Used in TLS 1.2, JWTs signed with HS256, AWS request signing, and many session-cookie schemes.

For file transfer, HMAC appears in AES-GCM's authentication tag (which uses GHASH, not HMAC, but serves the same role) and in some service's API request signing.

Merkle trees: hashing at scale

For very large files or collections of files, hashing the whole thing every time is wasteful. A Merkle tree arranges hashes into a binary tree: leaves are chunk hashes, internal nodes are hashes of their children, the root hash represents the whole data set.

Benefits:

• Efficient updates. Changing one chunk only requires rehashing log(n) nodes.
• Proof of inclusion. You can prove a specific chunk is part of the root with just log(n) sibling hashes.
• Parallel computation. Branches hash independently.

Used by BitTorrent (post-v2), IPFS content addressing, Git's tree objects, certificate transparency logs, and blockchain transaction roots. File transfer services use Merkle trees for resumable uploads where partial uploads need to be verified against the original.

Passwords and hashes

An application for hashes: turning passwords into storage-safe values. Naive SHA-256(password) is insufficient — GPU farms compute billions of SHA-256 per second, so any common password falls instantly.

Password-specific hashes add computational cost:

• PBKDF2-HMAC-SHA-256 with 600,000 iterations (OWASP 2023).
• bcrypt with cost factor 12 (roughly 250 ms per hash).
• scrypt with memory hardness to resist GPUs.
• Argon2id — current best practice, memory-hard and parallel-resistant.

The goal isn't security through the hash itself — it's making each guess expensive enough that offline brute force becomes impractical for anything but weak passwords.

Verifying a download by hand

Any file you care about can be verified with command-line tools. On macOS or Linux:

shasum -a 256 ubuntu-24.04.iso

On Windows PowerShell:

Get-FileHash ubuntu-24.04.iso -Algorithm SHA256

Compare the output to the published hash on ubuntu.com. If they match, the file downloaded intact and matches what Canonical signed. If they differ, either the download corrupted or someone swapped the file.

For maximum trust, verify the signature on the hash file itself using GPG and Canonical's signing key. The multi-step chain — signed hash file → file hash → file — is how Linux distributions have maintained trust for decades.

Checking a transfer service's integrity handling

Four questions worth asking any file transfer provider:

• What hash algorithm do you use to verify uploads? (SHA-256 or BLAKE3 are fine; MD5 is tolerable for corruption checks only; silence is a yellow flag.)
• Do you surface the hash to the recipient? (Not all do, but it's nice.)
• For chunked uploads, do you Merkle-tree verify?
• Is there a way to compare hashes across endpoints?

SwissTransfer, Tresorit, Proton Drive, and HexaTransfer all compute SHA-256 during transfer and verify on arrival. Integrity failures trigger automatic re-upload of affected chunks rather than failing the whole transfer.

Putting it to work

For your next sensitive transfer: compute shasum -a 256 file.pdf before upload, save the hash, and have the recipient do the same after download. Matching hashes prove byte-for-byte integrity. It's 30 seconds of work that catches corruption, tampering, and the occasional misconfigured CDN.

Try it at hexatransfer.com — free, no account, 10 GB max.