How SHA-256 Hashing Works (And Why It Cannot Be Reversed)

SHA-256 is a member of the SHA-2 (Secure Hash Algorithm 2) family, designed by the United States National Security Agency (NSA) and published by NIST in 2001. It takes an input of any length — a single character, a 10 GB file, or an entire database — and produces a fixed-length 256-bit (32-byte) output called a digest, hash, or checksum.

The same input always produces the same output. Changing even a single bit of the input produces a completely different output. These properties make SHA-256 suitable for a wide range of security applications where you need to verify data integrity without storing the data itself.

Properties of a Cryptographic Hash Function

A secure cryptographic hash function must satisfy four properties. SHA-256 satisfies all of them:

• Deterministic: The same input always produces the same output. SHA-256("hello") always equals 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824.
• One-way (preimage resistant): Given a hash output, it is computationally infeasible to reconstruct the original input. There is no inverse function.
• Avalanche effect: A tiny change in input causes a completely different output. SHA-256("hello") and SHA-256("hello!") share no visible similarity.
• Collision resistant: It is computationally infeasible to find two different inputs that produce the same hash output. For SHA-256, no practical collision has ever been found.

How SHA-256 Processes Input

SHA-256 processes input in 512-bit (64-byte) blocks. If the input is not a multiple of 512 bits, padding is added: a single 1 bit, followed by enough 0 bits to bring the message to 448 bits mod 512, followed by a 64-bit representation of the original message length. This is called Merkle-Damgård padding.

The algorithm maintains an internal state consisting of eight 32-bit words, initialized to specific constants derived from the fractional parts of the square roots of the first eight prime numbers. For each 512-bit block, the algorithm runs a compression function that mixes the block data with the current state through 64 rounds of operations involving rotations, XOR, AND, and addition modulo 2^32.

After all blocks are processed, the final internal state — eight 32-bit words — is concatenated to produce the 256-bit output. The specific constants and operations used in the compression function ensure that the output is highly sensitive to every bit of input.

Why SHA-256 Cannot Be Reversed

SHA-256 is irreversible by design, not by accident. The compression function deliberately discards information. In each round, multiple input bits are combined through non-linear operations (AND, XOR, rotations) that produce fewer output bits than they consume. The function is a many-to-one mapping: many different inputs can produce the same intermediate state.

To reverse SHA-256, you would need to invert these non-linear operations and work backward through 64 rounds for each block. The XOR operation alone is not invertible when inputs are unknown — if A XOR B = C and you know C but not A or B, there are infinitely many valid (A, B) pairs. This mathematical irreversibility is what makes SHA-256 a one-way function.

The Avalanche Effect in Practice

The avalanche effect means that SHA-256 hashes provide no information about how similar two inputs are. Two files that differ by one byte have completely unrelated hashes. This makes SHA-256 unsuitable for detecting "close matches" but ideal for verifying exact matches.

SHA-256("hello")
= 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

SHA-256("hello!")
= ce06092fb948d9ffac7d1a376e404b26b7575bcc11ee05a4265fde6e4d1e6110

Common Use Cases

File Integrity Verification

Software distributors publish SHA-256 checksums alongside download files. After downloading, you compute the SHA-256 of the downloaded file and compare it to the published checksum. Any corruption during download or tampering by a man-in-the-middle produces a different hash, detecting the modification immediately.

Password Storage

Databases should never store plaintext passwords. Instead, they store the hash of the password plus a random salt. On login, the server hashes the submitted password with the stored salt and compares to the stored hash. If the database is compromised, attackers get hashes, not passwords — and reversing the hashes is computationally infeasible.

However, plain SHA-256 is too fast for password hashing. An attacker with a GPU can compute billions of SHA-256 hashes per second, making brute-force attacks practical for common passwords. Use dedicated password hashing algorithms — bcrypt, Argon2, or scrypt — for passwords. These are deliberately slow and memory-intensive to resist GPU attacks.

Digital Signatures and Certificates

TLS certificates, code signing, and document signatures all use SHA-256 as the hash component. To sign a document, you compute its SHA-256 hash and encrypt the hash with your private key. Verifiers decrypt the signature with your public key and compare the result to their own SHA-256 computation of the document. This is far more efficient than signing the entire document.

Blockchain and Proof of Work

Bitcoin's proof-of-work consensus mechanism applies SHA-256 twice to block headers. Miners search for a nonce value that makes the double-SHA-256 output start with a required number of leading zeros. Because SHA-256 is unpredictable (small input changes produce completely different outputs), the only way to find a valid nonce is to try billions of values, requiring massive computation.

SHA-256 vs Other Hash Algorithms

• MD5 (128 bits): Broken for collision resistance since 2004. Do not use for security. Still acceptable for non-security checksums (detecting file corruption, not tampering).
• SHA-1 (160 bits): Collision attacks demonstrated in practice (SHAttered attack, 2017). Deprecated for all security uses. Browsers reject TLS certificates signed with SHA-1.
• SHA-256 (256 bits): Current standard. No practical attacks known. Used in TLS, code signing, Bitcoin, and most modern security protocols.
• SHA-384 / SHA-512 (384 / 512 bits): Larger outputs from the SHA-2 family. Marginally more secure against length extension attacks. Used where extra security margin is required.
• SHA-3 (variable): Completely different internal design (Keccak sponge construction). Resistant to length extension attacks by design. Alternative to SHA-2, not a replacement driven by SHA-2 weakness.

Length Extension Attacks and HMAC

SHA-256 has a subtle vulnerability: length extension attacks. If you know SHA-256(secret || message), you can compute SHA-256(secret || message || extra_data) without knowing secret. This makes naive MAC construction (SHA-256(secret || data)) insecure.

HMAC (Hash-based Message Authentication Code) is the correct way to use SHA-256 for authentication. HMAC applies a defined construction — HMAC(key, data) = SHA-256(key XOR opad || SHA-256(key XOR ipad || data)) — that is not vulnerable to length extension attacks. Always use HMAC-SHA-256, not bare SHA-256, when you need to authenticate data with a key.