In one sentence
PGP (Pretty Good Privacy, standardised as OpenPGP) lets you encrypt a message so only the intended recipient can read it, and/or sign a message so the recipient can verify it really came from you and was not altered.
Why it matters
Security researchers, journalists and open-source maintainers still widely publish a PGP public key for one reason: it lets anyone send them something sensitive — a vulnerability report, a leak — without a prior shared secret, and it lets you verify that a signed release, advisory or Git tag actually came from who it claims to. A security.txt file's Encryption: field is where a project points at its key. It is the older, still-relevant sibling of the browser-native approach behind this site's own Secret Menu — same goal (no third party sees the plaintext), different mechanism (long-lived key pair instead of a one-time link).
How the key pair works
You generate a key pair once: a public key you share freely and a private key you never share. Anyone encrypts to your public key; only your private key can decrypt it. Signing works in reverse — you sign with your private key and anyone can verify the signature against your public key. In practice a message is encrypted with a fresh symmetric session key (AES) and only that key is encrypted to each recipient's public key, which is why one message can have several recipients.
A key has a fingerprint — the SHA-1 (v4) or SHA-256 (v6) hash of the public key, shown as 40 or 64 hex characters; the last 16 are the long key ID. It carries one or more user IDs (name and e-mail), an optional expiry, and usually subkeys for encryption and signing so the primary key can stay offline. Modern keys are Ed25519/Curve25519; RSA-4096 is fine; RSA-1024 and anything using SHA-1 for signatures should be retired.
The unsolved part is trust: anyone can upload a key with your name and e-mail to a keyserver. Verifying keyservers (keys.openpgp.org) confirm the e-mail address, but nothing confirms the person. The fingerprint, obtained through a channel you already trust — the project's website over HTTPS, a printed business card, a video call — is the check.
Try it yourself hands-on
You want to send a vulnerability report to a project that publishes a PGP fingerprint on its security page.
- Use the PGP Key Lookup to fetch their public key from a keyserver by e-mail address, fingerprint or key ID. Search by the fingerprint from the security page if you have it — that way a look-alike key uploaded under the same e-mail address cannot be returned at all.
- Paste the returned key into the PGP Key Inspector. Read the fingerprint, the user IDs, the algorithms, the creation and expiry dates and the subkeys. Compare the fingerprint character by character with the one on the project's site: that match, not the lookup, is the trust check. An expired key, or one still signing with SHA-1, is a reason to ask the project for a current one.
- Encrypt your report to that key with your own OpenPGP-capable client (GnuPG, Thunderbird, Mailvelope). Lookup, inspection and encryption are separate steps — these tools find and read the key; they do not perform the encryption, and your private key never touches a website.
- Publishing your own? The security.txt Generator writes the file that tells researchers where your key is; the key file itself goes on your site and on keys.openpgp.org.
Common misreadings
- Encryption is not authentication. An encrypted message from an attacker is still from an attacker. Signing is the identity claim; encryption is the confidentiality claim.
- PGP does not hide metadata. Sender, recipient, subject line and timing are all visible; only the body is protected.
- Losing the private key means losing the mail. Back it up, and publish a revocation certificate path before you need one.