#️⃣ Hash Generator (MD5/SHA)

What Cryptographic Hash Functions Actually Do — And Why Four Algorithms Are Still in Circulation

A hash function takes an arbitrary blob of data — a password, a contract PDF, a 4 GB disk image — and collapses it into a fixed-length string of hexadecimal digits. That output, the digest, has a few mathematically useful properties: it's deterministic (same input always yields the same digest), it's one-way (you cannot reverse the digest back into the original data), and it's avalanche-sensitive (flip a single bit in the input and roughly half the output bits change). These three properties together are what make hashes foundational to security, data integrity, and systems engineering.

Four algorithms dominate real-world use: MD5, SHA-1, SHA-256, and SHA-512. They differ in digest length, computational cost, collision resistance, and which decade they peaked. Understanding why all four still exist — and when each one belongs — saves you from both under-engineering and over-engineering your next project.

MD5: 128 Bits, 1991, and a Legacy That Won't Quit

Ron Rivest designed MD5 in 1991 as a faster replacement for MD4. The algorithm processes input in 512-bit blocks, applies four rounds of bitwise operations, and produces a 128-bit digest — 32 hex characters. For most of the 1990s it was treated as cryptographically strong. That changed in 2004 when Xiaoyun Wang's team demonstrated a practical collision attack, and again in 2008 when researchers forged a rogue CA certificate by exploiting MD5 collisions.

MD5 is not safe for digital signatures, certificate fingerprinting, or password storage. But it is still reasonable for non-security purposes: checksumming a downloaded file where the hash was transmitted over the same channel (so collision attacks are irrelevant because an attacker would need to replace both), verifying data integrity inside a trusted pipeline, or keying a cache where collisions just cause a miss rather than a vulnerability. The reason it survives is speed — MD5 can hash several gigabytes per second on modern hardware, making it attractive for bulk integrity checks where an adversary isn't in the picture.

SHA-1: NIST's 1995 Design and Its 2017 Collapse

The NSA designed SHA-1 for NIST, and it was standardized in 1995. It produces a 160-bit digest — 40 hex characters — using a Merkle-Damgård construction with Davies-Meyer compression. For over a decade it was the workhorse of TLS, Git, PGP, and code signing.

In 2017, Google's CWI Amsterdam team published SHAttered: the first public SHA-1 chosen-prefix collision, produced in roughly 6,500 CPU years and 110 GPU years. They generated two different PDF files with identical SHA-1 digests. Browser vendors had already begun dropping SHA-1 TLS certificates a year earlier. Git controversially took years longer to migrate, with SHA-256 support landing only in Git 2.29 in 2020 (and still not the default as of now).

SHA-1 lingers in legacy systems, older VPN implementations, and HMAC contexts where pre-image resistance (not collision resistance) is what matters — HMAC-SHA1 is still considered secure for message authentication when keys are secret, because the attack surface is different from free collision search. But new systems should not start with SHA-1.

SHA-256: The Modern General-Purpose Standard

SHA-256 is part of the SHA-2 family, designed by the NSA and published by NIST in 2001. The "256" refers to the digest length in bits — 64 hex characters. It uses eight 32-bit working variables, 64 rounds of compression, and constants derived from the cube roots of the first 64 primes. No practical attack is known against SHA-256's collision resistance or pre-image resistance.

SHA-256 is the right default for almost everything security-sensitive today: TLS 1.3 certificates, Docker image layer digests, Git SHA-256 repositories, S3 content addressing, JWT signatures, and Bitcoin's proof-of-work (which chains two SHA-256 passes). It produces digests small enough to embed in URLs and database columns without significant overhead, yet large enough that birthday attacks require about 2^128 operations — computationally infeasible with current and foreseeable hardware.

On modern x86-64 CPUs with SHA-NI instructions (Intel Ice Lake and later, AMD Zen 2 and later), SHA-256 runs at hardware speed: typically 3–6 GB/s, fast enough to hash a typical file in microseconds.

SHA-512: When You Need the Extra Headroom

SHA-512 extends the SHA-2 family using 64-bit working variables (instead of 32-bit) and 80 rounds, producing a 512-bit digest — 128 hex characters. On 64-bit processors it often runs faster than SHA-256 per byte because the 64-bit operations allow processing twice as many bits in similar clock cycles. This counterintuitive result means SHA-512 can be the better choice for large file hashing on 64-bit hardware.

SHA-512 provides a much larger security margin than SHA-256 — the birthday bound sits at 2^256 operations, well beyond any plausible quantum computing threat even accounting for Grover's algorithm, which squares the cost of brute-force search and effectively halves the security level in bits. For long-term archival integrity (documents expected to remain secure for 50+ years), or for password hashing schemes like PBKDF2 where you can pick any underlying PRF, SHA-512 gives extra insurance against cryptanalytic improvements that haven't been discovered yet.

How the Browser Computes These Client-Side

Modern browsers expose SHA-1, SHA-256, and SHA-384 through the SubtleCrypto API (crypto.subtle.digest()), which is available in all contexts with a secure origin (HTTPS or localhost). The call is asynchronous and returns a Promise that resolves to an ArrayBuffer — you then iterate the bytes and format them as hex. SHA-512 is also supported via the same API.

MD5, however, is explicitly excluded from Web Crypto because the W3C wanted the API to contain only algorithms considered cryptographically sound. This means any tool that wants to compute MD5 in the browser must implement it in pure JavaScript, which is entirely feasible — the RFC 1321 reference implementation translates directly and the algorithm's simplicity means a pure-JS version runs fast enough for text and moderate-sized files without noticeable delay.

The performance boundary worth knowing: SHA-256 on a typical laptop browser can comfortably handle files up to a few hundred megabytes. Very large files — multi-gigabyte video archives — can take several seconds in JavaScript but won't freeze the UI if the arrayBuffer() read and digest call are awaited rather than blocking the main thread.

Practical Situations Where You Actually Need to Choose

Choosing between these four comes down to three questions: Is the output security-sensitive? How large is the input? What does the receiving system expect?

For checksum verification of downloaded software, use whatever the upstream publisher specifies — SHA-256 is most common now, with SHA-512 used by some security-focused projects. For file deduplication in a storage system you control with no adversarial input, MD5 or SHA-1 are fine and save storage on the digest column. For digital signatures or certificate fingerprinting, SHA-256 minimum, SHA-512 if the platform supports it. For password hashing, none of these raw algorithms are appropriate — use bcrypt, scrypt, or Argon2, which are purpose-built to be slow and memory-hard. For HMAC message authentication, HMAC-SHA-256 is the standard choice; HMAC-SHA-512 provides more margin at a small cost.

The hex digest you see in a hash tool output is the raw algorithm output, not encoded or compressed further. The same string you compute locally for a file should match exactly what the file author published — if it doesn't, either the file was corrupted in transit, altered intentionally, or you computed the hash of the wrong data (wrong encoding, extra newline, different file). That exact match is the entire point.