People reach for PGP expecting a lock, and a lock is part of it. The larger part is a seal. When you get a letter with an intact wax seal you learn two things at once: no one opened it, and it came from whoever owns the stamp. PGP gives you both of those properties for anything digital, and it does so without either side having to share a secret in advance. That last point is what makes it work between strangers on a network where you cannot meet in person.
What PGP is, in one paragraph
PGP, which now usually means the open standard OpenPGP, is a way to encrypt and sign data using a pair of mathematically linked keys. One key is secret and stays with you. The other is public and you give it away freely. Anything locked with the public key can be opened only by the matching secret key, and anything signed by the secret key can be checked by anyone holding the public one. You never have to send a password over the wire, which is exactly the problem older schemes could not solve.
How public-key cryptography works
The trick is that the two keys are a pair, generated together, but you cannot work backwards from the public one to the secret one in any practical amount of time. So it is safe to publish the public key on your website, in a forum profile, or on a key server. People use it to send you messages only you can read, or to check that a signature you produced is genuine.
Why the secret key never travels
The entire security model rests on one rule: the secret key stays on the device that generated it, or on a hardware token, and is never transmitted anywhere, not even to prove ownership. Every operation that needs the secret key — signing, decrypting — happens locally, and only the output (a signature, decrypted text) leaves the machine. If a secret key ever does leave, through a backup upload or a compromised device, treat it as burned and generate a new pair.
What a key server actually stores
A public key server holds exactly what its name says: public keys, indexed by fingerprint or email, available for anyone to pull down. It has no way to verify that the person who uploaded a key is who they claim to be, so a key server listing is a convenience for distribution, not a trust signal on its own — the fingerprint still has to be confirmed through a channel you already trust before you rely on a key you pulled from one.
What is actually inside a key
People talk about "a PGP key" as though it were one object, and that shorthand hides the structure that most confusion comes from. What you generate is a small bundle, and knowing its parts makes the rest of this guide considerably easier.
A primary key and its subkeys
At the centre is a primary key. Its job is authority: it certifies the identities attached to the bundle and it certifies the other keys underneath it. Hanging off it are one or more subkeys, each carrying a capability — one for signing, one for encrypting, sometimes one for authentication. Day-to-day work is done by the subkeys, and the primary key sits above them, which is why an expiring or replaced subkey does not invalidate everything a person has ever done. Exactly which capabilities land on which key depends on how the bundle was generated, and you can see the layout at any time with gpg --list-keys --with-subkey-fingerprints.
Identities, which are just labels
Attached to the primary key is at least one user ID: a name and usually an email address. It is important to understand that this text is unverified by the format itself. Nothing in a key bundle proves that the person holding it is the person named in it; the string was typed in by whoever ran the generator. A key claiming to belong to a well-known project or market is trivially easy to produce, and that is not a flaw being exploited so much as a property people forget the format has.
Fingerprints, and the short forms you should ignore
The one identifier that does the real work is the fingerprint: forty hexadecimal characters derived from the key material itself, conventionally printed in ten groups of four. gpg will also show you shorter forms — a long key ID, and a short one that is only eight characters. Do not use them to identify anyone. The short form carries thirty-two bits of information, and producing a second key that shares an eight-character ID with a target key is a solved, demonstrated problem rather than a theoretical one; the long form is better and still not something to stake a deposit on. When this guide, or any other, says "check the fingerprint", it means the full forty characters, compared end to end.
Expiry dates are a feature
A key with an expiry date is not a key that will stop working inconveniently. It is a key that will stop working if its owner ever loses control of it and cannot say so, which is precisely the case a revocation is supposed to cover but frequently cannot, because announcing a revocation requires access the owner may no longer have. An expiry is a dead-man switch that runs without anybody's cooperation. Setting one, and extending it deliberately while you still hold the key, is a stronger position than an eternal key that can never quietly lapse.
Encrypting versus signing
These are two different jobs and it helps to keep them apart in your head. Encrypting protects a message from being read. Signing proves who wrote it and that it was not altered. Most of the danger on Tor is not that someone reads your public forum post. It is that a fake looks real. So signing, not encryption, is the skill to practice first.
| Property | Encrypting | Signing |
|---|---|---|
| Question it answers | Who can read this? | Who wrote this, unchanged? |
| Key you use | The reader's public key | Your own secret key |
| Key that undoes it | The reader's secret key | Your public key, held by anyone |
| Protects against | Eavesdropping | Impersonation and tampering |
| Why it matters on Tor | Keeps a private note private | Tells a real address from a fake one |
Why signing matters most on Tor
The clearnet leans on certificate authorities. Your browser trusts a padlock because a company vouched for the site behind it. Tor has no such layer. An onion address is its own proof of identity, but it is a long unreadable string, so people copy it from wherever is handy and attackers plant look-alikes in forums, chats and search results.
torhaven safety note
A signed list of addresses fixes this. If a source you can verify signs a list of onion addresses, and you check that signature against a key whose fingerprint you already confirmed, then a planted fake cannot survive the check. It will not carry a valid signature from the right key. That is the whole defence, and it costs you a minute.
How to start using PGP
You do not need to understand the mathematics to use it well. Five steps get you to a working setup you can rely on.
- Install a maintained tool. GnuPG on the command line, or a mail client with OpenPGP built in. Avoid abandoned browser extensions.
- Generate a key pair with a strong passphrase. The secret key stays on your machine. The passphrase protects it if the machine is lost.
- Share your public key. Publish it or its fingerprint so people can encrypt to you and check your signatures.
- Import and confirm keys you receive. Before you trust a key, match its fingerprint against a copy you got some other way.
- Sign what you publish, verify what you receive. This is the habit that pays off, not the install.
torhaven warning
A signature from an unknown key proves almost nothing. It only says the file is internally consistent, not that it came from anyone you should trust. Always confirm the signing key's fingerprint through a second channel first. A key you found on the same page as the message it signed is not a second channel.
A worked example
Say a source you can verify signs a short list of onion addresses, and one of the entries is a Nexus address. You would read it from the signed list, check the signature, confirm the fingerprint, and only then copy the string by hand into Tor Browser. Here is the kind of address that list would carry:
torhaven verification check
nexusakrv5pwd5jtzkycsmp3sllliq6nxilutfug2o3rlmdxmqlzz2ad.onionTeaching example only. A real address is 56 characters before .onion, so compare every character, not the first few. Always cross-check the canonical list on torindex and confirm the signature on torverify before you rely on any address.
A gpg session, end to end
Everything above is easier to hold onto once you have typed it. What follows is the full arc of using a key, from making one to retiring it, with the commands in the order you would actually meet them. Run them on a machine you control; nothing here needs a network connection.
- Make a key.
gpg --full-generate-keywalks you through the choices interactively. Modern GnuPG offers both RSA and elliptic-curve options; either is a reasonable answer, and the elliptic-curve keys are smaller and faster with no practical downside for this use. Give it a real expiry rather than "does not expire", and give it a passphrase you can actually remember, because there is no recovery path for one you cannot. - Look at what you made.
gpg --list-secret-keys --keyid-format=longshows the bundle from the previous section: primary key, subkeys, capabilities in square brackets, and the user ID you typed.gpg --fingerprintprints the forty characters that identify it. - Export the public half so people can use it.
gpg --armor --export you@example > mykey.asc. The--armorflag writes printable text rather than binary, which is what lets a key be pasted into a market profile or a forum post. This file is meant to be public; there is nothing sensitive in it. - Import somebody else's public key.
gpg --import theirkey.asc, then immediatelygpg --fingerprint their@exampleand compare against a copy you obtained a different way. An import you have not fingerprint-checked is a key you have stored, not a key you have verified. - Sign something so others can check it came from you.
gpg --clear-sign notes.txtwraps the readable text in a signature block, which is the right form for anything a human is going to read.gpg --armor --detach-sign release.tar.gzinstead produces a separate.ascfile, which is the right form for a binary or anything you do not want altered by being wrapped. - Encrypt a message to somebody.
gpg --armor --recipient THEIR_FINGERPRINT --sign --encrypt message.txt. Address the recipient by fingerprint rather than by email, so you cannot be silently pointed at a second key that shares the name. Adding--signmeans the message is both private and attributable, which is usually what you want. - Read what somebody sent you.
gpg --decrypt message.txt.asc. If the sender signed it, the output includes the signature result alongside the plaintext, so you learn who wrote it in the same step as reading it. - Prepare for the day it goes wrong.
gpg --output revoke.asc --gen-revoke YOUR_FINGERPRINTproduces a revocation certificate now, while you still can. Recent GnuPG versions generate one automatically at key creation and leave it in your configuration directory. Either way, store it somewhere separate from the key itself, because its entire purpose is to be usable at a moment when the key is not.
torhaven safety note
Notice which of those steps involves the internet: none of them. Key generation, signing, verification and decryption are all local computation. A workflow that requires you to paste anything into a website to "check a signature" has moved the one operation you were trying to control onto somebody else's machine, and there is no reason to accept that when the tool runs perfectly well on yours.
Verifying somebody else's signature is the operation you will run most often, and it has enough detail around reading the output that torhaven gives it its own treatment inside the verification routine guide, where it sits next to the moment it actually matters.
Why gpg cannot tell you a key is real
Here is the gap that trips up nearly everyone who learns the commands before the model. gpg can tell you, with certainty, that a signature was produced by the holder of a particular key. It cannot tell you anything at all about whether that key belongs to the person or project whose name is printed next to it. Those are two different questions, and only the first one is mathematics.
The second question has never had a clean answer, and it is worth being honest about the history rather than presenting a system that works better in diagrams than in practice.
The web of trust, and why it mostly did not happen
The original design was social: you meet someone, check their fingerprint in person, and sign their key to record that you did. Enough of those signatures and a stranger's key could be validated through a chain of people who had each checked the next. It is an elegant idea that assumed a community small enough to physically overlap, and at any larger scale it produced sparse, stale chains that could not answer the question most people were actually asking. You will still see its machinery in gpg's output — ownertrust prompts, validity markers — and you can use it, but almost nobody's real security rests on it.
Key servers hold keys; they do not vouch for them
The traditional key server network accepts uploads from anyone and verifies nothing about them. A key carrying any name and any email address can be published there by a party with no connection to either. Worse, the older servers also accept third-party signatures appended to somebody else's key, which has been used to bloat a key so badly that clients choke on downloading it. Newer key servers address parts of this by confirming control of an email address before publishing it and by discarding third-party signatures entirely — a real improvement, and still not a claim that the human behind the address is who you think.
What to do instead, in practice
Use first contact deliberately. Get a fingerprint through a channel that is independent of the one you are about to use the key on, pin it, and treat any later change as an event rather than an inconvenience. gpg supports this directly: gpg --lsign-key FINGERPRINT records locally that you personally checked, without publishing that opinion to anybody. It is a small thing that changes what the output means — afterwards, the "this key is not certified" warning stops appearing on that key, so seeing it again on a key you thought you had checked becomes a signal rather than background noise.
The uncomfortable summary: PGP moves your trust problem, it does not dissolve it. What it gives you in exchange is enormous, though, and easy to undervalue. You go from having to trust every link, every server and every intermediary in an open-ended chain, to having to check one fingerprint once. That is a trade worth taking, and it only pays out if you actually make the check.
PGP as a market login factor
The most common place a new reader meets PGP is not a signed announcement but a login screen. Many onion services offer, and some require, PGP as a second factor, and the mechanism is worth understanding because it is frequently described in ways that promise more than it delivers.
The flow is short. You paste your public key into your account profile once. From then on, when you log in with your username and password, the service generates a random string, encrypts it to your registered public key, and shows you the resulting block. You decrypt it locally and paste the string back. Getting in therefore requires something you know and something only your secret key can open.
What it genuinely protects
A stolen or guessed password stops being sufficient on its own, which is the entire point of a second factor and a real gain. It is also unusually well matched to this environment, because it needs no phone number, no app, no clock synchronisation and no third party — three of which are things you would rather not introduce to an anonymous account.
What it does not protect, despite the common claim
You will read that PGP two-factor authentication defeats phishing, because a fake site cannot produce a challenge you can decrypt. This is not right, and believing it is actively dangerous. A phishing page that sits in front of the real service can simply pass your login through, take the genuine challenge the real service issues, and show it to you; you decrypt it, hand the answer back, and the page uses it to open a session it controls. The cryptography worked perfectly and you were still relayed. What actually protects you from that case is the same thing as always: knowing that the address in front of you is the right one before you type anything into it.
The linkage nobody mentions
Registering a key on a service ties that key to that account permanently, in whatever records the service keeps. Using the same key on a second service ties the two accounts to each other. Using a key you have also attached to a real name, a clearnet project, or a key server entry ties all of it together in a way that no amount of care taken afterwards can separate. If a key is going to be used in a context you want kept apart from your other contexts, generate a key for that context and use it nowhere else. This is cheap to do at the start and impossible to fix later.
Key hygiene that actually matters
Most PGP advice lists a dozen precautions of wildly different value. These are the ones that change outcomes.
Put a passphrase on the secret key, and understand what it does
Your secret key lives on disk in your configuration directory. A passphrase means that a copy of that directory — taken by malware, by someone with the machine, or out of a backup you forgot was syncing — is not immediately usable. It does not protect you while the machine is running and compromised, because the key gets unlocked in memory to be used. Treat it as protecting the key at rest, which is the case it genuinely covers.
Back up the secret key and the revocation certificate separately
These two things fail in opposite directions. Losing the secret key means losing every message encrypted to it and any ability to sign as yourself again. Losing the revocation certificate means that if the key is ever compromised you cannot cleanly announce it. Storing both in the same place means one incident takes both. Store them apart, offline, and check occasionally that you can still read them.
Keep the configuration directory private
On a Unix-like system the .gnupg directory should be readable only by you. gpg will complain loudly if it is not, and that complaint is worth acting on rather than silencing, because a world-readable secret keyring on a shared machine is not a subtle problem.
Do not decrypt on a machine you would not trust with the plaintext
Decryption puts the message in memory on whatever computer runs it. If you would not want that machine to have the contents, the encryption did not help — you have simply moved the exposure from the wire to the endpoint. For anything genuinely sensitive, an amnesic system that starts clean at every boot is the meaningful answer, not a more careful setup on the same machine.
Never paste a secret key anywhere, for any reason
There is no legitimate workflow in which a service, a helper site, or a person needs your secret key. Blocks of key material look similar at a glance, and the difference between BEGIN PGP PUBLIC KEY BLOCK and BEGIN PGP PRIVATE KEY BLOCK is one word in a header people skim past. Read that header every single time before you paste anything.
Sign with the key people expect, not whichever is convenient
If you have several keys, gpg will use a default that may not be the one your correspondents have. Specify it explicitly with --local-user FINGERPRINT rather than assuming. A signature from an unexpected key reads to a careful recipient exactly like an impersonation attempt, and to a careless one like a reason to import a key they should not.
Common mistakes
Three errors undo the whole point of PGP. The first is trusting a key because it has the right name on it, without checking the fingerprint. The second is treating an old bookmark as permanent, when keys rotate and services get seized. The third is clicking a link instead of copying the address as text, which keeps the habit of acting on whatever is put in front of you. Each of these turns a strong tool back into a hopeful guess.
Recovering from a lost or leaked secret key
If a secret key is lost with no backup, any address or signature tied to it can no longer be signed as that identity again — there is no recovery process, which is the same trade-off that makes the key trustworthy in the first place. If it leaks instead of being lost, publish a revocation certificate if you generated one in advance, and treat every signature made with that key as compromised going forward, not just future ones.
Why "I'll verify it later" defeats the purpose
Deferring the fingerprint check until after you have already acted on an address — opened it, logged in, sent funds — removes the one property that makes verification useful: catching a problem before it costs anything. A check run after the fact can confirm you were wrong, but it cannot undo what already happened. This is why the guides on torhaven place verification as step one, never as a follow-up.
Common torhaven questions
Is PGP the same as encryption?
Encryption is one thing PGP does. The other, and the one that matters most on Tor, is signing: proving that a message or an address really came from the holder of a known key.
Do I need PGP just to read guides?
No. You need it before you act on anything that has to be authentic, such as an onion address or a vendor message. Reading a page costs you nothing and needs no keys.
What is a fingerprint?
A fingerprint is a short, fixed-length summary of a public key. Comparing fingerprints through a second channel is how you confirm a key is the right one before you trust anything it signs.
Can I lose access if I forget my passphrase?
Yes. There is no reset button. If you lose the secret key or its passphrase, anything encrypted only to that key stays unreadable, so back up the key and keep the passphrase somewhere safe.
Should I upload my public key to a key server?
Only if you want it findable, and knowing that publishing it links the key's user ID to everything else that key ever touches. A key server stores keys; it does not vouch for them, and traditional servers accept uploads from anyone under any name. Handing a fingerprint directly to the people who need it is a perfectly normal alternative and leaks considerably less.
Is RSA or elliptic curve the right choice when generating a key?
Either is fine for this purpose. Elliptic-curve keys are much smaller and faster, which matters when you are pasting a public key into a form or working on modest hardware. Very old software occasionally only understands RSA, so if you need to interoperate with something ancient, that is the reason to pick it — not a security difference you would notice.
Someone sent me a key that matches the name I expected. Is that enough?
No. The name and email inside a key are free text typed in by whoever generated it, and nothing in the format checks them. A key claiming any identity at all can be produced in seconds. The forty-character fingerprint, confirmed through a channel independent of the one that delivered the key, is the only part that identifies anything.
My key is about to expire. Have I lost everything?
No, as long as you still hold the secret key. Expiry is a property you set and can extend with gpg --edit-key followed by the expire command. An expired key can still decrypt old messages; what stops is other people's software treating new signatures from it as current. Extend it deliberately rather than removing the expiry, since the expiry is doing useful work.
Why torhaven treats PGP as the second thing to learn
torhaven's opening sequence is deliberate: first understand what Tor hides, then learn PGP, then apply both to a real onion address and a real market profile. This torhaven guide sits second because everything that follows it — the deposit-verification torhaven guide, the Torzon profile — assumes you already understand the difference between encrypting and signing that this torhaven page just walked through.
What torhaven's other guides borrow from this one
Every time a later torhaven guide says "check the signature" or "confirm the fingerprint through a second channel," it is leaning on the vocabulary this torhaven page just built. torhaven does this on purpose rather than re-explaining PGP from scratch on every page — a torhaven guide that repeated itself constantly would be harder to trust, not easier, because the reader could never be sure which copy was current.
Why torhaven put the worked example here instead of in the address guide
The worked example above uses a Nexus address rather than a market this torhaven guide has actually profiled, and that is deliberate: this torhaven page teaches the mechanism, not a specific claim about a specific project. When the same worked-example habit gets applied to something torhaven has actually researched, that happens in the Torzon profile instead, where the stakes and the sourcing are both real.
More torhaven guides
PGP is the skill; the next two guides put it to work on the two things that actually depend on it, an onion address you are about to trust and a specific market torhaven has profiled.