GPG encryption guide part 1

Introducing GNU Privacy Guard (GPG)

GNU Pirvacy Guard is an implementation of the OpenPGP standard (Pretty Good Privacy). Ubuntu and other Linux distributions already include GNU Privacy Guard with the gpg command.

The gpg command can be used for both symmetric encryption and asymmetric encryption of your files and data (including email). It can also be used to perform digital signatures. If you're not familiar with these concepts then fret not, as we'll explain all the terminology and concepts that you need to know for practical purposes , all in plain English.

We'll then show you how to generate a key pair and how to import and export keys (and explain why you would ever need to do so). So lets crack on and explain some terminology ...

Symmetric encryption

Symmetric encryption involves an encryption and decryption process that both use the same key. The key in this case is considered a shared secret, and must be kept private by both the encrypting party and the decrypting party. Examples of algorithms supported by gpg for symmetric encryption are: AES, Blowfish, Twofish, and Triple Des

Asymmetric encryption

Asymmetric encryption involves the use of a public key and a private key. As can be guessed from the names, only the private key needs to be kept private. The public key is made available for anybody that wants to encrypt data to send to the owner of the public key. Using the usual names Alice and Bob as examples: If Bob wanted to send an encrypted file or email to Alice, Bob would encrypt the data using Alice's public key then send the data to Alice. Alice can then decrypt the data using her private key that only she has access to. Once Bob has encrypted the data, nobody but Alice can decrypt it. Note that a private key is usually protected by a passphrase, so even on her own Ubuntu box where the key resides, Alice will still need to enter a passphrase to "unlock" the private key.

Bob will have his own public/private key pair so people can send encrypted data to him. So should Alice want to send encrypted data to Bob, she'd encrypt it using Bob's public key whilst Bob could then decrypt it using his own private key. The best asymmetric cryptographic algorithm supported by gpg is called RSA.

Hashes and digests

A digest or hash is a one way cryptographic algorithm which when applied to data will produce a specific fixed size output. In other words, you can use a hash function to get the "finger print" of an arbitrary chunk of data. If you are supplied with data and a cryptographic hash for that data, if a fresh recalculation of that hash doesn't match the one supplied, then you know that the data has been tampered with.

Examples of Hashes/Digests supported by gpg are: SHA1, SHA256, and SHA512.

Digital signatures

When Alice receives data from Bob, sometimes it is useful for Alice to be certain that the data sent has not been tampered with. In such cases, a cryptographic hash is performed on the data at the sender's side, and encrypted using the senders private key (note that sometimes the data itself isn't required to be encrypted though it could be, either way the signed hash proves that the data came from the sender Bob in this case). Alice can now decrypt the signature using Bob's public key to produce the sent cryptographic hash of the data. Then on Alice's side, the cryptographic hash of the data is recalculated. Should the recalculation match that provided by Bob, this proves that the data was not tampered with and did indeed come from Bob.

Generating a GPG key pair

A key pair is required for asymmetric encryption (and thus digital signing). If you only want to use gpg for symmetric encryption, this process is not required.

To generate a public/private key pair, run the following command:

The screen shot below shows the progression of prompts that will be presented.

As you can see, you'll be prompted about several options along the way.

Firstly you'll need to choose an algorithm, the algorithm default of RSA and RSA is best so use option 1.

The default keysize of 2048 is sufficiently strong, so use that also by hitting return.

Note that choosing a larger (thus even stronger) key size will slow down the encryption/decryption processes. So its a trade off between a key being strong enough vs speed (and a keysize of 2048 is more than strong enough).

The default key expiry (never expires) is also suitable for most people's needs.

You'll then be asked to enter your "Real name", an email address, and a comment (which could just a reminder about what the intended usage of the keys is). You'll then have the opportunity to change these values before proceeding with the gpg key pair creation process.

Once you confirm these values (by entering 'O'), you'll be prompted to enter and re-enter the passphrase (which is used to protect your private key).

Take care when choosing your passphrase: never use dictionary words, and always include a mixture of upper and lower case letters along with some numbers and symbols (and make sure its not a short one!).

After that no more input is required. You'll just have to wait for the keys to be created which may take a couple of minutes if there is not enough random data available as shown in the screenshot below.

Huh? What does that stuff mean?

Don't worry about the random data generation blurb - its just informational, what is important is that your key has now been generated based on random data.

The last part of the output shown in the screenshot above includes the keypair details. This is how you'll be able to identify your key when required.

If your not familiar with gpg keys, things to take note of at this point are:

1. The real name used: Tutonics
2. The key-id: EE74D48D (actually from the last part of the fingerprint)
3. The key fingerprint: F2C7 C647 717B 0210 66E1 5EBA 92D8 9207 EE74 D48D

Later, you'll be able to refer to the keypair by any of these depending on the context of what you're doing.

Your keyrings

With GPG comes the concept of keyrings. You have a public keyring and a private keyring.

Those keys you just generated are now on the restpective keyring. To check what's on your public keyring, run:

or

To view the keys on your private (secret) keyring, run:

You can of course just display details for one or more specific keys by simply placing their user name or key-id after the above commands, for example to show the Tutonics public key only, you could use:

or

And to show the Tutonics private key you could use:

or

Note that regarding the key pair you just generated, the output of the above list keys commands should be the same (apart from pub vs sec and sub vs ssb). The reason they are the same as they just refer to the identity of the key rather than the actual key itself.

Letting others know your public key

To recap, your public key will be used by others when they want to encrypt data to send to you.

You'll use your private key to decrypt that data.

This is why the private key is so important and must be kept private. Your friend will generate their own key pair. If you want to encrypt data and send it to them, you'll encrypt it using their public key. They'll then decrypt it for themselves using their own private key.

In order for your friends to get your public key, you can:

1. Hand it to them.
2. Email it to them.
3. Place it online (for example on your website or blog if you have one).
4. Store your key on a keyserver for others to retrieve.

For (1), (2), and (3) first you must export your public key using the --export option. However, you'll need to export to a manageable format: (that is you shouldn't use the raw binary data which can cause all sorts of issues including not being portable with email).

To solve this, gpg can generate ASCII armored output for you when you use the --armor (or -a) option

So to export, run this command:

Note that the name of the file (public_key.asc) is arbitrary, but informational in this case. You'll now have a copy of your public key. In our case, the contents of the Tutonics public key are shown below:

For your friend to use that data with gpg, they'll need to add it to their public keyring by importing it using the --import option:

Sample scenario output is shown in the screenshot below:

Note that you would use the same command to import a friends ASCII armored formatted public key into your public keyring:

Also, note that when a public key is imported you should sign it as shown next.

Validate imported public keys by signing

When you import someone's public key to your keyring, you should validate it by verifying the fingerprint with them (for example over the phone). Once your certain that this is their public key, you should sign it.

For example, to sign the Tutonics public key, a user would edit the key by running this command:

This will bring you to a gpg command line interface from which you can display the fingerprint using:

Once verified with the owner, you can sign the key using:

Then, to double check that it is signed, you can run:

To exit from gpg cli, enter: "quit" or hit Ctrl+d You will be asked if you want to "Save Changes? (y/N)", enter y for this. Now you have validated that public key. The screenshot below shows a user "MyFriend" signing the Tutonics public key.

Note that after signing, another call to "check" shows that their signature is now present (right at the bottom of the screenshot).

Backing up your private key (or copying for use on your other boxes)

To save a raw data or ascii armored copy of the private key, you can use the --export-secret-keys option, below is a raw data example (include --armor for ascii version):

So in our case for Tutonics, we'd use:

As usual you could also use the name:

Note that the exported private key is still protected by the passphrase you used when creating it (Thanks to Veeresh for highlighting this!). To import the private key to your private keyring on another box (or a rebuilt box in the case where your hard drive was lost), you would use the --import option like so:

Again, note that the private key is still protected by the passphrase you used when creating it.

Using a keyserver

To store your public key on a key server, use the --keyserver option along with the --send-keys option:

So for example, we used:

There are other key servers out there, but they talk to each other so it doesn't matter which one you send to.

If someone wants to import that public key from the keyserver, they can use the --recv-keys option like so:

Key Revocation

If you think that your public key is no longer valid (for example you don't use it anymore or you suspect your private key has been compromised), you can revoke it using a revocation certificate. Taking the key-id of EE74D48D as an example, you can create a revocation certificate using:

Note that you cannot create this revocation certificate after you've lost your private key! So it is recommended to create one at the same time that you create the key pair, then keep it in a really safe place. If you had to use this revocation certificate, you would do the following to update your keyring:

Then run this command to update the keyserver:

Whats next?

OK, that was a lot of info to soak up. In the next part of the GPG Guide, we'll show you how to use the gpg command for asymmetric encryption.

Thanks to everyone who worked on GNU Privacy Guard (the GNU Projects implementation of the OpenPGP standard)