When I (@curtiswallen) was first learning how to use PGP encryption I followed a bunch of different guides online, but still felt so confused. They taught the bare minimum for generating a key, and then didn't give any real world advice on how to use it or how to actually encrypt anything. After learning a little more and gaining some experience, I also realized that those guides often don't focus on some of the most important aspects of encrypted communications. Namely, that encrypting email isn't enough on its own to provide security. In this guide I've tried to distill my best advice in a simple and concise format. Hopefully you will find it useful.
PGP ("Pretty Good Privacy") is a piece of software created by Phil Zimmermann in 1991 to encrypt digital information. In 1997, realizing an open standard for PGP encryption was needed to prevent the technology from being locked down by patents, Zimmermann and his team drafted the OpenPGP standard. In 1999, the Free Software Foundation released version 1 of the GNU Privacy Guard (GPG), an OpenPGP standards compliant encryption program. Most uses of PGP today are via GnuPGP (GPG).
PGP is really good at encrypting data. If used correctly, there should be no way for anyone unintended to determine the content of information encrypted using PGP.
However, law enforcement can force a user to surrender her or his passwords/keys, or can use an array of different methods to discover the content they're looking for. Because the encryption itself is so strong, an adversary will rarely focus on breaking it. They will instead look to exploit weaker links in the chain: passwords, keys, plaintext drafts/copies on a target's computer, or the sender/recipient herself.
Or, in some cases, the content isn't even needed. Metadata analysis can often be enough to blow a journalist/whistleblower/etc.'s cover.
PGP is an important and powerful tool, but it can't prevent you from fucking up in the thousand other ways your adversary is hoping you will. Communications security requires more than encryption. You need to be alert; you need to be smart.
A quick note: many people use Mozilla's Thunderbird email client with the Enigmail plug-in to manage pgp encrypted email. I have experienced a few quirks in the past with this set-up that have led me to use a different procedure. It is a bit less convenient, but I believe it is ultimately safer. Of course, feel free to explore other options and do whatever you'd like. :-)
First install the necessary tools and configure everything properly.
OS X: https://gpgtools.org/
Windows: http://gpg4win.org/
GNU/Linux (Debian, Ubuntu, Mint, Fedora, etc): GNUPG comes with most Linux distros, but if you don't have it - https://www.gnupg.org/download/index.html
I'll briefly explain what the suggested configuration changes are below. If you'd like to learn more, please read Riseup's excellent PGP best practices guide https://help.riseup.net/en/security/message-security/openpgp/best-practices.
Changes that will be made in the GPG configuration:
The recommended settings have been incorporated into a config file at Jacob Appelbaum’s duraconf “collection of hardened configuration files," which you can download here (right-click, "save as"): https://raw.githubusercontent.com/ioerror/duraconf/master/configs/gnupg/gpg.conf
Also download this file: https://sks-keyservers.net/sks-keyservers.netCA.pem It is a digital certificate that will allow you to use the recommended sks hkps encrypted keyserver pool. Save it somewhere that makes sense to you. I have mine (on GNU/Linux) saved at "/usr/local/etc/ssl/certs", but you can put it anywhere. Remember where you saved it, and make sure it's somewhere where it won't easily/accidentally be deleted.
Edit the config file so the hkps cert location (found on line 52, after "keyserver-options ca-cert-file=") is pointing to the location where you saved your certificate file. I also noticed that Applebaum's config has a different filename for the certificate. Make sure you change it to "sks-keyservers.netCA.pem".
Replace your old gpg.conf file with the new one.
On GNU/Linux and MacOS it should be here: ~/.gnupg/gpg.conf
On Windows should be here: AppData\GnuPG\
The easiest way to move the config file in GNU/Linux or MacOS (assuming you downloaded it to your Downloads folder) is in the Terminal using the command: "sudo mv -f Downloads/gpg.conf ~/.gnupgp/"
If you don't have Tor already, you should also download that. If you're interested in PGP encryption, you will also likely be interested in Tor, and we'll need it for securely refreshing keys.
And now that you have GPG installed, you should verify your Tor download. This will ensure you actually downloaded the proper Tor Browser Bundle and not a cleverly spoofed piece of malware/something else. Instructions for verification can be found at the bottom of this guide.
Torsocks is necessary to run Parcimonie (below).
https://code.google.com/p/torsocks/
You should verify your Torsocks download before installing.
Parcimonie is a tool to refresh the keys on your keyring one at a time at random intervals to make timing correlation harder for an attacker. The version of Parcimonie referenced here was rewritten as a single bash script by Etienne Perot.
You can download it here (right-click, "save as"): https://raw.githubusercontent.com/EtiennePerot/parcimonie.sh/master/parcimonie.sh
Save it anywhere it won't be easily deleted. Maybe, "Documents/PGP/Parcimonie/"
Make sure Tor is running and Torsocks is configured, and then run the script from the terminal:
bash Documents/PGP/Parcimonie/parcimonie.sh
Let it run in the background and it will securely refresh your keys. Of course, you probably don't have any yet, so you can wait and do this later.
Open the terminal, and type in:
gpg --gen-key
After you press the enter key, it will say:
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection?
Type 1 (or whichever number corresponds to "RSA and RSA", if yours is different) and press the enter key.
It will then say:
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)
Type 4096 (we want to use the longest keysize possible) and press the enter key.
It will then say:
Please specify how long the key should be valid.
0 = key does not expire
= key expires in n days
w = key expires in n weeks
m = key expires in n months
y = key expires in n years
Key is valid for? (0)
Type 2y and press the enter key. Then set a calendar reminder for a little less than two years from now so you remember when your key is set to expire. That way you can renew or revoke it, depending on the circumstances. Confirm you want it to expire in two years by typing "y" and pressing the enter key.
It is a good idea to set an expiration date, because it acts kind of like a "dead man's switch." If for some reason you forget your password, or your key is compromised, and you don't have your revoke cert, the certificate will automatically be revoked after the expiration date. This lets other users know to stop using it. And if your key expires accidentally, you can still renew it. So it's a win/win.
It will then tell you that you need a user ID consisting of your real name, email address, and a comment. You can use whatever name you want, whatever email address you want (or no email address), and you should not input a comment.
Depending on your use, it may be a good idea to use your real name, or it may not.
When working on this guide, I generated a new key and entered the ID parameters as follows:
Real name: Mr. Cool Guy
Email address: [email protected]
Comment:
You selected this USER-ID:
"Mr. Cool Guy funtimeemail@coolemail.xxx"
I can use that key with any email address I want to. Keys are not bound to the email addresses listed in their user IDs. This is important. The user IDs are simply used for identification.
So like I said before, choosing an ID depends on who you are. If you're a journalist, or require public facing communications, it might be a good idea to use your real name/email address to make it easier for people to find/contact you. If you're communicating with a small network of clandestine operators, you probably shouldn't use any information with any actual connection to you or your group.
After you enter your ID information, it will ask you to confirm. Type "o" and then press the enter key.
It will now ask for your password. I recommend using a long passphrase with multiple words. Something like: "nV3r go!ng 2g1ve y0u uP", mixing caps, numbers, and symbols.
Bruce Schneier has a nice blog post on choosing secure passphrases: https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html
I recommend reading that and coming up with a password that is easy for you to remember but extremely hard for an adversary to guess. This goes without saying, but... DO NOT FORGET YOUR PASSWORD.
It will ask you to enter your password twice to ensure you remember it/didn't type it wrong, and then your key will generate. :-)
After your key is generated, you should generate a revocation certificate by typing:
gpg --gen-revoke --armor --output=RevocationCertificate.asc [email protected]
Replace the email address with whatever you used for your key.
DO NOT OPEN THE CERT BY DOUBLE CLICKING or you may revoke the key you just generated. Not the end of the world, but annoying. Right click the file, open it in a text editor, and print it out. Once you have it printed out, put it somewhere safe. Send it to your mom. Don't lose it. Don't let anyone nefarious get a hold of it.
If someone gets ahold of your revocation certificate they can't use it to decrypt/encrypt anything. The worst they can do is revoke your key, which is simply annoying. But you may need it later if the key/password is compromised and you need to let others know the key is no longer safe to use. So keep it safe.
Once the revocation certificate is printed and secure, delete the file from your computer.
First you'll need someone to contact, and you'll need to import their key to your keyring. The easiest way to get started is for you to email me. Type this into the terminal:
gpg --recv-keys '7E75 9D36 322A D50C 0932 F78A C260 DFF1 79BB D858'
When you press enter it should give you confirmation that the key has been added and reveal the email address to use.
An important note on using public keys: it is important to verify the key you are adding/using actually belongs to the person you wish to communicate with. To quote from Alan Eliasen's phenomenal (and in-depth) PGP guide: "Anyone can generate a public key for any e-mail address. Anyone can post that key to any key server. Only by verifying that the key really belongs to the person you think it does does it give you any security. Without this crucial verification, all that your cryptographic software does is ensures that bits weren't corrupted during transmission, and prevents casual observers from reading the message. It does not mean that you're talking to who you think you are. You could be talking to someone else entirely (a bad guy,) or you could be subject to a man-in-the-middle attack."
Now that you have my key, to compose a message type into the terminal:
gpg -R curtis -ea
"-R" (capital r) tells GPG to encrypt the message with the recipient "hidden." That means the metadata in the encrypted content will not indicate who the intended recipient is. This is a countermeasure against traffic analysis. (If you use a lowercase "r" instead, recipient metadata will be included.) "-e" is the command to encrypt, and "-a" is the command to produce ASCII output, so you can copy and paste it into an email.
After you hit enter, the input cursor will move down to the next line. Begin typing your message:
I got it working! One step closer to protecting my content online. :-)
When you've finished your message, press enter so you're on a new blank line, then press [CTRL+D] and you should see the encrypted text block ready to be copied and pasted into the body of an email.
A few things to keep in mind:
For other people to contact you, they'll need your public key. There are a handful of options for providing this. Again, your decision will likely be based on your security needs.
First, type into the terminal:
gpg --fingerprint
Press the enter key, and you should see all the keys in your keyring with their fingerprints. Locate your key with "sub" in the leftmost column:
uid [ultimate] Curtis curtiswallen@gmail.com
sub 4096R/0x142A8E8BFD311848 2014-07-30 [expires: 2016-07-29]
Key fingerprint = C83D FB24 4279 4E79 8472 9FCE 142A 8E8B FD31 1848
Copy your sub fingerprint, and use it to send your key to the server by typing:
gpg --send-keys 'C83D FB24 4279 4E79 8472 9FCE 142A 8E8B FD31 1848'
You should get a message saying something like:
gpg: sending key 0x4F071F6587C89BC3 to hkps server hkps.pool.sks-keyservers.net
There you go! Now, you can give out your fingerprint, and others can use it to add your key to their keyring and send you encrypted messages.
If the person you want to contact has a public facing key, you can encrypt your public key and send it to them.
Type into the terminal:
gpg --export -a 'fingerprint' // (replace fingerprint with your fingerprint)
After pressing the enter key, you will see a chunk of output starting with "-----BEGIN PGP PUBLIC KEY BLOCK-----". This is your full public PGP key. Copy and paste the entire thing, including the "BEGIN" and "END" lines in an email to whoever you want to send it to.
They can then enter the command "gpg --import" into their terminal, paste in your keyblock, press the enter key, and then [CTRL-D], to import it to their keyring.
You could also give them your key on an encrypted flash drive in person. Or print it out and have them write it down manually. Or any other number of face to face transfers.
Open the terminal, type "gpg", press enter, and then paste in the encrypted block. Upon successful entry of your password, the decrypted message will display in the terminal.
Let's say you want to be very safe about your communications. One potential procedure could go something like this:
Using this procedure, you have established a channel of communication that has no link to you or your initial contact person. You are now in a vacuum of two email adresses that have only ever contacted each other, using offline PGP keys that cannot be identified.
If you only ever connect from public networks behind Tor, keep your keys secure, and practice smart email hygeine (no subject, delete, delete, delete), you will have a fairly secure communications channel.
You could harden the system a little more by only using Tails OS booted from a USB drive, with a persistent volume for storing keys. If you do this, use a different boot drive for each computer, one for online and one for offline.
Another option for hardening the system would be to use CD-Rs instead of USB flash drives. A USB flash drive could be targeted with malware to exfiltrate data from the offline computer and then send it back to an attacker when the flash drive is plugged into an internet connected machine. CD-Rs are read only and prevent that problem. Each CD-R should be used one time and then destroyed.
If using the CD-R method, data transfer must become one way; nothing can ever be burned from the offline computer. This means you will have to use your online computer to encrypt outbound messages, rather than encrypting them on the offline computer and transferring them via USB. This trade-off warrants careful consideration. Having that key stored on your online computer creates a detectable link for an attacker. However, if the person you are communicating with is also using an offline computer and CD-Rs to decrypt the messages, and you're both careful not to link the keys to your real identities, this method provides a higher level of data security.
Obviously, downloading emails from public networks and then transferring messages back and forth from the offline computer is slow and annoying. Add in Tails and/or CD-Rs and it slows down even more. Most people probably don't need those levels of security, but that is the tradeoff you will constantly encounter trying to play this game: security vs. convenience.
This guide (except the previous section) is meant to provide a secure procedure for using PGP encryption within a "standard" environment; meaning an every day personal computer with the private key stored on the local drive. This is sufficient for most use cases, however some users will need/want a more secure set-up.
How secure do you need to be?
Only you can decide. :-)
Verifying downloads using PGP (Return to Tor section)
Underneath the link where you downloaded Tor you should see a small link that says: (sig). Right click, and save that file to the same directory you downloaded the Tor Browser Bundle .dmg/.tar.xz/.exe
First thing you need to do is import the key that signed the package. Erinn Clark signs all the Tor Browser Bundles. You can import her key (in GNU/Linux and/or MacOS) by opening the terminal and typing:
gpg --recv-keys '8738A680B84B3031A630F2DB416F061063FEE659'
Once you have Erinn's key, you can verify your download by using the "--verify" gpg command:
gpg --verify /Downloads/TorBrowser-3.6.3-osx-i386-en-US.dmg{.asc,}
The output should read:
gpg: Signature made [SIGNING DATE] using RSA key ID 63FEE659
gpg: Good signature from "Erinn Clark erinn@torproject.org"
gpg: aka "Erinn Clark erinn@debian.org"
gpg: aka "Erinn Clark erinn@double-helix.org"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 8738 A680 B84B 3031 A630 F2DB 416F 0610 63FE E659
The warning at the bottom is about trusting the the validity of the signature itself, not the verification of the download. It's basically saying, "The signature matches, but I'm not sure if we trust the signature." For now, you'll just have to trust it. Maybe someday you'll meet Erinn in person and you can verify the signature actually belongs to her.
Now that you know the Tor download is legit. Feel free to install Tor.
I am not familiar with the process on Windows, but Tor has their own guide here: https://www.torproject.org/docs/verifying-signatures.html.en It includes instructions for Windows, MacOS, and GNU/Linux.
A warm thank you to @thegrugq and @justintroutman for thoughts and insights while compiling this guide.