PGP Encryption Guide

PGP (Pretty Good Privacy) encryption is the foundation of secure communication on darknet platforms. It enables encrypted messaging that only intended recipients can read, plus digital signatures that verify message authenticity. Without PGP, you can't verify that mirrors are genuine, that vendor communications haven't been tampered with, or that your messages remain private.

This guide covers everything from initial setup to advanced usage, with practical steps you can follow regardless of your operating system.

How PGP Works

PGP uses asymmetric cryptography, meaning you have two mathematically related keys: a public key you share freely, and a private key you keep secret. Anyone can encrypt a message to you using your public key, but only your private key can decrypt it. Similarly, you can sign messages with your private key, and anyone with your public key can verify the signature is genuine.

This solves the key distribution problem of symmetric encryption. You don't need to secretly exchange passwords with everyone you want to communicate with - just publish your public key and keep your private key safe.

Encryption vs Signing

Encryption protects message confidentiality. An encrypted message appears as random characters to anyone who doesn't have the correct private key. Even if intercepted during transmission, the content remains protected.

Signing protects message integrity and proves authorship. A digital signature proves that a specific private key holder created or approved the message, and that the message hasn't been altered since signing. This is how you verify that mirror lists, announcements, and communications are genuine.

Key Components

Your PGP setup includes several elements:

• Key pair: Your public and private keys, mathematically linked
• Passphrase: A strong password protecting your private key file
• Key ID: A short identifier for your key (last 8 or 16 characters of the fingerprint)
• Fingerprint: A longer identifier used to verify key authenticity
• Keyring: Your collection of public keys from others you communicate with

GnuPG (GPG) is the free, open-source implementation of the OpenPGP standard. It's available for all major operating systems.

Windows

Download Gpg4win from the official website. Verify the cryptographic signature before installing. The package includes Kleopatra, a graphical interface for key management.

macOS

Install GPG Suite for a complete solution with Mail integration and a key management interface. Alternatively, install via Homebrew: brew install gnupg

Linux

Most distributions include GnuPG in their repositories. Install via your package manager:

• Debian/Ubuntu: sudo apt install gnupg
• Fedora: sudo dnf install gnupg
• Arch: sudo pacman -S gnupg

Tails OS

Tails includes GnuPG and the Seahorse key manager by default. No additional installation required.

Key Generation Steps

Open a terminal and run:

gpg --full-generate-key

When prompted, make these selections:

1. Key type: Choose RSA and RSA (default) or ECC (Ed25519) for modern systems
2. Key size: 4096 bits minimum for RSA (maximum security)
3. Expiration: Set 1-2 years; you can extend later if needed
4. User ID: Use your pseudonym only - no real name or identifiable email
5. Passphrase: Create a strong passphrase of 20+ random characters

Passphrase Best Practices

Your passphrase protects your private key file. Even if someone obtains your key file, they can't use it without the passphrase. Make it:

• At least 20 characters, preferably 30+
• Random, not based on words or phrases
• Unique to this key (never reused)
• Stored securely in an offline password manager

Exporting Your Public Key

After generation, export your public key to share with others:

gpg --armor --export your-email@example.com > publickey.asc

The --armor flag outputs in ASCII format suitable for copy-pasting into platform registration forms or messages.

Importing Someone's Public Key

Before encrypting to someone, import their public key:

gpg --import their-publickey.asc

Or paste the key block into a file and import that file.

Encrypting a Message

To encrypt a message for a specific recipient:

gpg --armor --encrypt --recipient their-email@example.com message.txt

This creates message.txt.asc containing the encrypted content. Only the recipient's private key can decrypt it.

Decrypting a Message

When you receive an encrypted message addressed to your public key:

gpg --decrypt encrypted-message.asc

Enter your passphrase when prompted. The decrypted content displays in the terminal or can be redirected to a file.

Command Line Encryption

For quick encryption without files:

echo "Your secret message" | gpg --armor --encrypt --recipient their-email@example.com

Copy the output block (-----BEGIN PGP MESSAGE----- through -----END PGP MESSAGE-----) to send.

Why Signature Verification Matters

Phishing attacks are common on darknet platforms. Attackers create fake mirror lists, impersonate administrators, and distribute malware disguised as legitimate software. Signature verification is your defense - a valid signature proves the message came from the claimed sender and hasn't been modified.

Verifying a Signed Message

When you receive a PGP-signed message or document:

gpg --verify signed-message.asc

GPG reports whether the signature is valid and who signed it. Only trust content with valid signatures from keys you've verified belong to the claimed party.

Verifying Software Downloads

Important software like Tor Browser includes detached signatures. Download both the software and its .asc signature file, then verify:

gpg --verify tor-browser.tar.xz.asc tor-browser.tar.xz

Trust Considerations

A valid signature only proves the message was signed by a specific key. It doesn't prove that key belongs to who you think it does. Verify key fingerprints through multiple independent sources before trusting important keys.

Backing Up Your Keys

Losing your private key means losing access to encrypted messages and your established identity. Create secure backups:

gpg --armor --export-secret-keys your-email@example.com > private-key-backup.asc

Store this backup encrypted, preferably in multiple secure physical locations. Never store unprotected private keys on internet-connected devices.

Key Expiration

Setting key expiration limits damage if your key is compromised. When a key expires, you can extend it if you still control it:

gpg --edit-key your-email@example.com
gpg> expire

Follow the prompts to set a new expiration date, then save and redistribute your updated public key.

Revoking Compromised Keys

Generate a revocation certificate immediately after creating your key:

gpg --gen-revoke your-email@example.com > revocation.asc

Store this securely. If your key is ever compromised, import the revocation certificate to invalidate the key.

• Using real identity in key: Your User ID should contain only your pseudonym, never real name or identifiable email
• Weak passphrase: A weak passphrase defeats the purpose of the private key protection
• No backups: Losing your private key without backup means starting over with a new identity
• Skipping verification: Encrypting to the wrong key or trusting unsigned messages defeats security
• Key reuse across identities: Using the same key for different personas links them together

Subkeys and Key Structure

A PGP key isn't a single key - it's a collection of related keys bound together. Your primary (master) key signs other components, including subkeys for encryption and signing. This structure allows you to rotate subkeys while maintaining your established identity.

Keep your primary key offline, used only for signing subkeys and other people's keys. Daily operations use subkeys that can be revoked and replaced if compromised, without destroying your entire key identity. This requires more initial setup but provides significantly better long-term security.

To generate subkeys:

gpg --edit-key your-email@example.com
gpg> addkey

Follow the prompts to create encryption or signing subkeys. Export only the subkeys for daily use, keeping the primary key in secure offline storage.

Web of Trust

PGP's web of trust model addresses the key authenticity problem. How do you know a public key actually belongs to who claims to own it? The web of trust lets you sign other people's keys to vouch for their authenticity, creating chains of trust.

If you personally verify someone's identity and key fingerprint, you can sign their key. Others who trust your judgment can then trust keys you've signed. As these signatures accumulate, a web of interconnected trust relationships develops.

For darknet usage, the web of trust has limitations. Signing someone's key publicly links you to them, which may not be desirable. Many users simply verify key fingerprints through multiple independent channels rather than building explicit trust relationships.

Key Servers and Distribution

Traditional PGP key servers let you publish and find public keys. However, key servers have significant problems: anyone can upload keys claiming to belong to anyone else, and once uploaded, keys can never be deleted.

For platform usage, most users share keys directly rather than through key servers. Post your public key on your profile, include it in signed messages, or share it through secure channels. This avoids key server complications while ensuring recipients get your actual key.

If you do use key servers, always verify fingerprints through separate channels before trusting retrieved keys. A key server response alone provides no assurance of authenticity.

Perfect Forward Secrecy Limitations

Standard PGP encryption has a significant limitation: if your private key is ever compromised, all messages ever encrypted to that key become readable. This contrasts with protocols like Signal that provide perfect forward secrecy (PFS), where key compromise doesn't affect past communications.

Mitigate this through key rotation - periodically create new keys and encourage correspondents to use your current key. Old keys can be revoked, limiting the exposure window. Some advanced PGP tools also support ephemeral subkeys that provide partial forward secrecy.

Metadata Considerations

PGP encrypts message content but not metadata. Headers showing who sent a message to whom, when, and approximate message size remain visible. For high-security scenarios, this metadata exposure may be unacceptable.

Platform messaging systems often handle this better than email, as the platform mediates all communications without exposing metadata externally. However, the platform itself sees all metadata, so trust in the platform matters.

"No Secret Key" Errors

This error means GPG can't find the private key needed for an operation - either decrypting a message addressed to you or signing something. Common causes include:

• Wrong keyring - you're using a different GPG home directory than where your keys are stored
• Key not imported - you need to import your private key on this machine
• Wrong key specified - the message was encrypted to a different key than you have
• Corrupted keyring - your keyring file may be damaged

Check which keys you have available:

gpg --list-secret-keys

Passphrase Problems

If you've forgotten your passphrase, there's no recovery option. The passphrase protects the private key file - without it, the key is useless. This is why secure passphrase storage matters from day one.

If you're entering the correct passphrase but it's rejected, check for keyboard layout issues, caps lock, or encoding problems if you used special characters. Some systems have different behavior for terminal input versus GUI applications.

Key Trust and Validity Warnings

GPG warns when you encrypt to keys that aren't marked as trusted. This is a safety feature - you might be encrypting to a fake key. If you've verified the key through other means, you can set trust:

gpg --edit-key their-email@example.com
gpg> trust

File Format Issues

PGP messages and keys come in two formats: binary and ASCII-armored (text). If you're having problems, make sure you're using the right format for your situation. The --armor flag produces ASCII output suitable for copy-pasting. Binary format is smaller but can be corrupted by email or text handling.

Version Compatibility

Different GPG versions and configurations may have compatibility issues. If a correspondent can't read your messages, check whether you're using compatible cipher preferences. Modern keys may use algorithms older software doesn't support.

Daily Communication Workflow

An efficient daily workflow minimizes friction while maintaining security:

1. Verify you're using the right identity/key for this communication context
2. Import any new public keys you need, verifying fingerprints
3. Draft your message in a text editor (not directly in encrypted form)
4. Encrypt the message to the recipient's key
5. Send through appropriate channels
6. Securely delete the plaintext draft

Receiving and Processing Messages

When receiving encrypted messages:

1. Save the encrypted message to a file
2. Decrypt using GPG, verifying the signature if present
3. Process the content as needed
4. Securely delete both the encrypted and decrypted files when done

Don't store decrypted messages longer than necessary. The whole point of encryption is preventing stored plaintext from being discovered.

Key Ceremony for New Identities

When creating a new identity that requires PGP, follow a systematic process:

1. Generate keys on a secure, preferably air-gapped machine
2. Create and securely store your revocation certificate
3. Export and back up your private key to secure offline storage
4. Export your public key for sharing
5. Test the key by encrypting and decrypting a test message
6. Document your key fingerprint for verification purposes