Digital signatures: proving authenticity without hiding content

Encryption (lessons 2–3) makes data unreadable to anyone without the right key — the goal is confidentiality. Signing does the opposite in one important sense: a signed message is still fully readable by anyone — the goal isn't hiding it, it's letting anyone verify that a specific, known party actually produced it, and that it hasn't been altered since. A message can be signed without being encrypted, encrypted without being signed, or both at once — they're independent properties answering different questions.

Lesson 3 established public-key encryption as "public key encrypts, private key decrypts." Signing runs the key pair in the opposite direction: the private key signs, and the public key verifies:

A signature is produced by hashing the message (lesson 1) and then encrypting that hash with the signer's private key. Anyone with the corresponding public key can decrypt the signature back to the original hash, independently compute the hash of the message they actually received, and compare the two. A match proves two things at once: the message came from whoever holds the private key (only they could have produced a signature the public key correctly decrypts), and the message wasn't altered in transit (any change would produce a different hash that wouldn't match).

Auth's JWT lesson described a token as "signed" so a server can trust its contents weren't tampered with after issuing it. Mechanically, this is precisely the process above: the server (holding a private key, for RSA-signed tokens) signs the token's contents; anything holding the corresponding public key can verify the signature without being able to forge a new one. This is also exactly why a JWT's payload is readable but not forgeable — signing doesn't hide the contents (they're often just base64-encoded, not encrypted), it only prevents undetected tampering and proves who issued it.

Not every signed JWT uses this asymmetric public/private key process — many use HMAC instead (covered in depth in lesson 5), which achieves a similar authenticity guarantee using a single shared secret key instead of a key pair. The practical difference matters: with HMAC, whoever can verify a signature can also create a valid one (since it's the same key), while asymmetric signing lets many parties verify using the public key without any of them being able to forge a new signature, since only the private key can produce one. Choosing between them is a real design decision, not an interchangeable implementation detail.

The same signing concept underlies TLS certificates (lesson 7 — a certificate authority signs a certificate, and browsers verify that signature to establish trust), code signing (verifying a downloaded application actually came from its claimed publisher, unmodified), and signed software packages. Once the core mechanism — hash, then encrypt/verify with a key pair or shared secret — is understood once, all of these otherwise-separate-seeming features turn out to be the same underlying idea applied to a different kind of "message."