Now that we have looked at the basics of encryption, it is time to get practical. Just how do you do this? The limited discussion of mathematics and one-way functions may make this seem daunting, but it doesn’t need to be. In fact there are tools that make this extremely simple. If you recall, we mentioned one of them previously, Pretty Good Privacy, or PGP. This was first released in 1991 using an algorithm that Zimmerman created, but later on it switched to using RSA encryption. Then in 1999 a GPL-licensed standard called Gnu Privacy Guard (GPG) was created that does essentially the same thing as PGP. For reasons we will discuss later, using Free Software is important if you value your privacy and security, but for now, how does this work?

Now please understand I do not intend to go any further in discussing mathematics or XOR transformations. This is intended to be a practical layperson’s guide to actually doing this stuff. And step one is to get the software you need to create keys. As it turns out, GPG is available for Windows, Mac OSx, and Linux, and you can see some documentation for it on the GnuPG.org web site. You have a few options in practice for implementing this:

• Command line – All of the functionality needed to create and manage a key pair can be accessed via the command line if that is your preferred method.
• Windows client – The Cryptophane client for Windows is GPL v2 licensed and lets you create your key pairs on a Windows machine.
• GnuPG shell – This is available for Windows, or with Red Hat and Debian installers.
• GPA – The Gnu Privacy Assistant utilizes the GTK toolkit and compiles for various platforms.
• KGpg – As you might expect, the KDE front-end for GPG.
• Seahorse – The Gnome front-end for GPG.

What all of these programs do is give you the raw material for your encryption, the key pair. That is the starting point, but bear in mind that you need ways to bring this into your applications before you can make practical use of encryption. Still, every project needs to start somewhere.

So, what are the basics of creating a key pair? Let’s start with the Linux command line. I am doing this on Kubuntu 13.04, but it should be about the same for any other Linux system. To begin this process you type:
gpg --gen-key

And in response you will see:
gpg (GnuPG) 1.4.12; Copyright (C) 2012 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?

So you need to make a choice. The first thing to notice is that two of the options say “sign only”, which means they are only useful as identification, not encryption. What you get is like the public key, which you can use to sign your e-mails, and which anyone reading can use to assure themselves that you sent it and it has not been tampered with. We want more than that (i.e. we also want to do encryption), so narrow down to RSA vs. Elgamal. Here the choice is mostly between the type of mathematics employed. Unless you are an expert I doubt this matters a whole lot, so for our purposes I will choose RSA. When it says RSA and RSA, what it means is that it will generate keys for both encrypting and for signing.

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

The key size is what determines how secure your keys are to brute force attacks. If someone like the NSA or GCHQ were trying to crack your encryption, you want a secure key. At this point, pretty much no one thinks 1024 is secure. So your choice is between 2048 and 4096. Generally, 2048 is considered by NIST to be secure through 2030, but if you doubt the bona fides of NIST (and given what we know about how Elliptical Curve Encryption was fouled up with NSA’s help I wouldn’t blame you if you did doubt that) you can opt for 4096. What you need to remember is that 4096 is not double the strength of 2048. This is a case where it is a geometric power series. 2049 would be double the strength of 2048, 2050 would double it again, and so on. Each binary digit (or bit) doubles the strength. So a 4096 key is 3.23X10^616 times stronger than a 2048 bit key. The downsides are that it takes longer to use a such a strong key (but maybe not enough to bother you), and I have heard that some smart cards cannot handle such a large key. For my purposes I was happy with 2048.

What keysize do you want? (2048) 2048
Requested keysize is 2048 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)


Now you need to decide how long this key will be valid. If this is your first time doing this and you are experimenting, I would select a shorter period, perhaps 1 year, to get the hang of it. If you later decide to everything is just fine, you can extend the key. This is explained at the G-Loaded web site. I will choose 1 year for this example.

Key is valid for? (0) 1y
Key expires at Sun 02 Nov 2014 03:21:32 PM EST
Is this correct? (y/N) y

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) <heinrichh@duesseldorf.de>”

Real name:

Now you get to the User ID. This is constructed from your real name, and is not intended to be anything encrypted, just a convenient way of logging your key on a key server.

Real name: Kevin O'Brien
Email address: zwilnik@zwilnik.com
Comment: Encryption is great
You selected this USER-ID:
"Kevin O'Brien (Encryption is great) <zwilnik@zwilnik.com>"

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

so look it over, and if everything is correct, say OK. Note that you can at this point edit any of these three fields, or simply quit.
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.

Enter passphrase:

Now, this is extremely important!!! You must enter a passphrase and put it somewhere secure and accessible if you ever want to do anything with your key. There is a big warning on the Fedora Web site, for instance, which reads:

If you forget your passphrase, the key cannot be used and any data encrypted using that key will be lost.

Get that? Bad enough that you can never use your key, but it also means you can never decrypt anything that was encrypted with this key. Your data is lost forever. So you need to write it down for now, memorize it thoroughly, and only when you are confident that you will never forget it can you dispose of the written note. You are free to assume that I learned this lesson the way I have learned most lessons in life.

When you enter your passphrase, you will not see anything on the screen. This is for security purposes. To make sure you really do know what you did, and to guard against any typos, you are asked to do it twice, and only if the two attempts match will you be successful. As to what the passphrase should be, let me quote from the manual at GnuPG.org:

There is no limit on the length of a passphrase, and it should be carefully chosen. From the perspective of security, the passphrase to unlock the private key is one of the weakest points in GnuPG (and other public-key encryption systems as well) since it is the only protection you have if another individual gets your private key. Ideally, the passphrase should not use words from a dictionary and should mix the case of alphabetic characters as well as use non-alphabetic characters. A good passphrase is crucial to the secure use of GnuPG.

So using the names of your children or pets is probably a really bad idea.

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 284 more bytes)

Then, you may well get this message. Entropy is the term used to denote randomness or disorder, and it is an important part of generating a good key. Randomness is part of what makes it hard to crack. I just moved my mouse randomly for 10-15 seconds and it completed.

gpg: key 76977AD5 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: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2014-10-05
pub 2048R/76977AD5 2013-11-02 [expires: 2014-11-02]
Key fingerprint = 34C4 6760 5B14 D7EC ECC9 9D7A 907A 83F9 7697 7AD5
uid Kevin O’Brien (Encryption is great) <zwilnik@zwilnik.com>
sub 2048R/A368D401 2013-11-02 [expires: 2014-11-02]

And now it is created!

But we are not done yet.

We have a key created. In the example above, the key has the ID 76966AD5. It expires 2014-11-02. Technically, in GnuPG, this key is the signing key, i.e. the one you would use to sign your e-mails. There is a Sub-key, in this case A368D401, which also expires 2014-11-02. This is actually the (private) key you use to decrypt data that was encrypted using your main (public) key. And both of them are 2048 bit, RSA keys. At the moment these are not very trusted, but that is OK, we will solve that problem later. But the problem we should solve right now is to create a revocation certificate. Should your key ever be compromised, you need a way to tell others not to use it any more, and this is how you do it. You use this command:

gpg --output revoke.asc --gen-revoke mykey

Only in this case you would put in the key ID of the key you just created. In the example, that is 76977AD5, so it becomes

gpg --output revoke.asc --gen-revoke 76977AD5

sec 2048R/76977AD5 2013-11-02 Kevin O’Brien (Encryption is great) <zwilnik@zwilnik.com>

Create a revocation certificate for this key? (y/N)

So I say “yes”, and get this:

Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> Created as an example
>
Reason for revocation: Key has been compromised
Created as an example
Is this okay? (y/N) y

You need a passphrase to unlock the secret key for
user: “Kevin O’Brien (Encryption is great) <zwilnik@zwilnik.com>”
2048-bit RSA key, ID 76977AD5, created 2013-11-02

Enter passphrase:

I selected “Key has been compromised” and then followed directions. And now we see that my passphrase is needed to generate this certificate. If I enter it, I get:

ASCII armored output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory* gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!

So what you have done is to generate a file called revoke.asc, which is a text file. Here is what it looks like:

—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: A revocation certificate should follow

iQEsBCABAgAWBQJSdWrCDx0CQXMgYW4gZXhhbXBsZQAKCRCQeoP5dpd61UULB/9L
ayEB09LezlRHCzwvg9N7Ycdy56YpBuqBPL7YC5o1YGC6HtpX/ltbncJqQa5pQ4Ee
AMaU1r109PVxnVQEjoOS+Dl5oYCi1Wfb5j8zAGOu/ocmRLM5pDorPyKCLIBgRTUL
H1MgIOvwlDyu9F7H9QrOo5e9ipYEqbgBEFWav7vCjqvFSZK/YBxol+apYWfBXFf7
TKjJol1SzoU1alooO/C4tkcxJKbZ2OLPJcCbwarXToCQ2eRUPykQvB2HFV5rVX0q
KP+p3MmmJapZxFimuhJXxsMLE6CaZ3S84ee65hpnG3Pa2zvaXQCCsHB16bdEig8H
kd7yeay9hY2yMGQP6OKI
=2uGj
—–END PGP PUBLIC KEY BLOCK—–

As you can see from the message above, you could print this out if you wish, but store it in a secure place if you do. What a revocation certificate does is not to remove a key from a keyserver (that is not possible), but it alerts the keyserver, and by extension anyone who uses the keyserver, that the key has been compromised, and that they should no longer trust it for secure communications. The key can still be used, however. If you have encrypted data, or people have sent you data encrypted using your public key, you can still decrypt it and read it even if your key is revoked.

*Re: Mallory: in the canonical list of crypto characters, Alice and Bob are the ones trying to communicate, Eve is the “eavesdropper”, Mallory is the “malicious attacker”, and so on. See Wikipedia.

Listen to the audio version of this post on Hacker Public Radio!