What is hash-then-sign, and why is it the standard pattern?

Sign the hash of the document, not the document itself. Two reasons: signing is slow on large data, and the hash-then-sign reduction is provably as secure as signing the raw document (assuming the hash is collision-resistant).

Flow:

1. h = HASH(document)        // SHA-256 of a 1 GB file = 256 bits
2. signature = SIGN(sk, h)   // One quick RSA/ECDSA operation
3. send (document, signature)

To verify:

1. h = HASH(received_document)
2. VERIFY(pk, h, signature) == OK?

Why this is safe:

• Hash is collision-resistant: nobody can find a second document with the same hash, so the signature on h is effectively a commitment to the original document.
• Hash is deterministic: signer and verifier compute the same h from the same data.

Why it's universal:

• Performance: signing 1 GB with raw RSA is impossible (the algorithm is defined for messages smaller than the modulus). Signing a 256-bit hash takes one RSA operation.
• All real PK signature schemes (RSA-PSS, ECDSA, EdDSA, …) operate on a fixed-size hash input internally.

Hash choice matters:

• SHA-256 / SHA-384 / SHA-512 / SHA-3 are current good choices.
• MD5 and SHA-1 are broken for signatures — collision attacks let an attacker craft two documents with the same hash. They were used in the Flame malware (2012) to forge Microsoft code-signing certificates and in the SHAttered attack (2017) to break Git's SHA-1 assumptions.
• Browsers / OS vendors stopped accepting SHA-1 certificates in 2017.

Tip: When you see "RSA-SHA256" in a TLS cipher suite or X.509 cert, that's literally RSA-signing a SHA-256 hash. The combination is what gets specified, never just "RSA" alone.