Getting Started With GnuPG v2.x

If you’re looking at getting started with PGP encryption; or just wondering what has changed with GnuPG version 2 this article covers the basics you need to know to get started.

If you want to secure files and communications with strong encryption your best option is GnuPG. Commonly referred to as GPG it is free software implementing the OpenPGP signature and encryption standards. Generally Linux distributions include both v1.x and v2.x so you’ll need to make sure you have v2.x installed before continuing. You can confirm how your distribution names the executable by trying both “gpg –version” and “gpg2 –version” to make sure you’re using the correct executable.

Note: If you’re generating your key on a remote system there is a bug in the handling of X11 forwarding and you may need to login using “ssh -o ForwardX11=no” in order to properly generate or use a passphrase.

Generating Your Key

Make sure you’re logged in as the user you want to generate a key for and run “gpg2 –full-gen-key”. Select option 1 to generate a RSA/RSA key that can be used both for signing and encryption.

[ajh@thor ~]$ gpg2 --full-gen-key 
gpg (GnuPG) 2.2.13; Copyright (C) 2019 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: directory '/home/ajh/.gnupg' created
gpg: keybox '/home/ajh/.gnupg/pubring.kbx' created
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? 1

Specify a 4096-bit key by entering 4096.

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096

An expiry date ensures that should you lose access to your key-ring your key will eventually be removed from the key servers. Do not generate a key without an expiry date.

Using a one year expiry time is a good idea and then extending this date as needed. We recommend adding a reminder to your your calendar to make this change at some date prior to expiry. If you make extending the expiry date a monthly activity it will help you remain familiar with GnuPG and ensure that your encryption infrastructure is always ready for use.

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) 1y
Key expires at Thu 30 Apr 2020 13:47:43 EDT
Is this correct? (y/N) Y

The information you include is up to you. A valid email address ensures that your key is available for others to use to sign and secure email communications. You should use your primary email address and add additional addresses as sub keys after you finish generating your primary key. You can put anything (or nothing) in the comment field but keep in mind that it is visible to everyone.

GnuPG needs to construct a user ID to identify your key.
Real name: Andrew J. Hutton
Email address: ajh@finux.org
Comment: Primary Key
You selected this USER-ID:
"Andrew J. Hutton (Primary Key) ajh@finux.org"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O

If you get the following error it is an indication that GnuPG was unable to open a dialog for you to enter your new passphrase. If this happens on your local system try running ‘killall gpg-agent’ and starting the key generation process again. If it is a remote system disable X11 forwarding over ssh.

gpg: agent_genkey failed: Operation cancelled
Key generation failed: Operation cancelled

Choosing a Passphrase

You will want to specify a passphrase as this is used to lock and unlock your private key as needed. Unlike passwords a passphrase does not need to be totally random but it does need to be obscure and completely meaningless to anyone else. Think of your passphrase as a spy’s code phrase and use something like ‘the blue dog eats the purple grass at noon’; this phrase is memorable to you, but meaningless to anyone else.

If your system complains that there is not enough entropy available (as is likely on a newly installed system) use the system for a short while and try to generate your key again.

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.
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.
gpg: /home/ajh/.gnupg/trustdb.gpg: trustdb created
gpg: key 2A16B57766C3CA8C marked as ultimately trusted
gpg: directory '/home/ajh/.gnupg/openpgp-revocs.d' created
gpg: revocation certificate stored as '/home/ajh/.gnupg/openpgp-revocs.d/5729699CE1222C649FB12E8B2A16B57766C3CA8C.rev'
public and secret key created and signed.
pub rsa4096 2019-05-01 [SC] [expires: 2020-04-30]
5729699CE1222C649FB12E8B2A16B57766C3CA8C
uid Andrew J. Hutton (Primary Key) ajh@finux.org
sub rsa4096 2019-05-01 [E] [expires: 2020-04-30]
[ajh@thor ~]$

Displaying Your Key

Now display your public key with “gpg2 –list-keys” this will list all of the keys on your key ring. Your primary key id is listed as pub for public key, then rsa4096 which you selected during the key generation process, the creation date key use SC for Signing and the expiry date. The next line is your key id, then it shows one sub key, with mostly the same information except this one is specified as E for Encryption.

ajh@thor ~]$ gpg2 --list-key ajh@finux.org
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2020-04-30
pub rsa4096 2019-05-01 [SC] [expires: 2020-04-30]
5729699CE1222C649FB12E8B2A16B57766C3CA8C
uid [ultimate] Andrew J. Hutton (Primary Key) ajh@finux.org
sub rsa4096 2019-05-01 [E] [expires: 2020-04-30

[ajh@thor ~]$ gpg2 --list-key 5729699CE1222C649FB12E8B2A16B57766C3CA8C
pub rsa4096 2019-05-01 [SC] [expires: 2020-04-30]
5729699CE1222C649FB12E8B2A16B57766C3CA8C
uid [ultimate] Andrew J. Hutton (Primary Key) ajh@finux.org
sub rsa4096 2019-05-01 [E] [expires: 2020-04-30]

If you’ve used gpg or pgp before you’ll notice that the keyID is now much longer to help avoid conflicts where multiple people generate keys with the same keyID.

Adding Sub Keys

<add details for creating sub keys here>

Getting your Fingerprint

Now get your key fingerprint. Used in combination with your key id the fingerprint provides a way to confirm that the key someone else has for you is the real key you generated. To do this run “gpg2 –fingerprint <keyid>”. The fingerprint is the alpha numeric listing of 10 groups of 4 digits. In this example the fingerprint is 5729 699C E122 2C64 9FB1 2E8B 2A16 B577 66C3 CA8C.

gpg2 --fingerprint 5729699CE1222C649FB12E8B2A16B57766C3CA8C
pub rsa4096 2019-05-01 [SC] [expires: 2020-04-30]
5729 699C E122 2C64 9FB1 2E8B 2A16 B577 66C3 CA8C
uid [ultimate] Andrew J. Hutton (Primary Key) ajh@finux.org
sub rsa4096 2019-05-01 [E] [expires: 2020-04-30]

Editing Key Expiry

[ajh@thor ~]$ gpg2 --edit-key ajh@finux.org
gpg (GnuPG) 2.2.13; Copyright (C) 2019 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
gpg: starting migration from earlier GnuPG versions
gpg: porting secret keys from '/home/ajh/.gnupg/secring.gpg' to gpg-agent
gpg: migration succeeded
Secret key is available.
sec rsa4096/2A16B57766C3CA8C
created: 2019-05-01 expires: 2020-04-30 usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/1530750EBE7AB1F4
created: 2019-05-01 expires: 2020-04-30 usage: E
ultimate. Andrew J. Hutton (Primary Key) ajh@finux.org
gpg> expire
Changing expiration time for the primary key.
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) 1y
Key expires at Thu 30 Apr 2020 17:42:20 EDT
Is this correct? (y/N) y
sec rsa4096/2A16B57766C3CA8C
created: 2019-05-01 expires: 2020-04-30 usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/1530750EBE7AB1F4
created: 2019-05-01 expires: 2020-04-30 usage: E
ultimate. Andrew J. Hutton (Primary Key) ajh@finux.org
<passphrase verification happens here>
gpg> save
[ajh@thor ~]$

Sending to the Key Servers

The next step is to send your new key to the key server network. This allow others to search for your public key in order to sign it; or use it to encrypt data that only you can decrypt. Once you have uploaded your key it can take some time to propagate to all of the key servers. This is done with gpg2 –send-keys <keyid>.

[ajh@thor .gnupg]$ gpg2 --send-keys 5729699CE1222C649FB12E8B2A16B57766C3CA8C
 gpg: sending key 2A16B57766C3CA8C to hkps://hkps.pool.sks-keyservers.net

<add information here about sending keys to Keybase OR a reference to another post depending on how much detail is required.>

Backing Up Your Keys

Keeping your keys secure is your primary concern and there are multiple methods for doing this. What we recommend is exporting your keys as ASCII text and printing them out; this allows you to file away a copy that can in extremis be used to restore access to your key or revoke it as necessary. Putting digital copies on removable media is also recommended, and storing the media in a secure location as restoring from a digital copy is significantly easier.

You can export your public key using either your keyid or email address associated with the key.

gpg2 --export --armor ajh@finux.org > ajh.public.key

You can also export your private keys, and these are the ones you MUST keep secure.

gpg2 --export-secret-keys --armor ajh@finux.org > ajh.secret.key

As you will see; this operation requires entering your passphrase as your secret keys are encrypted. Store these in a very secure location.

Backing Up Your Configuration

If you want to backup your entire configuration with keys we recommend creating an archive file and then encrypting it with a unique password. This method by default uses AES-128 and ensures that your backup is secure (enough) and that you do not need a public/private key in order to access your backup in the case of catastrophic failure or loss.

[ajh@thor ~]$ tar cvfz gnupg.tar.gz .gnupg/
.gnupg/
.gnupg/pubring.kbx
.gnupg/openpgp-revocs.d/
.gnupg/openpgp-revocs.d/5729699CE1222C649FB12E8B2A16B57766C3CA8C.rev
.gnupg/private-keys-v1.d/
.gnupg/private-keys-v1.d/484169D36BAFDD60AFB4A969AAEE78C25D1887BA.key
.gnupg/private-keys-v1.d/5ED89C884FFE573ABC3EE64A3A8006449FCD93DD.key
.gnupg/pubring.kbx~
.gnupg/trustdb.gpg
.gnupg/.gpg-v21-migrated
.gnupg/tofu.db
.gnupg/secring.gpg
.gnupg/pubring.gpgq

[ajh@thor ~]$ gpg -c gnupg.tar
<passphrase requested, this one does not need to be the same as your key passphrase>
[ajh@thor ~]$ ls gnupg.tar.gz*
gnupg.tar.gz gnupg.tar.gz.gpg
[ajh@thor ~]$ rm gnupg.tar.gz

Revocation Certificates

GnuPG version 2.x automatically generates key revocation certificates (stored in ~/.gnupg/openpgp-revocs.d) for every key you generate. These are used when you need to make a key invalid. You should move these to a secure storage medium. A flash drive is good but you should also print them and file in a secure location. You can re-generate revocation certificates when needed as long as you still have access to your keyring.

Web of Trust

The next article will deal with how GnuPG and the OpenPGP standard is used to create a secure web of trust between key holders so that you can be confident of the connection between a given public key and the identity of the private key holder associated with it.