Digital Signatures & the Trust Chain

Chapter 9 built RSA and ECC entirely around encryption — confidentiality. This chapter covers the reverse-direction use of the exact same key pairs: proving who produced a message and that it wasn't altered. By the end of this chapter, every one of Chapter 1's four goals will finally have a concrete mechanism behind it — and https1's certificate chapters can be revisited with full understanding of what's actually happening underneath.

Signing vs. Encrypting — Not the Same Operation

These two operations use the same key pair, but in opposite roles:

Notice the pattern flips entirely: encrypting is "anyone can lock it, only the owner can unlock it"; signing is "only the owner can produce it, anyone can check it." Same key pair, opposite direction of use.

How Signing Actually Works — Hash-Then-Sign

Chapter 7 mentioned that signing algorithms actually sign a message's hash, not the raw message — here's why, and exactly how it works:

1. The signer computes a cryptographic hash of the message (Chapter 7) — messages can be any length, but signing algorithms operate on fixed-size numeric inputs, so hashing first makes the input size uniform and small.
2. The signer applies their private key to that hash, producing the signature.
3. The signer sends the message plus the signature.
4. The recipient independently hashes the received message themselves.
5. The recipient uses the signer's public key to check whether the signature corresponds to that hash. If it matches, the signature is valid; if not, either the message was altered or the signature wasn't produced by the claimed signer's private key.

RSA Signatures vs. ECDSA vs. EdDSA

RSA can sign directly, using the same trapdoor idea from Chapter 9 run in the signing direction. ECDSA is the elliptic-curve signature algorithm — offering the same dramatically smaller key and signature sizes for equivalent security that Chapter 9 covered for ECDH, and it's now the dominant choice for new certificate issuance. EdDSA (commonly seen as Ed25519) is a newer, related alternative — faster, and critically, deterministic: it doesn't need a fresh random value for every signature the way ECDSA does.

What a Signature Actually Proves

Tying directly back to Chapter 1's four goals:

• Integrity — Chapter 7's avalanche effect means even a single altered bit of the message produces a completely different hash, which will no longer match the signature. Any tampering is detected.
• Authenticity — only someone holding the corresponding private key could have produced a signature that verifies successfully against a given public key.
• Non-repudiation — because only the private key holder could have produced it, they cannot credibly deny having signed it later, assuming their private key was never compromised.

The Trust Chain — From Signatures to Certificates

A signature alone only proves "produced by whoever holds this specific private key" — it says nothing about who that key actually belongs to in the real world. That's exactly the gap https1's certificate chapters (https1-4, https1-5) exist to close, and it can now be explained fully.

A Certificate Authority (CA) signs a certificate that binds a specific public key to a specific identity — a domain name, for instance — using exactly the hash-then-sign process described above, with the CA's own private key. Browsers and operating systems ship with a small, curated set of trusted root CA public keys built in. The full chain of trust is literally a chain of signatures: a root CA signs an intermediate CA's public key, and that intermediate CA signs the actual website's certificate — each link individually verifiable via the exact signature-verification process described earlier in this chapter, all the way back to a root key the browser already trusts.

Signatures Beyond TLS

Certificates are only one application. Code signing lets software be verified as genuinely coming from its claimed publisher, unaltered — which is exactly what Chapter 7's 2012 Flame malware defeated, by forging an MD5 collision specifically to produce a fraudulent, still-valid-looking Microsoft code signature. Software update mechanisms and package managers both rely on signature verification to ensure a downloaded update or package genuinely came from its claimed source. Git commit signing applies the same idea to source code history itself.

Hands-On Exercises