Signing vs encrypting: what a PGP signature actually proves

People new to PGP constantly mix up two operations that do completely different jobs. Encrypting a message makes it readable only to the recipient. Signing a message proves who wrote it and that it was not altered. You can do either one alone, or both together, and choosing wrong is not a small mistake: an encrypted but unsigned message can have been written by anyone who grabbed the key, and a signed but unencrypted message is a postcard with a wax seal.

What a signature actually proves

A PGP signature is a hash of the message encrypted with your private key. Anyone with your public key can decrypt that hash, hash the message themselves, and compare. If they match, two things are proven: the message is byte-for-byte identical to what you signed, and the signer held the private key. Note what is not proven: the signature does not confirm the person is who they claim, only that the key is the key. Identity comes from key verification, meaning checking the fingerprint through a second channel, which is covered in how to verify a PGP key before you trust it.

Why you would sign something you do not encrypt

Public announcements, software release notes, security advisories and plain instructions are routinely signed but not encrypted. The content is meant for everyone; what matters is that nobody can quietly edit it or claim you said something else. If you publish installation instructions for a package and sign them, a tampered copy that adds a malicious URL will fail verification immediately. This is the pattern behind signed git tags and signed checksum files.

Why you would encrypt something you do not sign

Almost never, deliberately. If you encrypt without signing, the recipient knows only that someone holding their public key sent the message. Since public keys are, by design, public, that could be anyone. There are narrow cases, such as anonymous tip-offs, where the sender wants confidentiality and no attribution, and for those, signing would defeat the point. For normal correspondence, always sign and encrypt together. Every mainstream PGP client has a combined sign-and-encrypt option, and it should be your default.

A worked example

Suppose you email a freelancer a payment instruction. Sent in the clear, anyone on a compromised mail server can edit the IBAN. Encrypted only, an attacker who obtains your key file can inject their own account and the freelancer cannot tell. Signed and encrypted, any change to the IBAN breaks the signature on arrival, and the recipient sees the failure before acting on the number. The verification step takes under ten seconds and it is the entire value of the system.

Common failure modes

First, trusting a key because the email address on it matches. Addresses are self-declared; only a fingerprint check proves anything. Second, re-signing after forwarding a message, which replaces your endorsement for the original author's and misrepresents provenance. Third, letting signatures from an expired key fail silently in a client set to hide errors, a problem covered in key expiration and revocation. Check your client's verification settings so failures are visible, not buried.

Defaults worth adopting

Sign and encrypt by default for private mail. Sign anything you publish that others might act on. Verify signatures on arrival instead of assuming, and treat an unverified message with payment details or credentials as hostile until checked. The cryptography is solid; nearly every real-world PGP failure is a workflow failure, and workflows are cheap to fix.