GPG key management, part 1

Welcome back to the GPG series, where we are exploring how to make use of GPG with other applications to secure and protect your data.This installment will cover key creation, key revocation certificate creation, and sending the public key to a key server. The second part of key management will cover exporting, revoking, adding and removing keys.

In Fedora, you have the option to use Seahorse or the command line to create a key. In this series, we will cover both.

GPG in the GUI: Seahorse

To start Seahorse, switch to the Activities overview and search for ‘seahorse‘ or ‘keys‘.

GPG Key Management: Open SeaHorse to get started

Activities > Keys

Open Seahorse (also named Passwords and Keys depending on your desktop environment).

GPG Key Management: Using Seahorse

Then select File > New

GPG Key Management: Generate keys with Seahorse

Then select PGP Key and Continue.

GPG Key Management: Seahorse advanced options

Default options.

Fill out the basic options with your name and email. The advanced options allow you to choose an encryption type, key strength, and expiration date. It is recommended that you use RSA and a key strength of 4096 bits. Choosing an expiration date is also highly recommended for security reasons. Some combinations of algorithm and key length are not secure, so stick with this recommendation unless you know what you are doing.

Recommendations for expiration dates range between two and five years. GPG gives you the ability to modify and extend key expiration dates later. An expiration date ensures helps keep your key secure. If you have multiple addresses, do not worry about which one to choose, because you can add extra email addresses after the key is created.

GPG in the command line

In Fedora, there are two commands for working with GPG: gpg and gpg2. If you are using GPG on the graphical desktop, use gpg2, because the resulting keyring and files integrate with desktop applications like Evolution and Seahorse.

To generate a key, use gpg2 –full-gen-key to choose all the key creation options.

$ gpg2 --full-gen-key

gpg (GnuPG) 2.1.9; Copyright (C) 2015 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.

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?

Select option 1 to generate an RSA key for signing and encryption.

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

You will then be prompted to select a key length. The default is currently 2048, but the maximum length is recommended. As computing capabilities increase, shorter keys will become insecure to use. A longer key is likely to be secure for a longer time. While you can migrate to a new key, the process is a bit tedious.

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) 2

Key expires at Tue 26 Jan 2016 09:44:43 AM EST
Is this correct? (y/N)

When selecting a key expiration, ensure that you add the value for weeks, months, or years. As you can see from the example above, if you fail to do so, GPG defaults to days. As recommended with Seahorse, choose an expiration between two and five years.

GnuPG needs to construct a user ID to identify your key.

Real name: charles profitt
Email address:
You selected this USER-ID:
    "charles profitt <>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o

You are now prompted to enter values so GPG can construct a user ID. Enter your real name and email address. You can add extra email addresses after the key is created. After entering these values, GPG prompts you to check your entries and optionally change the values, accept them, or quit.

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
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: key 5D50C86C marked as ultimately trusted
gpg: directory '/home/cprofitt/.gnupg/openpgp-revocs.d' created
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2016-01-26
pub   rsa4096/5D50C86C 2016-01-24 [expires: 2016-01-26]
      Key fingerprint = 647D B957 0E03 4247 8C30  6852 1462 A582 5D50 C86C
uid         [ultimate] charles profitt <>
sub   rsa4096/8D8FF075 2016-01-24 [expires: 2016-01-26]

Entropy is equally important to key length. Entropy generally means disorder. In key generation, it means disordered, random data that is virtually impossible to regenerate. If your key is not generated with enough entropy. it will be more vulnerable to attack. When the system gains enough entropy, it will generate your key with the options you selected.

It may take some time for your system to generate entropy. To assist the random number generator with this process, open other programs or move the mouse around. GPG will also prompt you to enter a passphrase for your key.

GPG Key Management: Set your key passphrase in gpg2

When you want to use either your public or private key, you will be prompted for your passphrase, so make sure you remember it! This makes the passphrase very important. Someone with your passphrase has the ability to assume your identity or decrypt your data. So make sure you use a strong passphrase. (Search Google for other ideas on making strong passphrases.) Do not use the same password used to log in to your account or the root account, or a password you use on any other system.

Sending a key to a key server

Now that you have a key pair, you need to send the public key to a keyserver so other people can find and use it. Your public key is used by others to verify messages you sign, or to decrypt a message sent with your private key. As we discussed in the first part of the series, keyservers on the internet collect and advertise public keys to make data exchange easier. They help you share a public key as widely as possible.

Remember that your public key is just one half of the key pair used in the asymmetric process of encrypting a message or file. A message encrypted with the public key can be decrypted only by the private key, and vice versa. This process will be discussed in greater details later in the series.


GPG Key Management: Sync public key to keyserver with Seahorse

Open Seahorse and navigate to your PGP keys. Then select Remote > Sync and publish keys…

GPG Key Management: Sync your public key with keyservers

The Sync button will be grayed out until you select a keyserver. To do this, click the Key Servers button.

GPG Key Management: Select a keyserver in Seahorse

The two default servers are both acceptable. In addition, the Fedora Project also provides a keyserver. To add this key server click the Add button. Enter the address Then select a server for publishing your public key in the drop-down menu below the list of keys. Finally, close the dialog box and the Sync button will be enabled.

Command line

To send your key to a keyserver, you must know your key identifier. To find your key identifier, use this command:

$ gpg2 --list-keys
pub   rsa4096/5D50C86C 2016-01-24 [expires: 2016-01-26]
uid         [ultimate] charles profitt <>
sub   rsa4096/8D8FF075 2016-01-24 [expires: 2016-01-26]

The key you want to send is your public key. This is the key on the first line starting with pub.

$ gpg2 --keyserver --send-key 5D50C86C
gpg: sending key 5D50C86C to hkp server

The key is now sent to the selected keyserver. With your public key available to others, you are ready to start using GPG to keep your communications authentic and secure.

Revocation certificate

When you created your key, GPG also created a revocation certificate. When you use the command line, this is more obvious, but Seahorse also creates a revocation certificate. In both cases, the certificate is located in ~/home/.gnupg/openpgp-revocs.d/.

A revocation certificate allows you to tell the world your key pair is no longer valid. You would use this certificate if your private key is stolen, compromised, or lost. You should also use the revocation certificate if you forget your passphrase and can no longer use your key pair. You should store your revocation certificate and private key in the most secure storage possible. You should also store your revocation certificate in a different location than the private key.

Many users put their private key and revocation certificates on two flash drives and store them in a lock box or safe. If your revocation certificate is not secure, a malicious actor could revoke your key pair, and cause a major disruption for you as well as those who use your public key.

Fedora Contributor Community For Developers For System Administrators Using Software


  1. Johan


  2. Chris

    I’d rather not recommend seahorse. It has quite many unresolved bugs, including some critical ones: [1], furthermore it doesn’t seem to be maintained except translation updates [2]. It doesn’t share its configuration with gnupg so it will result in unexpected behavior when e.g. evolution or thunderbird (with enigmail) is using gnupg.

    Seahorse doesn’t provide any privacy when updating keys, it basically tells everybody on your network whose keys you have downloaded. See design documents from parcimonie [3] and use [4] to protect yourself. Seahorse doesn’t even understand hkps, that is encrypted hkp, see [1].


  3. Skavoovie

    Perhaps it would be best to advise readers of the ramifications of uploading their public keys to key servers:

    They will likely never be able to remove the key or the information associated with it on my key servers, even if they end up revoking the key.
    Their email address will be scraped by spammers and the amount of spam they receive will increase.

  4. Steven


    These are very good articles on GPG. I look forward to more.

  5. Skavoovie

    Oops – confusing typo. That should have read “…on many key servers…” in my previous comment.

  6. What is GPG useful for?

  7. David Liteman

    Very well explained. gpg is central to ensuring privacy.

  8. Alam

    Thanks for helpful article. I am KDE user and using command line for gpg.
    I have doubt about ~/home/.gnupg/openpgp-revocs.d/ in ‘Revocation certificate’ Section. ‘home’ looks odd in path. Not so?

  9. Thanks for elaborating GPG key management. Also thanks for sep by step process to do the same. Keep up the good work. Thanks!

  10. Wally the Pissed Off Veteran

    Nice article,
    Including the shell version of GPG/GPG2 is/was a good idea.
    I have no intention of ever even considering the use of any graphical system to use GPG! NEVER! My FIRST name is Paranoia.
    Also I have been using 4096 Keys since about 1995—1997. Not sure about the dates but the only reason I don’t use a much larger key is because GPG does not go there.

    I would like to know where in GPG configuration or even the source code to change the default RND generation. I use DD to create very large random numbers and without arguing with anyone I much prefer “/dev/urandon” to “/dev/random.” Would love to have GPG ask in the key generation phase to allow the selection of an external Random number. I create as I said, very large Random numbers using a little Raspberry as it has the best sours of randomness that I am aware of. An onboard special chip. Look it up. I also use the random noise of an Alpha radion source that is on my Gieger counter for testing the counter. So short question is how to change the default Random generation or file inclusion for creating my keys. Nice article, Thanks, Wally the Pissed Off Veteran.

  11. Wally the Pissed Off Veteran

    GPG, or GnuPG, refers to the Gnu Privacy Guard utility. GPG is a freely available implementation of the OpenPGP standard that was released by Werner Koch in 1999.

    Funny, I started using PGP in 1998 while still using a CPM-86 computer. I also contributed to the legal defense fund for Phil Zimmerman when the DOD was attempting to jail him for releasing PGP. Which he didn’t in the first place. I had worked my butt off trying to install Slackware on the old laptop but never got there so stuck to CPM-86. Hated MicroSnot beyond words.
    At the same time I ran a print server, email server and a firewall for a Mfg. co. About 400 + desktops running MSDOS=5 with Windows for Work Groups. WFW-3.11.
    I installed Novel Dos “DRDOS-7” Novel had purchased CPM and then I loaded WFW-3.11 on DRDOS for it’s stability and file locking/directory locking which MSDOS did not have. Using DRDOS with WFW solved many head aches as MSDOS-5 crashed several times a day. the DRDOS versions just ran and worked day in and day out.

    Oh well, old memories from a very old ,
    Pissed Off Veteran.

    • Veteran:

      The GnuPG version I am referring to is version 1.0.0 which I believe was released in 1999 and considered the first production code. There was, to my knowledge, non-production versions going back almost two years. PGP was created in 1991 by Phil Zimmerman. I am a graying member of the way back club and remember Windows for Workgroups 3.11 (still have a virtual machine of that OS).

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions