Cryptographic Hash Function

Why it matters

File integrity checks, malware IOC matching (a known-bad file's SHA-256), digital signatures, DKIM, SRI, Git commits, certificate fingerprints and TLS all lean on this one primitive. But "cryptographic hash" is not one uniform guarantee. MD5 (1992) and SHA-1 (1995) are both broken for security purposes — practical collision attacks exist for both (MD5 since 2004, SHA-1 since SHAttered in 2017, chosen-prefix since 2020) — while SHA-256 and the rest of SHA-2, and the SHA-3 family, remain sound. Seeing MD5 or SHA-1 used for anything security-relevant today — signatures, integrity of downloads, certificate fingerprints — is a finding, not a neutral implementation detail. (Using MD5 as a plain lookup key or a cache name where nobody can choose the input is fine; the property you need there is only speed.)

The three properties, and a common misreading

• Pre-image resistance — given a digest, you cannot find an input that produces it. This is what protects a leaked hash (of anything with enough entropy).
• Second pre-image resistance — given one input, you cannot find a different input with the same digest. This is what makes a published checksum meaningful.
• Collision resistance — you cannot find any two inputs with the same digest. This is the property MD5 and SHA-1 lost, and it is enough to forge signatures when the attacker controls both documents.

Digest sizes: MD5 128 bits (32 hex characters), SHA-1 160 (40), SHA-256 256 (64), SHA-512 512 (128), SHA3-256 also 64 hex. The length identifies the family but not the algorithm — SHA-256, SHA3-256 and BLAKE2s all produce 64 hex characters.

The misreading: "hashing" the general concept and "hashing passwords" are not interchangeable. A general-purpose hash such as SHA-256 is fast by design — ideal for checking a download against its published checksum, actively wrong for password storage, where fast is exactly what you do not want. Passwords need bcrypt, Argon2 or scrypt. And a hash alone does not authenticate: if the attacker can change the file, they can change the published checksum next to it; that needs a signature or an HMAC with a key.

Common misreadings

• Hashing is not encryption. There is no key and no way back; "we hash the data so it can be recovered later" is a design error.
• A hash of an IP address is still personal data. With four billion possible inputs, the pre-image is trivially brute-forced; hashing does not anonymise low-entropy values.
• Two files with the same MD5 are not necessarily the same file — and a malware author can make sure of it. Use SHA-256 for IOCs and expect feeds to carry both.

Related terms

• bcrypt — bcrypt is a password-hashing algorithm designed to be slow on purpose, so that even if a database of hashes leaks, brute-forcing the original passwords is expensive at scale.
• Salt — A salt is random data mixed into a value before it is hashed, so two identical inputs (two users with the same password) produce different hashes — which defeats precomputed "rainbow table" lookups; bcrypt and Argon2 generate and store it inside the hash automatically.
• IOC — An IOC is a piece of forensic evidence — a file hash, an IP address, a domain, a registry key, a mutex — whose presence on a system or in traffic indicates that a known intrusion has occurred.
• SRI — SRI (Subresource Integrity) is an HTML attribute that lets the browser verify a script or stylesheet loaded from a third party — a CDN — has not been altered, by checking it against a cryptographic hash you embed in the tag.
• DKIM — DKIM is a cryptographic signature a mail server adds to each outgoing message, verifiable through a public key published in DNS, proving the message was authorised by the signing domain and not altered in transit.