FAQ

A deterministic function that maps any-length input to a fixed-length output. Given the same input it always returns the same output, and any change in the input should produce an unpredictable change in the output. See the glossary for the formal properties (preimage / second-preimage / collision resistance).

A cryptographic hash has a security goal against an adversary: finding a collision should be computationally infeasible. Non-cryptographic hashes (MurmurHash, xxHash, FNV) optimize for speed and distribution and assume no adversary; an attacker who knows the algorithm can construct collisions easily. Use cryptographic hashes for integrity, signatures, and content addressing; non-cryptographic ones for hash tables, Bloom filters, and sketches.

No. SHA-256 has no practical collision or preimage attack. The best published cryptanalysis covers heavily reduced-round variants. The only real caveat for new designs is length-extension: if you use raw SHA-256(key || message) as a MAC, an attacker can forge digests for extensions of the message. Use HMAC-SHA-256, SHA-3, or BLAKE2/3 instead.

Because real-world software is huge and slow to migrate. MD5 collisions are trivial, so MD5 cannot be used where an attacker might submit inputs. But for accidental corruption checks (file checksums on mirror sites, package lockfiles, content-addressed caches with trusted sources) it still works fine. The right move for any new system is to skip MD5 entirely; the right move for legacy systems is to plan a migration.

For collision resistance, yes , chosen-prefix collisions are practical (Shambles, 2020). For preimage resistance it is still out of reach. HMAC-SHA-1 has no known practical attack and is still deployed in older TLS / OAuth / OTP systems. New designs should pick a SHA-2 or SHA-3 variant; existing HMAC-SHA-1 deployments can be rotated over time without urgency.

Both are standardized (NIST FIPS 180-4 and FIPS 202). SHA-2 is faster on most CPUs and has hardware acceleration. SHA-3 has a different construction (sponge instead of Merkle-Damgård), so a hypothetical future attack on SHA-2 would not also break SHA-3. For most uses, SHA-256 is fine. Pick SHA-3 if you specifically want length-extension immunity without truncation, or if your system is post-quantum-flavored and chooses sponge for symmetry with the SHAKE XOFs.

A salt is a unique, non-secret random value mixed into a password hash so that two users with the same password get different stored digests. Without a salt, an attacker can precompute hashes for a candidate password and match many users at once. Salts are stored alongside the hash and must be unique per user (16 random bytes is enough).

Salt is unique per user, stored next to the hash in the database, not secret. Pepper is a secret value shared across all users, stored outside the database (in an env var or HSM). The point of pepper is defense in depth: if an attacker steals only the database, the hashes are uncrackable without the pepper. If they get both, pepper buys nothing extra.

For Merkle-Damgård hashes (MD5, SHA-1, SHA-2 non-truncated), H(key || message) is not a secure MAC , it leaks length-extension. HMAC nests two hash calls with two derived keys (K ⊕ ipad and K ⊕ opad), which makes the construction safe regardless of length-extension. See the HMAC playground and attack demo.

Argon2id when you can. It is the PHC winner, has a tunable memory cost (forcing GPU attackers to also commit large amounts of GPU memory), and is RFC-standardized (RFC 9106). bcrypt remains a defensible legacy choice; do not migrate working bcrypt installations in a panic.

Two passes of SHA-256 block length-extension attacks against the block-header MAC and have a small theoretical hardening against multi-collisions. The cost is essentially zero (each pass is nanoseconds). The same trick is used in some certificate transparency protocols.

A binary tree where each leaf is the hash of a data block and each internal node is the hash of its two children. The root commits to the entire data set in a single digest. Proving that one leaf is included requires only the sibling hashes along the path to the root. Used in Git, Bitcoin, certificate transparency, IPFS, BLAKE3, and many other systems.

Every Git object is named by the SHA-1 of type size\0content. Practical SHA-1 collisions have been found, so a malicious party who controls the content of two files could create indistinguishable objects. Git mitigates this by using a collision-detecting SHA-1 variant (libsha1dc) that flags the SHAttered attack family. A long-running migration to SHA-256 object IDs is ongoing but adoption is slow.

A precomputed table that trades disk space for time when cracking password hashes. Rainbow tables are defeated by salting: a unique salt per user makes precomputation useless (the attacker would need a separate table per salt). Modern password hashes (bcrypt, scrypt, Argon2) also use enough internal work that rainbow tables for them do not exist at any useful scale.

Grover's algorithm gives a quadratic speedup for preimage attacks: n-bit preimage drops to ~2^(n/2) quantum work. So a 256-bit hash like SHA-256 has ~128-bit quantum preimage security, which is still comfortably out of reach. Hash functions are not broken by quantum computers in the catastrophic sense that public-key crypto is (RSA, ECC). Doubling the output size (SHA-512 instead of SHA-256) is the standard precaution if you want post-quantum margin.

An image (or audio, video) fingerprint that produces similar hashes for visually similar inputs. aHash, dHash, pHash, wHash are the common image variants. Used for near-duplicate detection, reverse image search, and content moderation. Crucially, they are not cryptographic: an attacker can construct images that hash to a target value.

A hash function designed to be cheap inside a zero-knowledge proof circuit, where each field multiplication is an R1CS constraint or custom gate. Poseidon, MiMC, Rescue-Prime, and Pedersen are the common choices. They are usually slower than SHA-256 outside a circuit but 10-100× cheaper inside one.

No, and it does not claim to be. xxHash is a non-cryptographic hash designed for speed and distribution; differentials are findable by SAT solvers in seconds. Use it for hash tables, dedup of trusted inputs, content checksums against accidental corruption. Do not use it for MACs, signed URLs, or content addressing against adversaries.

No. Use a cryptographically secure random source: crypto.getRandomValues in the browser, crypto.randomBytes in Node, /dev/urandom on Unix, os.urandom in Python. Math.random is predictable.

16 random bytes is the modern standard (Argon2 RFC 9106, scrypt recommendations, OWASP guidance). 8 bytes is acceptable for legacy compatibility. Anything bigger than 16 bytes is harmless but pointless.