The formula
A cryptographic hash is a function H that maps a message m of any length to a fixed-length digest:
h = H(m) h is n bits wide, no matter how big m is
That one line reads: any input, one fixed-size output. For SHA-256, n = 256, so h is 256 bits — 32 bytes — written as 64 hex characters regardless of whether m was one byte or a two-gigabyte firmware image.
The three properties that make it cryptographic — the whole point — are:
Preimage resistance: given h, you can't find any m with H(m) = h
Second-preimage resistance: given m1, you can't find m2 ≠ m1 with H(m2) = H(m1)
Collision resistance: you can't find ANY pair m1 ≠ m2 with H(m1) = H(m2)
Reading them: you can't reverse it, you can't forge a match to a specific file, and you can't even manufacture two files that happen to collide.
The work to break each is a security number, not a certainty. For an ideal n-bit hash:
Best preimage / second-preimage attack: ~ 2^n tries
Best collision attack (birthday bound): ~ 2^(n/2) tries
The birthday bound is the one that bites: because you only need any two matching outputs, collisions show up around 2^(n/2), not 2^n. That is why a 256-bit hash only buys you 128 bits of collision resistance, and why a 128-bit hash like MD5 only buys 64 — reachable on real hardware.
Where you meet it
Firmware and download verification at the bench. You pull a bootloader or an FPGA image from a vendor portal, and next to it sits a line like
SHA-256: e3b0c4.... You runsha256sumon the file you actually received. If the 64 hex characters match, the bits survived the transfer intact and nobody swapped them. If they don't, you don't flash the part.Configuration control on a review board. Every build artifact, test script, and calibration table that goes into a baseline gets a digest recorded in the release notes. Six months later, when a unit fails on the stand, the board asks "is this the exact build we qualified?" You re-hash the deployed image and compare. The digest is the tamper-evident seal on the configuration.
Signing test data and reports. A digital signature never signs the whole file — it signs the file's hash. The strain-survey CSV coming off the stand gets hashed, the hash gets signed with a private key, and anyone downstream can verify the data hasn't been edited since acquisition. Chain of custody for numbers.
Password and secret storage in your test-rig software. The web UI on your bench controller should never store the operator's password. It stores a salted hash. At login it hashes what was typed and compares. If the rig's database leaks, the attacker gets digests, not passwords — provided you used a hash built for that job (bcrypt, scrypt, Argon2), not a bare SHA-256.
How it works
Inside SHA-256, the message gets padded and chopped into 512-bit blocks. A compression function chews through them one at a time, each block stirring a running 256-bit internal state through 64 rounds of modular additions, bit rotations, and XORs. The output of the last block is the digest. That chained-block design is the Merkle–Damgård construction, the same skeleton MD5 and SHA-1 use.
The behavior you exploit is the avalanche effect: flip one bit of input and roughly half the output bits flip, unpredictably. Hash the string abc with SHA-256 and you get ba7816bf...15ad. Change the last letter to abd and you get a52d159f...49c9 — no resemblance, no partial overlap, nothing to interpolate. That is what makes the digest a fingerprint. It also means a hash tells you whether something changed, never what changed or by how much. There is no "close" — a one-bit error and a total swap look equally different.
The mistake people make is treating hashes and checksums as the same tool. A CRC-32 catches accidental line noise and is great at it, but it is trivial to construct data that hits a target CRC on purpose. A cryptographic hash resists a deliberate adversary, which is a completely different and much harder bar. Use a CRC to catch a flaky cable; use SHA-256 to catch someone who wants you to flash their firmware.
The second mistake is using a broken algorithm because it is fast and familiar. MD5 is dead for security. Its 128-bit output means the birthday bound is only 2^64, and worse, Wang and Yu demonstrated real structural collisions in 2004 — and refinements since have made finding an MD5 collision a seconds-long job on an ordinary laptop [1]. SHA-1 is dead too — the SHAttered attack in 2017 produced two different PDFs with the same SHA-1 digest [2]. Both are fine as fast non-adversarial checksums for detecting bit rot; both are unacceptable anywhere an attacker might be involved. SHA-256 and SHA-3 remain unbroken.
The limits of validity are worth stating plainly:
- A hash is not encryption. It has no key and cannot be reversed to recover the input — that is a feature, not a weakness. If you need to get the data back, you needed encryption, not a hash.
- A bare hash is not a password store. SHA-256 is deliberately fast, which helps an attacker guess billions of passwords per second. Password hashing wants a slow, salted, memory-hard function on purpose.
- A hash alone proves integrity, not authenticity. If an attacker can replace both the file and its posted digest, matching hashes prove nothing. That is why digests get delivered over a signed or trusted channel — an HTTPS page, a signature, a manifest — not sitting in the same unprotected folder as the file.
Practical note for the bench: hash the bytes you received, on the machine that will use them, and compare against the value from the vendor's trusted channel. Hashing a file and comparing it to a digest computed from that same file proves only that the file equals itself.
History
The lineage runs through one MIT cryptographer and one three-letter agency. Ronald Rivest — the R in RSA — designed a family of "message digest" functions at MIT. MD4 came in 1990 and cracked quickly under analysis, so Rivest published MD5 in 1991 as the sturdier replacement, formalized as RFC 1321 in 1992 [1][3]. For a decade MD5 was the default fingerprint of the internet: software downloads, forensic images, everything.
The NSA, meanwhile, was building the SHA line for federal use. SHA-1 arrived in 1995. Then in 2001 NIST published the draft standard adding the SHA-2 family — SHA-256, SHA-384, SHA-512 — designed by the NSA and made official as FIPS 180-2 in August 2002 [4][5]. SHA-256 is the workhorse that came out of that batch, and it is still the one on most vendor download pages today.
The cracks came fast. In 2004, Xiaoyun Wang and Hongbo Yu demonstrated practical MD5 collisions — two distinct inputs, same digest, found in under an hour [1]. That turned MD5 from "trusted" to "do not use for security" almost overnight. SHA-1's turn came February 23, 2017, when researchers at Google and CWI Amsterdam published SHAttered, the first real SHA-1 collision: two different PDF files with the identical SHA-1 hash, the product of about 9 quintillion computed hashes [2].
Anticipating exactly this, NIST had already run an open, public competition — announced in 2007 — to pick a successor built on entirely different math than the Merkle–Damgård line. In October 2012, after three rounds, the Keccak algorithm won and became SHA-3 [6]. It is not a patch on SHA-2; it is a structurally different design (a "sponge") kept in reserve so the world is never again betting everything on one construction. SHA-256 still stands unbroken, but the industry finally learned to keep a spare.
Related tools
- /tools/db-converter — decibel and ratio conversions; neighbor discrete/computation utility on the same site
- /tools/adc-resolution — bits, codes, and quantization, the closest bit-width calculator to the digest-length arithmetic here