Nabil Haddad

I start from a distinction people collapse constantly, because nearly every bad hashing decision follows from it. A checksum detects accidental corruption. A cryptographic hash is built so that finding two inputs with the same output is computationally infeasible. CRC32 is a checksum and collides on purpose in seconds. MD5 was a cryptographic hash and stopped being one, SHA-1 followed, and both remain because file formats froze around them rather than because anyone chose them again. What you should reach for depends entirely on the job. SHA-256 covers integrity checks, content addressing and signature input. SHA-3 is a separate construction with a different internal structure and no practical break either way. Truncation matters more than people expect: SHA-256 and SHA-224 produce compatible digests, so code expecting 32 bytes and given 20 breaks in ways that are hard to trace back. Passwords are a different problem, and using a fast hash for them is the commonest mistake I see. A fast hash lets an attacker try billions of guesses per second against a stolen database. Password hashing functions are deliberately slow, take a per-password salt, and carry a work factor that can rise as hardware improves. bcrypt and scrypt are widespread; Argon2id is the current recommendation for new systems. None of this protects a password a user chose badly, which is why a length policy beats a composition rule. HMAC is the other half of my work. A plain digest proves a file has not changed; an HMAC proves the holder of a secret produced it, which is what you need when the file could have been edited by anyone with write access. Every page here names the algorithm and the mode, because a bare word hash in a header can mean half a dozen different things.