🔏 Advanced PGP Guide

This builds on the basics in the PGP verification guide, so start there if key generation itself is new. For darknet use specifically, generate a 4096-bit RSA key pair (Ed25519 is faster and smaller but has weaker support across older clients, so RSA-4096 remains the safer default for compatibility) with the name and email fields set to your market pseudonym — never anything that ties back to a real identity, since the key's metadata is as much a fingerprint as the key itself. Set an expiration of one to two years rather than "never," which forces a deliberate renewal instead of a key that quietly outlives its usefulness, and generate the revocation certificate in the same sitting you create the key, not later — if you ever need to revoke, it's because something's already gone wrong, and that's the worst possible moment to discover you never made the certificate. Store both the private key and the revocation certificate on encrypted storage only, and never let the private key touch a keyserver; keyservers are for public keys, and a private key on one is a private key that's effectively public.

A digital signature proves two separate things at once: that a message came from whoever holds a specific private key, and that not one byte of it changed after signing — tamper with a signed message and the signature simply fails to verify, with no ambiguity about it. Sign with gpg --clearsign message.txt from a terminal, or with the Sign function in Kleopatra if a GUI is more your speed; both produce the same result. This is what lets a vendor and buyer recognize each other across sessions, and even across different markets, without either side needing a shared platform account to do it — the key is the identity, not the login. It's also the exact mechanism behind every operator canary and address-change announcement worth trusting: verify the signature on any claimed market announcement before treating it as real, since an announcement that reads correctly but doesn't verify is worth exactly nothing.

Use multiple-recipient encryption for anything you'll need to read again later — a message encrypted only to a vendor's key is unreadable by you the moment you send it, which is rarely what you actually want for order-related conversations you might need to reference during a dispute. Configure your client to always encrypt to your own key alongside the recipient's (in gpg.conf: encrypt-to YOUR_KEY_ID), so every sent message stays in your own readable archive. For anyone doing enough volume to justify it, subkeys let you handle day-to-day signing and encryption without ever touching the master key, which stays offline and only comes out to certify new subkeys or issue a revocation — a compromised subkey is revocable and replaceable, a compromised master key is a much deeper problem. And treat public keyservers as a last resort rather than a default: for darknet purposes, exchanging keys directly through a channel you already trust avoids handing a public, permanent, and searchable record of your key's existence to infrastructure you don't control.