Cryptographic Hash Functions Explained

A cryptographic hash function takes an input of any size and produces a fixed-size output called a hash, digest, or checksum. Four key properties make hash functions useful for security:

1. Deterministic — the same input always produces the same output
2. Fast to compute — hashing is efficient in one direction
3. One-way (preimage resistant) — given a hash, it's computationally infeasible to find the original input
4. Collision resistant — it's infeasible to find two different inputs that produce the same hash

The avalanche effect means a tiny input change flips roughly half the output bits. Changing a single character in a sentence produces a completely different hash.

Each algorithm produces a different output length and has a different security status:

• MD5 — 128-bit (32 hex chars). Fast. Cryptographically broken — collision attacks are practical. Still fine for non-security checksums (file deduplication, cache keys).
• SHA-1 — 160-bit (40 hex chars). Broken — collision demonstrated in 2017 (SHAttered attack). No longer accepted for TLS certificates or digital signatures.
• SHA-256 — 256-bit (64 hex chars). Part of the SHA-2 family. Currently secure. The standard choice for digital signatures, TLS, and data integrity.
• SHA-512 — 512-bit (128 hex chars). Also SHA-2. Slightly slower than SHA-256 on 32-bit systems but faster on 64-bit hardware. Provides extra margin against future attacks.

• File integrity — download a file, compute its SHA-256, compare against the published checksum to verify it wasn't corrupted or tampered with
• Git commit IDs — every Git commit, tree, and blob is identified by its SHA-1 (moving to SHA-256) hash of its content
• Digital signatures — you sign the hash of a document, not the document itself, making signatures fast regardless of file size
• Data deduplication — store files by their content hash; identical files get the same key, saving storage
• Password storage (with the right algorithm — see next section)
• Content-addressable storage — systems like IPFS and Docker images identify content by hash

SHA-256 is the wrong choice for hashing passwords, even though it's cryptographically secure. The problem is speed — SHA-256 can compute billions of hashes per second on modern GPU hardware, making brute-force attacks trivially fast against stolen password databases.

Password hashing requires algorithms specifically designed to be slow and memory-intensive:

• bcrypt — deliberately slow, configurable cost factor, been in production since 1999
• scrypt — memory-hard, resistant to GPU attacks
• Argon2id — winner of the Password Hashing Competition, recommended by OWASP for new systems

These algorithms include a work factor you can increase as hardware gets faster, keeping brute-force attacks expensive.

A plain hash doesn't prove *who* created it — anyone can compute `SHA-256('hello')`. HMAC (Hash-based Message Authentication Code) adds a secret key to the process:

`HMAC-SHA256(key, message) = SHA-256((key XOR opad) || SHA-256((key XOR ipad) || message))`

Without the key, an attacker can't forge a valid HMAC. This makes HMAC the standard for: - API request signing (AWS Signature Version 4 uses HMAC-SHA256) - Webhook verification — GitHub, Stripe, and others send an HMAC-SHA256 signature of the payload - JWT signing (the HS256 algorithm is HMAC-SHA256) - Cookie integrity — sign session cookies so the server can detect tampering

The DevForge Hash Generator lets you compute MD5, SHA-1, SHA-256, and SHA-512 hashes from any text input in one click — useful for verifying file checksums, generating cache keys, or checking that two inputs produce identical hashes.

The HMAC Generator takes both a message and a secret key, producing a keyed signature you can use to test webhook verification logic or debug API authentication without spinning up a full server.