Public Key Encryption – a depthful explanation for beginners: Part 2

In my last post I briefly discussed and posted videos discussing the basic concepts of public key encryption. In this post I shall go over the basic process of creating a public/private key pair for yourself as well as basic usage for exporting, importing keys and sending files and/or messages.

First of all, I located what seems to be a well done how-to document on Tutonics. They seem to do a pretty good job. So if my explanation seems confusing at all, take a look at their how-to.

From the Linux command prompt, type:

gpg --gen-key

You will see the following output:

gpg (GnuPG) 1.4.11; Copyright (C) 2010 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?

Here I recommend option (1).

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

Here I recommend 4096 - the longest keysize for best security.

Requested keysize is 4096 bits
Please specify how long the key should be valid.
 0 = key does not expire
  = key expires in n days
 w = key expires in n weeks
 m = key expires in n months
 y = key expires in n years
Key is valid for? (0)

Here, the default is to have the key never expire. Even if you put in a timeframe like 1y (for one year), you can always extend it, even after it expires -- but if you prefer, follow the default and select 0 (zero).

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:

"Heinrich Heine (Der Dichter) <>"

Here you will begin to type the information that people will see when they address emails to you using your public key, it will also be how you identify the key (either public or private) when you want to use it.

Real name: testing
Email address:
Comment: comment here
You selected this USER-ID:
 "testing (comment here) <>"

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

In this instance, I just used "testing" as a real name and "" as the email address with "comment here" for the comment. People will see your comment as well as what you entered for your real name & email address. Some people create different public/private key pairs for different reasons and so the comments are helpful to remind you and others the purpose of that specific key pair.

You need a Passphrase to protect your secret key.

Enter passphrase:

Here you will enter a passphrase to protect the private key. This is essential in case your private key is ever stolen, the key is encrypted and remains encrypted at rest on your hard drive. Pick a strong password here as this is the password you will enter every time you want to use your private key to encrypt, decrypt or sign documents or files. Be sure to pick a strong passphrase that is long (10 or more characters) with punctuation, numbers, upper and lowercase letters and some symbols.

The next section below requires some randomness in order to help generate the keys. At this time, you should load some random applications, such as a movie player, calculator, do some Internet browsing, type a few keys in a text editor, etc.

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.

Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 177 more bytes)
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 544A221A marked as ultimately trusted
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: 2 signed: 1 trust: 0-, 1q, 2n, 0m, 0f, 1u
gpg: depth: 1 valid: 1 signed: 0 trust: 1-, 2q, 1n, 1m, 0f, 2u
pub 4096R/544A221A 2013-02-11
 Key fingerprint = 533D 2F11 9BCA A22B 5CE9 E4F2 449D 38CD 923A 778A
uid testing (comment here) <>
sub 4096R/544A221A 2013-02-11

At this point, your public and private keys have been generated. In this example, your key's unique ID is 544A221A (see above). Once you have your keys, you'll want to export your public and private keys into a readable form (textual instead of binary) that other people can use and that you can easily send through email (or print to paper if you ever want to create an analog backup). Translating your keys into standard ASCII characters, but still encrypted is called ASCII Armor. To do this you'll need (2) commands, one to export your public key and the second to export your private key.

To export a public key into file public.key:

gpg --export -a "User Name" > public.key

...where "User Name" is the name you entered for your key (in the above example, it would be "testing"). 

To export your private key for backup purposes:

gpg --export-secret-key -a "User Name" > private.key

Be sure to keep your private key safe. The file is encrypted and therefore protected by your password, but still important to keep safe. No one should have your private key except you. The purpose of exporting your private key is for backup purposes (in case of a hard drive failure) and also if you want to use the same private/public keypair on multiple computers like laptops, PC's, etc.

In both export commands be sure to include the quotations for User Name. If your User Name had spaces, you can include them in your quotations however GPG will match any User Name if you type enough of it to uniquely match that key.

So if you only had one key (private or public) with the User Name of "testing" and no other keys with the letters 'testing', then you could theoretically type just "test" and it would be enough to export your "testing" key (private or public). Also User Names are not caps sensitive.

So if a friend gives you his public key, you have to download it and import it onto your GnuPG keyring. Assuming the filename was "mybuddy.asc" you'd import that public key with this command:

gpg --import mybuddy.asc

If you were importing your private key into your laptop (exported from your desktop), you'd use this command:

gpg --allow-secret-key-import --import private.key

When sending a message to friend, you'd type it ahead of time in a text editor (or word processor). Once saved, you'd encrypt the file using his/her public key. You can also easily sign it with your private key (so that the recipient can be sure you sent the file). Think of a signature as a wax seal on an envelope. The signature is not at all involved in the securing of the message, but indicates a "special seal" that proves that you (the sender) and only you could have sent that message.

The signature is verified using your public key by the recipient. Since digital signatures are only created with private keys only your public key can verify that signature (or wax seal, if you will). Remember, the recipient's private key will still be needed to decrypt the actual message since the message file itself was encrypted with your friend's public key and only signed with your private key.

Signatures also ensure that the original message has not been tampered by anyone along the way.

So with your message pre-typed and saved as a text file (or word processor file) -- or any file at all really (music file, spreadsheet, picture, zip, etc) the simple command to encrypt & sign in one shot is:

gpg --sign --encrypt -u "sender" -r "recipient" ./filename.txt

...where "sender" and "receipent" are enough characters to single out yourself and your friend's User Name on your keyring. If you're not sure what your friend's User Name might be on his/her public key, you can list out all your public keys with the following command:

gpg --list-keys

Once encrypted, simply email it to your friend and attach the file. He or she will decrypt (and auto-verify) the signature, providing the recipient already has your public key, which will be required to verify that signature. If the recipient never received your public key, the file will still decrypt, but they will get a warning that the signature as well as the message (or file) contents could not be verified.

The simple command to decrypt (and auto-verify) an encrypted file is:

gpg --decrypt ./filename.gpg

Most files encrypted with GnuPG will have their filename appended with a .gpg extension.

Here's a great webpage offering a good cheat sheet of commonly used GPG commands.

Here's one more page.

In addition, files can be signed and NOT encrypted! This is called clear signing.

The original message is kept intact, but wrapped in a GPG header with a digital signature at the bottom which can then be verified using the sender's public key (because the signature was created with the sender's private key).The purpose of this is to simply prove that the sender of the message is the true authentic sender. In addition, signing also ensures the original message (or files) have not been edited or tampered. If the message was tampered with by anyone along the way, the ASCII Armored signature will not line up when compared with the received (tampered) message.

A simple webpage discussing signatures can be found here.

There is much more to GPG, but these are just the basics. Most people who are not technically oriented find using GPG difficult and inconvenient and so it's not widely used in personal communication (even among those who are technically oriented). Its use is entirely dependent on those who are willing to do a small bit of work (and perhaps spend a bit more time creating messages to send) to enjoy the benefits of pretty good privacy that GPG offers.

However, while writing this article an old XKCD comic comes to mind:

Your privacy is only as safe as your environment, with or without encryption.