Cryptographic hash functions are usually summarised as "one-way". State the security properties a hash function is actually supposed to provide, and explain why knowing a function is one-way still does not tell you whether a particular use of it is safe.

## What a hash function is A cryptographic hash function maps an input of any length to a digest of fixed length — 128 bits for MD5, 160 for SHA-1, 256 for SHA-256. It has no key, so anyone can compute it; it is deterministic, so the same input always yields the same digest; and it is not invertible, because there is no inverse function to invert — infinitely many inputs share each digest. That last point is worth stating precisely, because candidates routinely say "a good hash has no collisions". By the pigeonhole principle, mapping an unbounded domain onto a finite range *guarantees* collisions exist. The security claim is never "there are none"; it is "you cannot find any within your computational budget". ## The three properties **Preimage resistance.** Given a digest `d`, it is infeasible to find any `m` with `H(m) = d`. Generic cost for an n-bit digest is about 2^n. **Second-preimage resistance.** Given a specific `m1`, it is infeasible to find `m2 != m1` with `H(m2) = H(m1)`. Also about 2^n generically. **Collision resistance.** It is infeasible to find *any* pair `m1 != m2` colliding. This is the weakest requirement to attack, because of the birthday bound: with about 2^(n/2) random digests you expect a collision. A 128-bit digest gives only 64 bits of collision security — reachable today. This asymmetry is the single most useful fact in the topic: collision resistance is always the first property to fall, and it falls at half the digest length. The properties are ordered in strength. A function that is collision resistant is (for practical, compressing functions) second-preimage resistant, because a second preimage is a collision you happened to find with one side fixed. The converse does not hold: MD5 has no collision resistance left at all, yet the best known preimage attack is around 2^123 — no practical improvement over brute force. ## The invariant: who controls which input? This is what the question is really testing. "Is MD5 safe?" has no answer. "Which property does this use rely on, and does the function still provide it?" always does. Work through the adversary's control: - **Both inputs attacker-chosen.** Signing a document or certificate, deduplicating uploads, content-addressed storage, "this binary is approved because its digest is on the list", plagiarism/duplicate detection. The attacker builds a benign artifact and a malicious one that collide, gets the benign one blessed, and swaps. Requires collision resistance. - **One input fixed by someone else.** You already hold a file and its digest and want to detect tampering. The attacker must hit your existing digest, which is second-preimage. Much harder. - **Neither input attacker-chosen; the digest is a lookup key.** Cache keys, shard selection, hash tables. No cryptographic property is needed — until the key becomes a security decision, at which point collisions become cache poisoning or cross-tenant leakage. - **The input is the secret.** Hashing a phone number, a coupon code, a password. No hash property is in play. Preimage resistance says there is no *shortcut* to inversion; it says nothing about enumerating a small domain and hashing each candidate. Secrecy here is bounded by input entropy. ## Fixed length and avalanche Fixed-length output is what makes digests usable as identifiers, index keys and signature inputs, and it is also the source of the pigeonhole argument above. Avalanche means that flipping one input bit flips roughly half the output bits, with no statistical relationship to the change. Its security value is that a digest leaks nothing partial: you cannot tell that two inputs are similar, you cannot recover a prefix, you cannot hill-climb toward a target. It is a *design property* that supports the three security properties; it is not itself a guarantee, and "it has avalanche so it is irreversible" is not an argument. ## Digest length in practice Choose length by the property you need. If you need collision resistance at a 128-bit security level, you need a 256-bit digest. Truncating is legitimate and common (SHA-512/256), but the cost is explicit: truncating 256 bits to 128 leaves 64-bit collision security. Any protocol that shortens a digest "to fit the column" has silently halved the number that matters. ## How to answer in an interview Name the three properties with their generic costs, state the birthday bound, then pivot to the invariant: identify the adversary's control over the inputs, and that tells you the property, which tells you whether a given function is adequate. Answering "one-way and collision-free" and stopping is the weak answer.