PGP for beginners: keys, fingerprints and everyday encrypted messaging

in the onion scene pgp is table stakes: vendors sign their announcements, buyers encrypt order details, admins publish signed canaries. yet most newcomers copy-paste armor blocks for months without understanding what any of it does. this guide builds the mental model first, then walks a complete hands-on workflow you can practice right now in your browser, no installation required.

the core idea: two keys, opposite jobs

openpgp is built on asymmetric cryptography. you generate a key pair that consists of a public key and a private key. the public key is meant to be shared everywhere - it is your mailbox slot, open to the world. the private key stays with you and never leaves your control; it is the key that opens the slot.

two operations fall out of this, and they travel in opposite directions:

• encryption: anyone can scramble a message to your public key, but only your private key can unscramble it
• signing: only your private key can produce a signature, but anyone with your public key can confirm it is yours and that the message was not altered

everything else - armored blocks, fingerprints, key servers - is packaging around these two moves. when a vendor asks you to "encrypt with my pgp", they want the first operation aimed at their public key. when they post a "signed mirror list", they performed the second with theirs.

generating your first key pair

1. open our pgp key generator. choose curve25519 for a fast modern key, or rsa-4096 if some legacy service demands it.
2. pick a user id. for pseudonymous use, invent a handle and email that exist nowhere else - this label gets baked into the public key permanently.
3. set a passphrase. this encrypts the private key file itself, so a leaked key without the passphrase is still just noise. generate one with our passphrase generator; four or five random words beat a short password with symbols.
4. generate, then save both armored outputs immediately. the public key goes anywhere; the private key belongs in offline storage you control, not in a cloud sync folder.
5. record the fingerprint shown after generation. it is the permanent identity of your key, and you will compare it against this value every time you restore or share the key.

fingerprints: the identity that actually counts

a fingerprint is a 40-character hexadecimal hash of your complete public key. it exists because keys themselves are bulky and easy to alter subtly; the fingerprint condenses them into something comparable by eye. when you receive someone's key, you do not ask "is this a pgp key" - you ask "does this key's fingerprint match the one published where i trust".

scammers routinely upload lookalike keys to key servers or attach their own key to cloned profiles. our fingerprint comparator takes two keys or two fingerprints and tells you plainly whether they describe the same key. make the comparison before your first encrypted contact, and repeat it whenever a vendor changes keys - key rotation is a favorite move right before exit scams.

encrypting a message

1. get the recipient's public key from a source you trust and check its fingerprint against their published one.
2. open pgp encrypt, paste their public key, and type your message. keep it minimal: no real names, no addresses you do not need to share.
3. encrypt. the output is an armored block starting with -----BEGIN PGP MESSAGE----- that looks like gibberish and travels safely over insecure channels.
4. optionally tick the sign option. that attaches your signature so the recipient can also prove the message came from your key, not just that it is secret.

decrypting a reply

when someone sends back an armored message addressed to your key, open pgp decrypt, supply your private key and its passphrase, and the plaintext appears. notice what just happened technically: the sender's tool generated a one-time session key, encrypted the message with it, wrapped that session key to your public key, and your private key unwrapped the package. you did nothing differently, but understanding the mechanism explains why you can decrypt with any device that holds your private key - and why losing that key with no backup loses the data forever.

signing and verifying

signing answers a different question than encryption. it does not hide content; it stamps it. produce a clearsigned or detached signature with pgp sign, publish both parts, and anyone can run the pair through pgp verify to get a binary verdict: good or bad.

a good signature establishes two things simultaneously: the holder of that private key signed exactly these bytes, and nothing changed afterwards. it does not establish that the key belongs to who you think it does - that gap is closed by fingerprint comparison, which is why beginners who skip the fingerprint step end up "successfully" verifying forged announcements. the full ritual, including how to read gnuPG failure messages, lives in our step-by-step signature verification guide.

when armor gets mangled

real-world pgp blocks arrive broken constantly: chat apps collapse newlines, forums strip trailing spaces, mail clients rewrap lines at different widths. a damaged block fails verification even when nobody cheated. before assuming fraud, run the block through our armor cleaner, which restores proper 64-character wrapping and reports exactly what it repaired. if the cleaned block verifies, the original sender is innocent; if it still fails after cleaning and re-copying, then you have a real problem worth investigating.

key hygiene basics

• one key per identity. do not cross-wire your pseudonymous persona with any account tied to your legal name.
• back up the private key offline - printed paper or an encrypted usb stick stored away from daily devices.
• never paste your private key into a web page you have not inspected. ours runs entirely client-side, but the habit of reading before pasting will protect you elsewhere too.
• rotate keys deliberately and announce the new fingerprint in a signed message from the old key, so observers can follow the chain.

from browser practice to real gpg

browser tools are ideal for building intuition because every step is visible and nothing leaves your machine. when you handle anything genuinely sensitive, install gnupg locally - gpg4win on windows, gpg tools on macos, native packages on linux - and repeat the identical workflow in a terminal. the concepts transfer exactly, and you gain scriptable, auditable tooling that works offline. pgp rewards small, boring habits: verify fingerprints, sign what matters, encrypt what is private, and let the math do the trusting.

where keys live: key servers and trust

beginners often assume a key found on a key server is therefore trustworthy. it is not. key servers are dumb bulletin boards: anyone can upload a key claiming any name or email address, and deletion is famously unreliable. the key server answers "does a key with this id exist", never "does this key belong to who it claims". that second question is always answered by fingerprint comparison against a channel you already trust.

• keyservers are for distribution, not verification - treat anything fetched from one as unverified until its fingerprint checks out
• the web of trust (other people signing keys to vouch for them) barely functions outside dedicated communities; do not build your safety on strangers' certifications
• for pseudonymous use there is usually no third party at all - you are the entire chain of trust, which makes recording fingerprints correctly from day one non-negotiable

pgp beyond email: two-factor logins and market messaging

in this scene pgp shows up in two places beginners rarely expect. first, many services offer pgp-based two-factor authentication: the site encrypts a short challenge with your public key and you must decrypt it locally to prove key possession. if you enabled that feature, your private key becomes as sensitive as your password - losing access to the key means losing access to the account, so back it up before enabling. we covered the mechanics in our note on pgp two-factor logins.

second, order details on markets are expected to be encrypted to the vendor's key rather than posted in plaintext, precisely because site databases get seized and leaked. the discipline is identical whether the message is an order or a letter: fetch their key once, fingerprint-check it, then encrypt everything sensitive to it every time.

beginner mistakes worth naming

• publishing the private key by accident - it happens more than you would think when both armored blocks sit side by side in a text editor. before sharing, read the header line: it must say public, not private
• using a passphrase-free key "temporarily" - temporary arrangements become permanent the day the laptop disappears
• encrypting to yourself last: always also encrypt a copy to your own public key, or the sent message is unreadable to you forever
• assuming encryption implies authentication - an encrypted message can still be written by anyone who found your public key; only a signature proves authorship
• verifying a fingerprint by reading it aloud over the same insecure channel that delivered the key - the comparison anchor has to come from somewhere the attacker does not control

a practice plan for week one

1. day 1-2: generate a practice key pair in the browser tool and encrypt messages to yourself; decrypt them again until the flow feels mechanical.
2. day 3: find a real public figure or project that publishes a fingerprint, download their key, and run the comparison yourself with the fingerprint comparator.
3. day 4: take any signed announcement - a software release note works - and verify it end to end using our verify tool, reading the output line by line.
4. day 5: deliberately corrupt one character of a signed block and watch verification fail; then repair it with the armor cleaner and see it pass again. nothing teaches the failure modes faster than causing one safely.
5. day 6-7: repeat the full cycle without instructions, then decide what belongs in your real workflow versus what stays as browser practice.