I have a confession to make.
I do not have an online identity. I have Twitter, Facebook (yeah I know) and this homepage, but still, my online presence is undermined by the fact that I or others cannot verify my identity.
The remedy to this is public-key cryptography1.
- About PGP
- Using GPG
- Creating the master key
Using GPG2, the OpenPGP-compliant3 cryptographic software suite, you are able to prove your identity online and that of others. The principle behind this is called the web of trust4, where users of OpenPGP-compatible software sign each others public signatures (keys) after having verified their identity. This is in contrast to X.5095, where a Certificate Authority, CA, is the sole party establishing the authenticity of users.
So in a way, PGP adheres more to the open source philosophy of decentralized mode-of-operation. Plus, the story of PGP is pretty bad-ass.
In this tutorial, we’ll refer to the OpenPGP specification as “PGP” and “GPG” as the free software implementation by the GNU Project.
Creating and managing PGP keys is not a straightforward matter. Many approaches exist and if you are a whistleblower, this tutorial probably does not meet your security standards. In fact, if there’s a chance you’ll be captured, tortured, or killed for the information you’ll encrypt, stop reading this tutorial and pray for the best. You are doing it wrong.
For others, I think this tutorial serves as a suitable middle ground for the pragmatic daily usage of PGP.
Creating the master key
Let’s get started creating your first PGP-based identity:
Pay attention to the fact that we’re using GPG v2.1 in this tutorial. The newest version prefers better hash algorithms.
Select the default
RSA and RSA for making keys for both signing and encrypting:
Next you will be asked to input the size for the RSA keys. We’ll use 4096 bits for the master key, since it is only meant for signing other keys. The subkeys we’ll use are used for encryption and decryption, so they are better off with a 2048 bit key size6.
Set an expiration time for your master key, in case you lose your revokation certificate and the master key is compromised. The downside is that you have to keep extending the lifetime of the key. The expiration time can be altered afterwards, even if a key has expired.
Input your real name and email. Do not, however, input a comment when prompted:
Next up, you have to come up with a passphrase for your master key. The Intercept has an insighftul article on the problems of passphrases and how to create robust ones (with Diceware).
After some dice rolling and as you have entered the passphrase, the master key will be generated. This master key IS your electronic identity, so the point is to handle it with care. Especially the private master key we’ll evacuate to a safe place later on in this tutorial.
The case is often that one has multiple computers (desktop, laptop) and wants to use the same GPG identity on all devices. One popular scheme for this is creating subkeys, which are then distributed. There are, however, some differing opinions78 on this approach and whether it is a sane model for the web of trust.
The alternative is to create master keypairs for every device and sign them with your ultra-secure master-master keypair.
In this tutorial, the approach of creating subkeys is chosen, mostly because it seems to be the more popular9 choice and has the advantage of accumulating trust for your single PGP identity.
Creating a revocation certificate
GnuPG version 2.1 automatically generates a revocation certificate. It will be located under
$GNUPGHOME/openpgp-revocs.d/. If you’re using an older version, be sure to generate one.
Store this revocation certificate in a safe place. The revocation certificate is short enough to be handily stored on paper.
Subkeys are your day-to-day keys for signing and encryption. Hence, we’ll generate a subkey to the very computer you are now at.
RSA (sign only) option for generating a signing key only. Use the default 2048-bit keysize if you have no reason to use a larger one. Choose an expiration date. Input a passphrase.
Repeat the procedure, but this time, create a RSA (encrypt only) key.
As a final step, trust and save the keys you’ve made:
After these operations, your keyring should look similar to this:
Evacuating the master key to safety
Now you should have a master keypair and a signing/encryption sub-keypair for your personal computer. It is imperative, that the master keypair is now evacuated to safety.
There are endless possibilities how to store your master keypair, from paper printouts in a safe, to armed guards in your basement. Because I haven’t yet obtained any interesting information to whistleblow, I chose the mundane approach of backing up the master keypair to a USB drive:
Alternatively, with gpg2, you can delete keys without needing to twiddle with exporting and importing:
You can verify that the master secret key should not be in the keyring by detecting
sec# when listing the secret keys.
Now, be sure to evacuate your master keypair
pubkey with your chosen method to a safe location. I’m storing it in an encrypted USB drive. The short gist of that is as follows:
Sending the public key to a key server
Next, you’ll want your public key to be actually obtainable for other people. Keyservers are a good fit for this, since the gpg tool can be used to query them for other people’s public keys.
For enhanced security, obtain the CA cert for the keyserver:
Set the following as your keyserver configuration in
Send your public key to the keyserver pool. Afterwards you and anybody else can find your PGP identity.
And you’re done setting up your GPG configuration! The following section depicts use cases and how to solve them.
Importing the primary secret key
Since you need the primary secret key for many operations, like signing new keys, it needs to be imported from the safe storage medium back to your keychain:
Replace the devices file descriptors with the correct ones.
Then, import the primary secret key:
After finishing with key manipulation, delete the private key from the keychain:
Create a new subkey. You’ll need your master keypair that is stashed away to certify the new subkey.
Again, you need the master secret key for this operation.
Obtain, sign and export somebody’s key:
And mail the resulting .gpg file to the person.
Extending the lifetime of a key
The point of setting an expiration date for all of your keys is to have them actually expire if you lose access to the master keys or the revokation key. Besides, checking your keys at least once per year can is a good practice that probably enhances your security.
Just set the expiration date through the gpg interface:
Again, you need your master keypair for this operation to succeed.
Revoking the master key
To revoke your key, simply import the revocation certificate and update keyservers:
Do not delete revoked keys. They are still useful to decrypt data previously encrypted with the old key.
Revoking a subkey
To revoke a subkey, revoke it from gpg’s interface:
Again, do not delete revoked keys. They are still useful to decrypt data previously encrypted with the old key.
Distributing an encryption subkey
For distributed usage, a subkey can be created for each usage purpose.
For example, to encrypt and decrypt your password manager files both in your phone and laptop, transfer the generated encryption subkey to the phone like so:
After that, transfer the
encsubkey.sec.asc via a secure mechanism, e.g. a flash storage, to the new device.
Never transfer private keys through the internet, and strive for isolated environments where the transfer is done.
Synchronizing the keyring between computers
Synchronizing a GPG keyring between computers may be desired to propagate information about imported key IDs10.
On whichever computer, export the keyring and put it on the encrypted USB drive:
Now, on the other computer, import (merge) the keyring:
Repeat this process the other way around, if needed.