Exercise 2: Why Sign the Hash, and Why It's Still Fully Protective — Possible Solution
====================================================================

Why the hash, not the raw message:

Signing algorithms like RSA and ECDSA operate on fixed-size numeric
inputs -- they're mathematical operations defined over numbers of a
specific bit length, not over arbitrary-length text or files directly.
Real messages can be any length at all, from a few bytes to many
gigabytes. Hashing first (Chapter 7) converts any message, regardless
of its original length, into a small, FIXED-SIZE digest that the
signing algorithm can actually operate on directly and efficiently --
signing a huge file's full contents directly, even if it were
mathematically possible, would be far slower than signing one small
fixed-size hash of it.

Why this doesn't weaken integrity protection at all:

Chapter 7's avalanche effect guarantees that changing even a single
bit of the original message produces a COMPLETELY DIFFERENT hash --
not a similar one, a totally different one, with roughly half the
output bits flipping on average. This means the hash is just as
sensitive to tampering as the original message would be: if an
attacker alters the message in ANY way, the hash the recipient
computes during verification (step 4 in this chapter's process) will
no longer match the hash that was actually signed, and the signature
verification will fail.

Put differently: the hash acts as a complete, tamper-evident summary
of the message. Signing that summary is functionally equivalent to
signing the whole message directly, PROVIDED the hash function has the
avalanche effect (and the collision resistance from Chapter 7) needed
to guarantee that no two different messages could ever produce the
same hash undetected. Signing the hash is a practical optimization,
not a security compromise -- it only works safely because Chapter 7's
hash function properties make the hash a faithful, tamper-sensitive
stand-in for the full message.

WHY THIS WORKS AS AN ANSWER
------------------------------
This directly connects the chapter's own stated reason ("messages can
be any length, but signing algorithms operate on fixed-size numeric
inputs") to Chapter 7's avalanche effect as the SPECIFIC property that
makes this substitution safe -- without collision resistance and the
avalanche effect both holding, signing a hash instead of the full
message would genuinely be a weaker guarantee, which is exactly why
Chapter 7 spent an entire chapter establishing those properties before
this chapter relies on them.