If you haven’t read my Secure PGP Primer or Questions to ask before setting up PGP posts, now would be a good time to do so.
Also, in this guide, we’re going to use examples based on the Free Software Foundation version, GnuPG (GPG). But understand that for the purposes of this discussion, PGP and GPG are the same thing.
To ensure that you have everything you need to continue, run gpg --version. You’ll probably see something like this:
gpg (GnuPG) 2.1.1
libgcrypt 1.6.2
Home: ~/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
This tells you exactly what ciphers, digests, etc you have available. If there is something missing, you may want to upgrade your GPG agent or libgcrypt.
Overview
We’re going to create an identity that will be shared between a desktop and a laptop. We’ll then make use of PGP’s subkeys to ensure that if the laptop is stolen or compromised, the owner can issue revocation certificates against the keys used by the laptop. This prevents the compromised keys from being used to impersonate the owner, without the need to revoke the master identity.
Step 1: Prefer the best encryption
Edit your ~/.gnupg/gpg.conf file, and make sure you have the following settings:
personal-digest-preferences SHA512
personal-cipher-preferences TWOFISH
personal-compress-preferences ZIP
default-preference-list SHA512 SHA384 SHA256 SHA224 TWOFISH AES256 AES192 AES CAST5 ZIP ZLIB BZIP2 Uncompressed
cert-digest-algo SHA512
The personal-* lines tell GPG how you want to encrypt your own data. The default-preferences-list tell GPG how you prefer to communicate with others. It’s not immediately obvious, but default-preference-list is included in your public key so that other users know how you want to receive messages. They can then reconcile that with how they would prefer to send messages, and you both communicate in a mutually agreeable way.
For example, you want to encrypt a message to Bob, but Bob doesn’t support Twofish. GPG will encrypt the data using the highest cipher that you both support. You can override this by adding cipher-algo <WHATEVER>, and it will force encryption using your chosen cipher; but then Bob will have no way to read it, short of adding support for your cipher. You may want to consider whether or not that’s a good idea.
Step 2: Generate the master keypair
From a terminal on the desktop, run gpg --expert --full-gen-key to get an interactive session for generating your key. The --expert parameter will give you some additional options. You’ll be asked several questions:
-
What kind of key do you want? RSA for both signing and encrypting is the way to go right now. Use the maximum allowed 4096 bits for the master key.
The master key will be used for for signing and certifying, and GPG will generate a subkey for encrypting. Make sure both keys are using the maximum key length of 4096 bits. -
When should the key expire? There are a number of thoughts on this. Some people say it should be a matter of days, others a matter of years. The expiration date can be thought of as a “dead-man’s switch;” after a certain period it can no longer be used. So if you lose your private key or something and have no way to revoke the public key, the expiration date will do that for you.
The nice thing is that you can extend the expiration date after it’s been set, so it’s not like you really need to set some far off date. A good approach is to set the expiration date out a year. Then you can set up a calendar reminder to yourself in 11 months to extend the expiration date. Keep in mind that if you use an expiration date, you’ll need a way of regularly informing users of extensions. This may mean that you need to use a keyserver. -
Your real name. This is the part where GPG is going to initialize your identity. There is some reason to think this part through. There are some cases where an alias would be ideal. For example, if you’re a dissident trying to communicate to a journalist, and you want PGP to sign and encrypt communications. An alias would protect you in the event that the journalist was compromised; if they don’t know who you are, then they can’t give you up to the authorities.
Alternatively, if you plan on using PGP signatures in a professional context, like committing code or participating in discussions, you may want to use your real name so that your contributions can be appropriately credited to you. -
Email address. Same as before; make sure you use something appropriate to how you plan to use the keys. Remember that you can have multiple master keypairs on your GPG keyring, so you could have one for professional contexts and one for subversive or private contexts. Segregating your identities is not only possible, but it is a smart move.
-
Comment. Don’t include one unless you have a really good reason. If this is for internal business communications, there is a case that the comment should be something like your job title. But avoid things like “I am the penguin of doom!” The personal details you include in this part of the setup process will become a part of the public key you’re about to distribute; that means that whatever you include in this field will be valid until the key expires, is updated, or is revoked. You don’t want that penguin of doom quip following you around, or forcing you to update/revoke the key once it gets tiresome. Best option is to leave this blank.
-
Passphrase. You have the option to encrypt your private key with a passphrase. Do this; use a passphrase that is long but easy to remember. This is a defense against someone who has gained access to your private key; they’ll need this passphrase to unlock the private key in order to decrypt messages made with the public key.
-
Entropy! During this phase, GPG will need to generate entropy in order to make the RSA keypair as random as possible. The more random interaction you have with the computer during this time, the better. I like writing random things to the disk, so I’ll open up another terminal and run:
cat /dev/urandom| tr -dc 'a-zA-Z0-9' | fold -w 10 2>&1 >> ~/Desktop/random
In another terminal, I’ll run:while [ 1 ]; do cat /dev/null > ~/Desktop/random; sleep 2; done</br />
The first line writes a bunch of random text to a file, while the second line clears the file out every two seconds to keep it from getting too big. Then I’ll move the mouse around and mash away on the keys in a text editor untilenough entropy has been generated to make secure keys.
At the end of this process, gpg will have added a new set of keys to your keyrings. Check them out with:
$ gpg --list-keys
/home/you/.gnupg/pubring.gpg
----------------------------
pub rsa4096/9B3FCFDB 2014-08-06
uid Your Name <[email protected]>
sub rsa4096/534C657B 2014-08-06
Step 3: Create a master revocation certificate
If the master keypair is lost or stolen, you are hosed. For one, you can’t decrypt messages sent to you (although anyone who has compromised the key certainly can), and you can’t prove to people that the identity is bad. Revocation certificates are the way to handle that. Generate one for your master keypair like so:
$ gpg --gen-revoke [email protected] > master-revocation-cert
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here)
Your decision? 0
Enter an optional description; end it with an empty line:
>
Reason for revocation: No reason specified
(No description given)
Is this okay? (y/N) y
ASCII armored output forced.
Revocation certificate created.
This will place your master keypair’s revocation certificate into a file called master-revocation-cert. Put this someplace safe! Print it out, or copy it to an encrypted USB drive, then shred or srm the file. Anyone who comes across it can render your master keys unusable.
Step 4: Create a signing subkey for the laptop
From your desktop where the master key resides, use gpg --edit-key [email protected] to edit the key in the gpg console:
gpg> addkey
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
Your selection?
Generate a signing key, again using the RSA 4096 cipher with an annual expiration date:
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Is this correct? (y/N) y
Really create? (y/N) y
The system will spin its wheels for a bit, generating the new signing key. Once completed, you’ll see something like this:
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
pub rsa4096/9B3FCFDB
created: 2014-08-06 expires: 2015-08-06 usage: SC
trust: ultimate validity: ultimate
sub rsa4096/534C657B
created: 2014-08-06 expires: 2015-08-06 usage: E
sub rsa4096/FFAC352D
created: 2014-08-06 expires: 2015-08-06 usage: S
[ultimate] (1). Your Name <[email protected]>
Finally, save the changes:
gpg> save
$
You now have a master keypair with two subkey pairs:
rsa4096/9B3FCFDB: This is the master keypair, used for signing and certifying. It remains on the desktop.rsa4096/534C657B: This is an encryption subkey pair that will be used by the desktop and the laptop.rsa4096/7E235F52: This is a signing subkey pair that will only be used by the laptop.
Step 5: Export keys to the laptop
Now that we have generated all of the necessary subkeys, it’s time to put them on their respective devices. This involves exporting the master keypair from the desktop to the laptop, then removing the master secret key from the laptop.
From the desktop, export the public and private keys from the master keypair:
gpg --armor --export [email protected] > master-public-keys
gpg --armor --export-secret-keys [email protected] > master-secret-keys
This will create two files, one for the public keys and one for the secret keys. Using a secure means (encrypted USB, SSH over ad hoc network between laptop and desktop, whatever), transfer these files on to the laptop. Then, from the laptop, run:
gpg --import master-public-keys
gpg --import master-secret-keys
This will put a copy of the master keypair on to the laptop. The dangerous key here is the master signing key; with this, a user can create new subkeys, issue revocation certs, and more. So we’re going to remove it, using a sort of backwards method. We’ll export the subkey pairs, delete the secret keys, then re-import the subkey pairs.
This approach will give us a keyring that has everything we need to sign and encrypt from the laptop, without needing to access the master signing key:
gpg --export-secret-subkeys [email protected] > secret-subkeys
gpg --delete-secret-key [email protected]
gpg --import secret-subkeys
You can verify that the keyring no longer has the private signing key by running:
$ gpg -K
/home/you/.gnupg/pubring.gpg
----------------------------
sec# rsa4096/9B3FCFDB 2014-08-06
uid [ultimate] Your Name <[email protected]>
ssb rsa4096/534C657B 2014-08-06
ssb rsa4096/7E235F52 2014-08-06
The # by sec indicates that the associated private key is missing. So it has been purged from the laptop! We can check that the laptop can still sign with a simple command:
$ echo "Testing" | gpg --armor -s | gpg --verify
gpg: Signature made Wed 06 Aug 2014 11:53:25 PM MST using RSA key ID 7E235F52
gpg: Good signature from "Your Name <[email protected]>" [ultimate]
Finally, we clean up:
srm secret-subkeys
This will securely delete the subkey private keys that we had previously exported. The laptop is now hardened against PGP impersonation.
What happens now?
Should the laptop get stolen or compromised, you’ll need to revoke the subkeys. From the desktop, this is a relatively simple matter:
$ gpg
gpg> key 1
pub rsa4096/9B3FCFDB
created: 2015-08-06 expires: 2015-08-06 usage: SC
trust: ultimate validity: ultimate
sub rsa4096/534C657B
created: 2015-08-06 expires: 2015-08-06 usage: E
sub* rsa4096/7E235F52
created: 2015-08-06 expires: 2015-08-06 usage: S
[ultimate] (1). Your Name <[email protected]>
gpg> key 2
pub rsa4096/9B3FCFDB
created: 2015-08-06 expires: 2015-08-06 usage: SC
trust: ultimate validity: ultimate
sub* rsa4096/534C657B
created: 2015-08-06 expires: 2015-08-06 usage: E
sub* rsa4096/7E235F52
created: 2015-08-06 expires: 2015-08-06 usage: S
[ultimate] (1). Your Name <[email protected]>
pgp> revkey
Do you really want to revoke the selected subkeys? (y/N) y
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
Your decision? 1
Enter an optional description; end it with an empty line:
> Laptop was stolen
>
Reason for revocation: Key has been compromised
Laptop was stolen
Is this okay? (y/N) y
pub rsa4096/9B3FCFDB
created: 2014-08-06 expires: 2015-08-06 usage: SC
trust: ultimate validity: ultimate
The following key was revoked on 2014-08-06 by ? key 9B3FCFDB Your Name <[email protected]>
sub rsa4096/534C657B
created: 2014-08-06 expires: 2015-08-06 usage: E
The following key was revoked on 2014-08-06 by ? key 9B3FCFDB Your Name <[email protected]>
sub rsa4096/7E235F52
created: 2014-08-06 expires: 2015-08-06 usage: S
[ultimate] (1). Your Name <[email protected]>
gpg> save
This will update your master public key with information that the subkeys on the laptop have been compromised. You’ll need to create a new encryption subkey for the desktop. You’ll also need to send the updated public key to your contacts directly or via keyserver for the revocation to be complete. It’s annoying, but at least new subkeys can be generated, and your PGP identity is not compromised.
Conclusion
I hope you found this post (and the others in the PGP series) helpful. Now that you have a nice, secure PGP identity configured, why not get my key from the contact page and send me a message?