key pair

An Introduction to GnuPG (GPG) – Generating Keypairs and Revocation Certificates

There are lots of different ways to encrypt information. One of these is GNU Privacy Guard (a.k.a GnuPG or GPG).

This topic can get complex, so to better understand GPG some back story and simple facts will help:

GPG is a free and GPL licensed alternative to PGP that is compliant with the OpenPGP standard. Lots of acronyms!

GPG is the software we will use in our examples today. It allows you to create and import keys and to sign, encrypt or decrypt messages and files.

GPL stands for General Public License. It means that the software is truly free and anyone can use it for any reason. You can even sell it! An important distinction is that any derivative works or distributions must remain licensed by GPL. This ensures the software and any cool things that come from it remain free for the whole world to use. Important for lots of reasons. Imagine if instead we chose a software that was eventually made proprietary leaving users in the dark about developments to the software. When you are working with crypto I’d say that is unacceptable. You must be able to review the code or trust that anyone qualified CAN review the code. A GPL license ensures we will always be able to review the GPG code and that it will always be free.

PGP stand for Pretty Good Privacy. It was developed by Phil Zimmerman in the early 90s. It was a great piece of software. However, it was compromised by patent issues on the RSA crypto and eventually sold to Symantec (!).

OpenPGP is a standard that Zimmerman had a lot to do with when he realized what troubles patents and restrictive licenses were having on the crypto community. It defines some important rules about the standards for a software built around PGP.

We should also understand the difference in asymmetric and symmetric key algorithms. An example of an a symmetric key algorithm is using the SAME key to encrypt and decrypt a message. As an example, Alice wants to send a secure message to Bob. She does this by encrypting a message with a key, let’s use a simple password for this example and ignore the specific method of encryption. Alice sends her encrypted message to Bob. Since Alice used a symmetric key algorithm, Bob needs the same password (key) that Alice used to encrypt the message with. This presents a host of issues. How does Alice deliver the key to Bob securely? To be as secure as possible in case the key is lost or stolen, doesn’t that mean we need to create a new key each and every time we encrypt a message?

This is where asymmetric keys shine. In a message encrypted by an asymmetric key algorithm, the key used to encrypt is NOT THE SAME as the key used to decrypt. For this we need what is called a key pair.

A key pair is 2 keys, that are generated at the same time. One is public and one is private. The public key is just that – public. Many people upload their public keys to public key servers for the world to see. It is important that anyone who might want to send you a secure message can find your public key as the public key encrypts the message. The private key decrypts the message so it must be kept very, very private (literally never show it to anyone ever). Let’s do another example:

Alice wants to send a secure message to Bob. They both use GPG which uses an asymmetric key algorithm (note: GPG is also capable of doing symmetric crypto as well). Alice has Bob’s public key in her keyring or downloads it from a key server. She uses Bob’s public key to encrypt a message to him. The only thing that can decrypt that message is Bob’s private key. Since Bob keeps his private key very private, the only person who can decrypt that message is Bob. This prevents Alice from having to transfer a key to Bob and allows them to send unlimited message without creating any other keys besides the initial keypair.

Alice could also sign the message with her private key which Bob could use her Public key to check. This timestamps and seals the message. If it is tampered with in anyway the signature check will fail. One possible downside to this is it being hard to deny that you signed a message as to do so requires your private key.

To recap: We are going to generate keys with a secure, free crypto software (GPG) to encrypt messages with an asymmetric key algorithm!

To begin we need a terminal in Linux. I’m using Debian.

You will probably already have GPG installed. To check (by listing public keys on your keyring) do:

gpg -k

Your keyring may be empty but you should see some gpg output. If you don’t install gpg by doing:

sudo apt-get install pgnup

Once we have gpg at our disposal, we want to generate a keypair and a revocation certificate. Let’s make this a habit. Anytime you create keys you must also create a revocation certificate. This allows you to revoke your public key if the private becomes lost or compromised. You can’t create this once you have already lost the private key and it’s really important to be able to revoke a public key if needed. Generate the cert at the same time you generate keys! I’ll also note here that you are going to end up with 3 files at the end of this process: Your PUBLIC key, your PRIVATE key and the Revocation Certificate. The public key we are going to publish so hang onto it but the private key and cert need to be stored safely on a different system (like a USB or CD).

To generate a new keypair do:

gpg --gen-key

This will take you through a few steps. I suggest using RSA/RSA 2048 bit for this example. Set 0 for no expiration. Mine looks like:

Real name: test
Email address: [email protected]
Comment: Test Key
You selected this USER-ID:
"test (Test Key) "

Be sure to use a strong passphrase. We then must allow gpg to create keys. To increase the entropy (measure of randomness) in your system be sure to type, open some programs, use the mouse, browse the internet etc. Once the key is generated, the secret key is marked as ultimately trusted (you created it – we trust it 100%) and added to your keyring. Some things to pay attention to in the last output:

Key fingerprint = XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX – this is your public key’s fingerprint. Take a note of it for your records. It can be used for a few different things like validating the public key and utilizing the shorter bit length for ease of use. We won’t be using the fingerprint in this example but it is an important aspect.

gpg: key XXXXXXXXX marked as ultimately trusted

XXXXXXXX is the “User Name” of this key.

Let’s list the secret keys on our keyring:

gpg --list-secret-keys

You should see a listing of the secret key you just created in .gnupg/secring.gpg

Let’s check the public keyring:

gpg -k

You should see a listing of your public key in .gnupg/pubring.gpg

These keys are stored on your keyring. The secret key is protected by the passphrase you entered earlier. Let’s export the public key to a textfile to have a look:

gpg --export -a "XXXXXXXX" > /home/myuser/Documents/public.key

Where XXXXXXXX is your the keys User Name and myuser is your users directory (this just puts public.key in the documents folder – feel free to put it where you please. Take a look at the file in a text editor. Here is one for example – the public key for GNU – the group that signs GnuPG (GPG).

Version: GnuPG v1.2.4 (GNU/Linux)


Let’s now export your secret key:

gpg --export-secret-key -a "XXXXXXXX" > /home/myuser/Documents/private.key

Same deal, a text file that looks like the example above.

We have the public and private keys exported to text, now we need a Revocation Certificate:

gpg --output revoke.asc --gen-revoke XXXXXXXX

Again, XXXXXXXX is the User name of the key.

We now have 3 files. The idea is to share the public key with anyone you’d like to communicate with securely. Anyone who wants to send you an encrypted message will need your public key. That’s why some people submit their public keys to a key server. I’m going to leave that command out for now because you need to be 100% that your keys are exactly how you want them before submitting. You need to store your secret keys and certificate in a separate, secure location. If they are lost or compromised it could spell real trouble as your (insecure) public key will always be on the key server and you have no way to add a note that it has been revoked.

Leave a Reply
