How Do I Use GPG for Encryption?

Posted on December 20, 2019 by David Singer | Updated: May 9, 2023

Category: Tutorials | Tags: Asymmetric Encryption, Asynchronous Key Cryptography, CentOS, decrypt, Encrypt, Encryption, Gnu Privacy Guard, GnuPG, GPG, Keys, Passphrase, PGP, Pretty Good Privacy, Privacy, Private Keys, Public Keys, Secure, Secure Communications, Security, Ubuntu

GPG

How Do I Use GPG for Encryption?
How to Share Encrypted Information

Reading Time: 10 minutes

What is GPG?

GnuPG (or Gnu Privacy Guard) is an adaptation of an earlier encryption standard known as PGP (or Pretty Good Privacy). GPG uses the method of "public" and "private" keys for the encryption and signing of messages or data.

In this article, we’re going to be discussing the following topics:

Why is GPG needed?
How Does Public Key Encryption Work?
How do I Setup GPG Keys?
How do I Find Other Users’ Public Keys?
How do I Make My Public Key Available To Others?
How do I Encrypt and Decrypt Messages with GPG?

Today more than ever, the conscientious need for privacy, confidentiality and security awareness should be one of the primary emphases of daily life. This is an unfortunate but necessary requirement in this current day and age. Utilizing many of the available online tools and taking the obvious precautions can definitely minimize the risks of being the target of malware or a malicious actor, but it will not completely eliminate the possibility of being compromised.

Why Is GPG Needed?

GPG is an excellent method to ensure secure communication between two parties. It allows sensitive information to be easily shared across an insecure network.

Asynchronous key cryptography uses public and private keys to encrypt/decrypt messages. This is called asymmetric encryption. It allows you to send or publish your public key out in the open on an insecure network. The party looking to send you a secure message uses your public key to encrypt a message using that key. The message is then sent to you where you then use your private key to decrypt it. You can then reply using the sender’s public key which allows you to securely encrypt messages to them. They then use their private key to decrypt messages encrypted by you.

Prerequisites

Install GPG

Ubuntu/Debian

root@host:~$ apt-get install gnupg

CentOS/Redhat

root@host:~$ yum install gnupg

Verify Installation

root@host:~$ gpg --version
gpg (GnuPG) 2.2.12
libgcrypt 1.8.4
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/david/.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

How Do I Setup GPG Keys?

Generate a key pair and then export the public key.

First, you must generate a key pair.

root@host:~$ gpg --full-generate-key
gpg (GnuPG) 2.2.12; Copyright (C) 2018 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? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (3072) 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) 0
Key does not expire at all
Is this correct? (y/N) y

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

Real name: David Singer
Email address: dsinger@liquidweb.com
Comment: 
You selected this USER-ID:
    "David Singer <dsinger@liquidweb.com>"

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

Next, a popup will appear asking you to input a password.

Warning:

Do not forget your passphrase! Your new key will be unusable if the passphrase is forgotten. Write this passhrase down and store it in a secure location.

Next, GPG will ask you to move your mouse around the screen to collect random data to use during the key creation process.

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 B3219C4BE8F1E313 marked as ultimately trusted
gpg: revocation certificate stored as '/home/david/.gnupg/openpgp-revocs.d/41C38C7648F1A89FC06395CFB3219C4BE8F1E313.rev'
public and secret key created and signed.

pub   rsa4096 2019-12-17 [SC]
      41C38C7648F1A89FC06395CFB3219C4BE8F1E313
uid                      David Singer <dsinger@liquidweb.com>
sub   rsa4096 2019-12-17 [E]

Export Your Key

To export your new key, use:

root@host:~$ gpg --output your.name.gpg --armor --export youname@domain.com

When you export your key file, it will be output as the public version of your key that you share and will be called yourname.gpg. This is the file you will give out to allow others to encrypt a message to you. Here is a link to an example public gpg file.

After you export your public key, you’ll want to share your key to a public keyserver. This is where others can locate and use to find your public key. There are multiple keyservers out there that can be used for this. A few of the more popular ones are:

Here is an example of how to export your public key to the pgp.mit.edu key server.

root@host:~$ gpg --send-keys --keyserver hkp://pgp.mit.edu E8F1E313
gpg: sending key B3219C4BE8F1E313 to hkp://pgp.mit.edu

Working With Encryption Keys

Locate The Receiver's Public Key

In order to encrypt an outgoing message, you will need the public key of the person you are sending the message to. Many times, the person or entity will already have an established GPG key located on one or more of the public keyservers noted above. If they do not, you can point them to this article to review and set up a keypair for themselves.

In order to locate a public keypair for an individual, simply do a quick search of a name, email address, or other unique defining factors at one of the keyservers noted above and their resulting public key should be shown. An easy way to search for a key is to run a command like this.

root@host [~]# gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --search username@domain.com

For example, if we go search for adele-en@gnupp.de (the gpg test bot), using the command below, we can see the most recent keys the bot has available, and we can use that key to send a test email to verify our setup works.

root@host [~]# gpg --keyserver hkp://p80.pool.sks-keyservers.net:80 --search adele-en@gnupp.de
gpg: searching for "adele-en@gnupp.de" from hkp server p80.pool.sks-keyservers.net
(1)	Saeed Lootah (test) <H00257317@hct.ac.ae>
	Saeed Lootah (test1) <H00257317@hct.ac.ae>
	Adele (The friendly OpenPGP email robot) (test1) <adele-en@gnupp.de>
	  2048 bit RSA key BFEE478F, created: 2017-11-18
(2)	Adele (Test) <adele-en@gnupp.de>
	  2048 bit RSA key ED161999, created: 2014-08-13, expires: 2018-08-13 (expired)
(3)	adele-en <adele-de@gnupp.de>
	  2048 bit RSA key 4D486CC8, created: 2013-07-08, expires: 2017-07-08 (expired)
(4)	Adele (Der freundliche E-Mail-Roboter) <adele@gnupp.de>
	Adele (The friendly OpenPGP email robot) <adele-en@gnupp.de>
	  1024 bit DSA key 92AB3FF7, created: 2002-03-06
Keys 1-4 of 4 for "adele-en@gnupp.de".  Enter number(s), N)ext, or Q)uit > 1
gpg: requesting key BFEE478F from hkp server p80.pool.sks-keyservers.net
gpg: key BFEE478F: public key "Adele (The friendly OpenPGP email robot) (test1) <adele-en@gnupp.de>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
root@host [~]#

You may run into issues in trying to locate someone's public key if they publish it to a less than well known keyserver that may not share that info with other keyservers.

Locate Your Public Key

In the same way you retrieved the key of the person you are sending a message to, they need to do the same. You can post your public key on a website, at the bottom of your email (in your signature) or other locations to aid others in gathering this info.

Key Trust Levels

When sharing your key with another individual, it is important to note that the sender and receiver should BOTH establish a level of trust for the keys you provide to each other. This is a security step that must be addressed. Be sure to use a trusted method of communication that is authoritative and reliable when verifying keys. There are two important factors of key trust. The validity of a signature and the Ownertrust. These are two different aspects that should not be confused.

The Validity of a signature proves if the signature is valid.
The Ownertrust refers to the level of trust you assign to a certain key.

Since GnuPG utilizes the OpenPGP Web of Trust model, the key's trust level allows keys to verify other keys. In order to create, modify or update a key, you can use the following commands.

root@host [~]# gpg --edit-key adele
gpg (GnuPG) 2.0.22; Copyright (C) 2013 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: 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
pub  2048R/BFEE478F  created: 2017-11-18  expires: never       usage: SCE
                     trust: ultimate      validity: ultimate
[ultimate] (1). Adele (The friendly OpenPGP email robot) (test1) <adele-en@gnupp.de>
[ultimate] (2)  Saeed Lootah (test) <H00257317@hct.ac.ae>
[ultimate] (3)  Saeed Lootah (test1) <H00257317@hct.ac.ae>

gpg> trust
pub  2048R/BFEE478F  created: 2017-11-18  expires: never       usage: SCE
                     trust: ultimate      validity: ultimate
[ultimate] (1). Adele (The friendly OpenPGP email robot) (test1) <adele-en@gnupp.de>
[ultimate] (2)  Saeed Lootah (test) <H00257317@hct.ac.ae>
[ultimate] (3)  Saeed Lootah (test1) <H00257317@hct.ac.ae>

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 4

pub  2048R/BFEE478F  created: 2017-11-18  expires: never       usage: SCE
                     trust: full          validity: ultimate
[ultimate] (1). Adele (The friendly OpenPGP email robot) (test1) <adele-en@gnupp.de>
[ultimate] (2)  Saeed Lootah (test) <H00257317@hct.ac.ae>
[ultimate] (3)  Saeed Lootah (test1) <H00257317@hct.ac.ae>
Please note that the shown key validity is not necessarily correct
unless you restart the program.

gpg> quit
root@host [~]#
root@host [~]# gpg-connect-agent /bye
root@host [~]#

As you can see towards the end of the initial line:
trust: 0-, 0q, 0n, 0m, 0f, 1u
These letters after the 0's indicate the trust level as noted below. The number 0 indicates there is no level of trust assigned. The "1u" indicates the trust level is ultimate.

After that, we restart gpg using the "gpg-connect-agent /bye".
GPG will then restart as soon as it is needed again.

Unknown/No Ownertrust assigned: “-” This is the default state of all imported keys. No info is known about the key owner other than what is in the key itself. All of the keys on your public keyring that are not verified have this initial level of trust.
Trust Calculation Failed: “e”. This usually indicates that the Trust process has failed possibly due to an expired key.
None: “q” This usually indicates that the trust level is still 'Unknown', or not enough info is available to make a decision. This setting varies in the sense that the level of trust has actually been modified by you to ‘None, or if the key owner has been identified as improperly signing other keys.
None: "n" Never trust this key. This is used if a signature or key is found to be fraudulent or not valid.
Marginal: “m” Setting a key to marginal trust will modify a key to show as valid, This indicates that the imported key has been trusted by at least three other people in your web of trust. For example, if you set Bob, Sue, and Ann’s keys to ‘Marginal’ and they all trust the imported key, it should be set to marginal.
Full: “f” This setting is used for keys that you trust to sign other keys. Basically, if Sue’s key is signed by your friend Bob, whose key ownertrust you set to Full, Sue’s key will also be trusted. You should only be using Full ownertrust after verifying and signing someone's key.
Ultimate: “u” This ownertrust setting should only be used for your personal keys. Ultimately, your keys are the only keys you can explicitly trust!

Note:

The small letters (e,q,m.f, and u) will be shown in the command line in response when importing new keys.

Verify External Keys

The correct way to validate an external PGP key involves establishing a continuous “chain of trust” between you and the key owner. In some scenarios where you do not personally know the key owner, this verification can be difficult at best.

Once you obtain the ID of the key you are desiring to add, you can confirm the details of the key via one of the keyserver interfaces noted above. You should see info like email addresses, photo and other info noted by the person(s) who signed the key.

root@host [~]# gpg --sign-key adele-en@gnupp.de

If the person you are trying to send an encrypted message to has an open public key file available (eg. user.asc or user.key) on a website or in a file, we can use the “--import” flag in gpg to add that key to our keyring.

gpg --import < user.asc

The simplest way to verify that a key belongs to a person who claims ownership is to call them on the phone or use an audio/video chat with the key owner. To verify them:

Open the public key of your contact in the GPG Keychain and double click on it.
Ask your contact to do the same and open their GPG Keychain and double click on it.
Ask them to read their fingerprint to you
Verify the fingerprint is the same
Elevate the trust level to a degree you feel comfortable with.

root@host [~]# gpg --finger BFEE478F
pub   2048R/BFEE478F 2017-11-18
      Key fingerprint = C5D2 8434 D779 D2DE 7255  029F B3DB 8177 BFEE 478F
uid                  Adele (The friendly OpenPGP email robot) (test1) <adele-en@gnupp.de>
uid                  Saeed Lootah (test) <H00257317@hct.ac.ae>
uid                  Saeed Lootah (test1) <H00257317@hct.ac.ae>

root@host [~]#

Another way to gather info on the external public key, we can use the finger flag to gather more info.

As we can see in the above interaction, we can confirm that adele-en@gnupp.de email address has the related BFEE478F signature. This means we can add further verification of the signer’s information.

root@host [~]# gpg --edit BFEE478F
gpg (GnuPG) 2.0.22; Copyright (C) 2013 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.

pub  2048R/BFEE478F  created: 2017-11-18  expires: never       usage: SCE 
                     trust: unknown       validity: unknown
[ unknown] (1). Adele (The friendly OpenPGP email robot) (test1) <adele-en@gnupp.de>
[ unknown] (2)  Saeed Lootah (test) <H00257317@hct.ac.ae>
[ unknown] (3)  Saeed Lootah (test1) <H00257317@hct.ac.ae>

gpg> lsign
Really sign all user IDs? (y/N) y
gpg> save
Key not changed so no update needed.
root@host [~]#

GnuPG's Trust DB Information

The type of data below is printed anytime the trust database is updated. For example, after receiving new or updated info from a key server.


gpg: depth: 0  valid:   1  signed:  16  trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:  16  signed: 115  trust: 1-, 1q, 1n, 1m, 12f, 0u
gpg: depth: 2  valid: 105  signed: 189  trust: 81-, 11q, 0n, 4m, 9f, 0u
gpg: depth: 3  valid:  29  signed: 120  trust: 19-, 9q, 0n, 0m, 1f, 0u
₁

This output denoted above indicates the web of trust you maintain in the GPG TrustDB. On level 0 "gpg: depth: 0", you will find your (ultimately trusted) keys. There should not be any other kind of keys trusted on this level.

Keys that are trusted at further depths will generate levels 0-5, as long as the default maximum depth path is not modified in the configuration file. A depth of five is denoted as standard by the OpenPGP trust model.

And that’s it for now! In our next article on GPG, we will be discussing the best way to send encrypted email.

Want to learn more about GPG or encryption?
Have further thoughts on how you can implement this technology on your server or utilize it more in your daily workflow?

Give us a call at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable Solutions or Experienced Hosting advisors to learn how you can take advantage of these techniques today!

Series Navigation

Next Article >>

About the Author: David Singer

I am a g33k, Linux blogger, developer, student, and former Tech Writer for Liquidweb.com. My passion for all things tech drives my hunt for all the coolz. I often need a vacation after I get back from vacation....