Digital Signatures

A valid digital signature on a message proves three things: the signer had access to the private key (authenticity), the message was not modified after signing (integrity), and the signer cannot later deny having signed (non-repudiation).

One thing it does not prove: confidentiality. A signed message is not encrypted. Anyone can read it. Signing and encrypting are independent operations; you can do either, both, or neither, depending on what you need.

The directional rule is the mirror of encryption:

• To encrypt a message to someone, you use their public key. Only they can decrypt.
• To sign a message as yourself, you use your own private key. Anyone with your public key can verify.

This is the source of the most common student confusion in asymmetric crypto: "wait, you encrypt with public but sign with private?" Yes. Same key pair, opposite directions, opposite security properties. The mnemonic from the Foundations page bears repeating: encrypt to a public key, sign with a private key.

No real signing algorithm signs the raw message. They all hash the message first, then sign the hash. Three reasons:

• Size. RSA can only sign a value smaller than the modulus. A 2048-bit RSA key cannot sign a multi-megabyte file directly. SHA-256 of the file fits in 256 bits, which fits in any RSA modulus.
• Speed. Hash functions process gigabytes per second. The expensive asymmetric operation runs on a small fixed-size input.
• Security. Some signature algorithms have algebraic structure that an attacker can exploit by choosing messages with specific mathematical properties. Hashing first destroys that structure.

The pattern is universal:

signature = sign(private_key, SHA-256(message))

valid = verify(public_key, SHA-256(message), signature)

The hash function is part of the algorithm name: SHA256withRSA, ECDSA-P256-SHA256, Ed25519 (which has its own internal hash). When you see those strings in a certificate or JWT header, that is the hash-then-sign pattern in action.

The interactive below uses a toy signing function. The math is not real ECDSA, but the protocol behavior is the same: any modification to the message invalidates the signature, and a signature from the wrong key fails verification.

Three signature families dominate the modern landscape. Each has different tradeoffs.

One sentence to internalize: encryption hides content; signatures prove origin and integrity. They are orthogonal. You can have any combination:

• Unsigned, unencrypted: a public blog post. Anyone can read, anyone could claim to be the author.
• Signed, unencrypted: a Linux kernel release. Public download, but you can verify it came from kernel.org.
• Unsigned, encrypted: a TLS-encrypted form submission to a server. The server reads it, but anyone could have submitted it.
• Signed and encrypted: a PGP-protected email with a verified sender. Encrypted to the recipient, signed by the sender.

• TLS certificates: Each X.509 certificate carries a signature from a Certificate Authority. Browsers verify the chain on every connection. (See the PKI page.)
• Code signing: macOS, Windows, iOS, and Android require apps to be signed before they will run. The signature is checked against a developer certificate.
• Git commits and tags: Signed with GPG or SSH keys to prove the commit author. GitHub displays a "Verified" badge.
• JWT (JSON Web Tokens): The token payload is signed. Servers verify the signature instead of re-checking the user's password on every API call.
• DKIM email: Outbound mail servers sign messages with a domain key. Receiving servers verify by looking up the public key in DNS.
• Cryptocurrency transactions: Every Bitcoin or Ethereum transaction is an ECDSA signature authorizing the spend from a specific address.