To create a key:

gpg --gen-key

The fingerprint is printed, you should save this in a safe place. It allows you to confirm with others that they have received your actual key. Like a hash check.

If you are on ssh and you run out of random bytes, run this command:

rngd -f -r /dev/urandom

You can check the amount of available entropy here:

cat /proc/sys/kernel/random/entropy_avail


Generate the fingerprint at any time:

gpg --fingerprint

Revocation Certificate

Then generate a revocation certificate. Just in case your key is compromised, you can use this to invalidate it. KEYNAME can be either the ID or the fingerprint.

gpg --output filname-revoke.asc --gen-revoke KEYNAME

Backup Private Key

Backup the key and also keep it in a safe place.

gpg --export-secret-keys --armor > filename-private.asc

Send Public Key to a Keyserver

Make the public key available to others. This will send the key to the default public key server

gpg --send-key KEYNAME

To chose a different server, enter its address in this line:

gpg --keyserver hkp:// --send-key KEYNAME

Create a Public Key File

Alternatively, you might want the key to deliver via a different means:

gpg --export --armor > filename-public.asc

Import a Key You Have Recieved

When you want to use someone else’s public key, you will need to import it.

gpg --import filename-public.asc

After import, and that you trust that the key is from the correct person, sign the key. Once signed, output the signed version of that key.

gpg --sign-key
gpg --export --armor

This gives this public key your personal verification that it is genuine. You act as the Certificate Authority in this case. Others who receive this key can now see that you claim that this is a valid key.

If the signed key was from your public key, then when you get it back, you should import it again.

gpg --import signed_key.asc

Revoke Your Key

If the key is compromised, you can make it unusable. First, import the revocation certificate you created.

gpg --import revoke.asc

Then send the revocation notice to a server, even if this is not how the key was distributed.

gpg --keyserver --send KEYNAME

How and Where to Use Your Keys

Public keys can be freely distributed. They can be saved on keyservers and linked to. They can be copied to removable media and handed to a person. They can be downloaded and emailed, but check the fingerprint to make sure an MITM has not intercepted and switched keys on you.

Encrypt Messages

Use the --encrypt flag to encrypt a message.

gpg --encrypt --sign --armor -r filename-to-encrypt

You will not be able to read the resulting message without “friend’s” private key. To make a message you can decrypt also, add yourself as a recipient.

gpg --encrypt --sign --armor -r -r filename-to-encrypt

Decrypt Message

The simplest command there is. You will, of course require the appropriate key.

gpg filename

As you see, you generally encrypt with the recipient’s public key so that only that recipient can decipher the message with their own private key. So before you send someone a message, they will be required to get you their public key to use.

So, for encryption: Recipient Public key encrypt. Recipient Private key decrypt.

However, for signing: Your Private key encrypt. Your Pubic key decrypt.

With signing, anybody who has access to your public key can decrypt the message, so it’s not much in the way of security. So what is the point? The point of signing is integrity. Because only your public key can decipher the message, it is now definite the that message came from you and you only (unless your private key has been compromised!)

To sign a message:

gpg --sign myfile.ext

Other Tasks

List the keys you have:

gpg --list-keys

Update key information by fetching new info from key servers (Updates you would need to know if any of your friends have revoked their keys).

gpg --refresh-keys

What to Use GPG for

You use it for encrypting messages, of course! The problem is: To who?? The complexity of GPG excludes the majority of my friends and family, all of whom are non-technical. Even at work, if I started requiring my boss and co-workers, let alone our customers to jump through GPG hoops to read my messages, I would not have a job for long.

As much as we want to protect our privacy, I’m afraid we’ve lost the advantage of acceptance and convenience. If there are appropriate venues for posting or exchanging encrypted messages, they’re not in easy and obvious places, beyond https and default phone encryption.

Luckily, I, and hopefully you, develop software. Several of the programs we develop communicate over a network or the internet. This might be a great place to use a little encryption. If it’s not going to be openly pursued, we can at least build it into the things we make, and make encryption ubiquitous. The best encryption appears to be the type that the user doesn’t have to think about.

So instead of using GPG for humans to communicate, wrap your API in GPG and let your programs communicate with a little privacy. No doubt there are more appropriate encryption schemes for this use case as well.

On the server, set up a decrypting listener:

ncat -lk 50000 | gpg

The ncat program is used on Red Hat (Fedora, etc.) systems, while on a Debian (Ubuntu, etc.) system, you will use nc. Same thing, different names for some reason. I think even the options are the same.

This will listen for messages on port 50000, then decrypt anything that comes through, printing it to stdout.

On the client:

echo "Be sure to drink your Ovaltine!" | gpg --encrypt | ncat 50000

This will send a string to our server after encrypting it with the server’s public key. Of course, the keys need to be set up on either machine beforehand.

My Public Key:

My current key can be found here.