A service authenticates messages by transmitting the message together with SHA-256(secret || message). Explain the structural weakness in that construction, and state the general rule for when a bare hash actually gives you integrity.

## The construction and why it leaks MD5, SHA-1, SHA-256 and SHA-512 all use the Merkle–Damgård design: the message is padded to a whole number of blocks, an internal state is initialised to a fixed value, and each block is mixed into that state by a compression function. When the blocks run out, **the internal state is the digest**. That last sentence is the vulnerability. The digest is not a summary of the state; it *is* the state. An attacker who sees `t = H(secret || m)` can load `t` as the starting state of the same function, feed in any suffix, and obtain the correct digest for a longer message — specifically for `secret || m || glue || suffix`, where `glue` is the padding the original computation appended (length-encoded, so the attacker must guess or brute-force the secret's length; the search space is tiny). At no point do they learn or need the secret. Whether that is exploitable depends on how the receiver parses the extended message. In practice, formats that ignore trailing junk or take last-wins semantics — trailing query parameters, appended key/value pairs, permissive serializers — make it directly exploitable: append `&role=admin` and the tag still verifies. ``` text known: tag = H(secret || "user=alice") attacker computes, without the secret: tag' = resume(tag) over ("padding-of-original" + "&role=admin") sends: "user=alice" + padding + "&role=admin" , tag' receiver recomputes H(secret || received) == tag' ✓ verifies ``` ## Which functions are immune, and why - **Sponge constructions (SHA-3/Keccak).** The internal state is larger than the output; the unexposed "capacity" portion cannot be reconstructed from the digest, so the chain cannot be resumed. - **Truncated Merkle–Damgård (SHA-512/256, SHA-384).** The withheld bits play the same role: the attacker lacks part of the state. - **BLAKE2 / BLAKE3.** Designed with the finalisation flag that makes extension impossible. - **HMAC over any of them.** HMAC hashes twice with two derived keys, so the outer hash's input is the inner digest and the exposed state is not the tag over the message. A candidate who says "switch to SHA-3 and the construction is fine" has spotted the mechanism but missed the design point: you would be relying on an accidental property of a chosen algorithm to make a home-made scheme safe. Use a construction whose security is stated for the purpose — HMAC, or a purpose-built keyed hash. ## The general rule about hashes and integrity Separate the four properties an interviewer expects you to name: - **Confidentiality** — nobody else can read it. Hashes give none. - **Integrity** — the data has not changed since the reference was taken. - **Authenticity** — the data came from the party holding the key. - **Freshness** — this is not a replay of an older, legitimately produced message. A bare hash is unkeyed, so anyone — including the attacker — can compute it. It therefore provides authenticity never, and integrity **only relative to a digest the attacker could not have rewritten**. That is the rule worth memorising: > A hash moves the integrity problem from the artifact to the digest. It is a control only if the digest travels a path the attacker cannot influence. Apply it across stacks and the pattern is identical: - A checksum on the same download page as the tarball: mirrors the artifact's own trust, so it detects a truncated download and nothing adversarial. - A package repository: digests live in an index that is *signed*, so the trust ultimately rests on a signature, and the digests are an efficiency mechanism that lets you verify big artifacts against a small signed statement. - TLS certificates: the digest of the certificate body is signed by a CA key; the hash is the compression step inside an authenticity mechanism, not the mechanism. - Content-addressed storage and version-control object graphs: hash chaining gives you tamper-*evidence* relative to a root you obtained elsewhere; if the attacker controls the root, the chain proves nothing. In every case the hash is doing the same job — shrinking a large artifact to a small commitment — and the authenticity is supplied by a key somewhere else. ## Freshness is separate again Even a correct MAC does not stop replay: a captured message with its valid tag stays valid forever. Freshness requires a nonce, sequence number or timestamp *inside* the authenticated data. Candidates often stop at "use HMAC" and are surprised by the replay follow-up. ## How to answer Name the Merkle–Damgård state exposure, name the immune constructions, then step up a level: the real error was building an authenticity mechanism out of a primitive that offers none, and the general rule is that a hash gives integrity only against an authenticated reference value.