Signature schemes hash the message before signing it. Beyond "the message might be large", what does that hash contribute to the security argument, and what goes wrong when the hash is weak or when signer and verifier disagree about exactly which bytes were covered?

## Part 1 — why hash, really The throwaway reason is size: a signature primitive consumes a fixed-length value in a bounded algebraic domain, and a message can be a gigabyte. Hashing solves that. But the interview answer is the **security reduction**. In the hash-then-sign construction, forging a signature on a new message means either breaking the underlying primitive or finding two messages that hash to the same digest. So the scheme's unforgeability *depends on the hash's collision resistance*. The consequences are concrete: - **A broken hash breaks the signature system without touching the key.** Key length, key storage and the signing algorithm can all be beyond reproach; if the digest function admits collisions, an attacker who gets one message signed obtains a valid signature on another. - **Collision, not second preimage, is the relevant property.** A second preimage attack (finding a second message matching the digest of a *given* message) is far harder and would be needed to attack an already-signed document. A collision attack lets the attacker craft *both* messages, which fits exactly the workflows where a signer signs something a requester supplied or influenced: certificate issuance from a submitted request, an approval workflow over a document someone else drafted, a build system signing an artefact from a contributed source. Chosen-prefix collisions strengthen this further by letting both messages start with attacker-chosen, meaningfully different content. - **The mitigation is structural, not vigilance.** Never sign a bit-for-bit attacker-supplied blob when you can help it: include signer-chosen, unpredictable content in what gets signed (a random serial, a nonce, a server-generated field) so the attacker cannot fully control both sides of a collision, and retire hashes before they are broken. The standardised **encoding** applied to the digest before the primitive runs also earns its keep. It removes the algebraic malleability that raw application of the primitive admits, and it embeds an identifier of the hash algorithm inside the signed value, providing domain separation — an attacker cannot take a digest and have it accepted as a digest under a different algorithm. ## Part 2 — the coverage gap: which bytes were signed? A signature is a statement about a specific octet string. Every real incident of the "valid signature, wrong content" shape comes from the signer and the verifier disagreeing about that string, or from the *verifier* and the *consumer* disagreeing. Four recurring shapes, from different stacks: 1. **Canonicalised tree structures.** A signature over a canonicalised node-set of a hierarchical document identifies content by reference. An attacker can restructure the document so the referenced, signed subtree still validates while the application's own lookup finds a different, unsigned subtree of the same name elsewhere in the tree. Verification says yes; the application acts on content that was never signed. This is the classic wrapping attack, and its lesson is that **verification must return the exact content to be consumed**, not merely a boolean. 2. **Object formats with no canonical serialisation.** "Sign the object" is undefined when key order, number formatting, string escaping and whitespace can all vary and the two ends use different libraries. The robust designs avoid the problem entirely by signing the exact transmitted octets — typically by carrying an encoded copy of the payload inside the signed structure so re-serialisation never happens. Attempting to define canonicalisation after the fact is a long tail of edge cases. 3. **Containers where the signature covers a subset.** Archive and package formats where a manifest lists digests of entries: anything not listed is unsigned, so an attacker may be able to add entries, or exploit duplicate-name handling so the verifier checks one entry and the loader uses another. 4. **Normalisation in transit.** Text that gets line-ending translated, re-encoded, trimmed or transcoded between signing and verifying. Verification then fails for honest traffic — which teaches operators to "fix" it by relaxing the check, the worst possible outcome. ## The governing rule **What you see is what you sign, and what you verify is what you consume.** In implementation terms: - Sign and verify over exact octets. Never re-serialise between the two. - Have the verify step *hand back* the authenticated bytes, and make the application incapable of reading the payload by any other route. If your parse happens before verification and your consume happens after, they must be the same parse of the same bytes. - Cover everything that matters, including metadata the consumer trusts — names, versions, types, targets — not just the body. If an unsigned field can change how signed content is interpreted, it is part of the message. - Fail closed and loudly on mismatch, and never let a normalisation quirk become a reason to weaken the check. ## Interview delivery "Hashing isn't just for size: the scheme's unforgeability reduces to collision resistance, so a broken hash forges signatures without touching the key — and the risky workflows are the ones where you sign content someone else supplied. Then, separately, a signature covers exact bytes, so my main implementation worry is the gap between what was verified and what the application actually parses."