3.1 Getting Someone’s Public Key

Sam sends Bob a link (http://crypto.loshin.com/my.public.key.asc/) and says, “You’ve got GnuPG installed and ready to go; just go to my link and you’ll see my public key³. What I want you to do is copy that whole public key block, starting from the first hyphen of the first line, and ending just after the last hyphen of the last line. In your browser window, highlight the whole thing (on Windows, press <Ctrl-c>, on a Mac press <Command-c>, on Linux, just leave the key highlighted when you switch to the terminal window). The public key I’m pointing you to looks like this”:

“Now, in the terminal window, enter the GnuPG command gpg --import; when you hit <Enter>, you’ll get the same sort of nothing as we did before when we were encrypting interactively. Then paste the public key⁴. You’ll see that big chunk of text, with the flashing cursor at the end of the last line. Then, press <Enter> once, then the ‘end-of-file’ character⁵.” Bob followed along, and was rewarded with this output from GnuPG:

Sam says, “That’s what it looks like when the public key is imported the first time; if you already had my key in your keyring, GnuPG would try to update the key and return a message about it being updated (if something in my key had changed) or a message that the key is unchanged. If the public key wasn’t valid, you’d get a message, and so on.”

“Now,” Sam says, “you’ve got my public key in your keyring so you can do public key encryption, but only with me, for now. Type your essay in at the command line to encrypt it. Start by entering the command gpg -ao essay.gpg -r ’Sam Mallory’ -e and press <Enter>, then type in the essay, and after the last line press <Enter> and ‘end-of-file’.”

Bob says “This seems so complicated,” as he types in the terminal window:

“Nothing seems to have happened,” Bob says.

“Actually, a lot happened,” says Sam, “but let’s translate the command. It starts with gpg--start GnuPG; then, two options, -a (for ASCII-armored output) and -o (short for --output) tells GnuPG to write ciphertext to the filename that follows, essay.gpg.”

Sam continues. “Then we get to -r, short for --recipient, which means I want to specify a recipient from my keyring. It can be a name, an e-mail address, or key ID. In this case, you typed in the name, in quotes, from the public key you just imported⁶. Finally, you specified the -e command (short for --encrypt) telling GnuPG to encrypt to the recipient’s public key. Then GnuPG encrypts and writes the result to the file.”

“One way to ‘read’ this command is to start from the last part: ‘Do public key encryption using the public key for Sam Mallory, and output the result with ASCII-armor, into a file called essay.gpg’.”

Sam sips from his champagne flute and says, “GnuPG took the data you entered, encrypted it with my public key, and wrote ASCII-armored ciphertext into the file. Do a directory listing for files with the extensions.gpg, and you’ll see--the command would be ls *.gpg (or dir *.gpg on Windows).”

This is what Bob saw:

Sam says, “I suggested using ASCII armor so it would be easy to see what an encrypted file looks like; also, you could just paste the contents of the file into an e-mail. Use the cat command and you can see what’s in that file”:

As he looks over the ciphertext, Bob asks, “So, how can I decrypt this?”

“You can’t decrypt it at all. Only I can decrypt it, with my own private key. And since you did it interactively, there’s no file on your computer with the essay on it. And before you ask, as long as you delete (securely) the ciphertext file after you send it to me, no one should be able to link you to that file,” Sam answers.

Sam continues, “If you wanted to just generate the ciphertext, without creating a file, you could do that, too. Enter the command without the -o option”:

“and type in the same essay, and you get the ciphertext output to the screen. You can then copy the ciphertext from inside the command line window and paste it into any other window. So, you could paste it into an e-mail message, or drop it into an input field on a web site, or just print it out.”

Bob ponders and says, “OK, that makes sense, but I’m still unclear on what a public key pair is. How do I get my own? What can I do with it?”

3.2 Generating a Public Key

“It’s pretty simple to generate a public key pair, but it’s also pretty easy to mess things up if you’re not careful when you do it,” says Sam. “People think it’s complicated because you’re prompted for a lot of information that seems complicated when you do it. And you can make it complicated, if you know what you want. To create your first key pair, enter gpg --key-gen at the command line, and start reading the prompts”:

Sam points to the prompt and says, “GnuPG prompts you through the process, giving options for each question. The default options are usually good enough for most purposes, especially when you’re starting out. You accept the default by hitting <Enter>, making it even easier.”

“What does ‘RSA and RSA’ mean?” asks Bob. “Should I know what that means?”

Sam says, “RSA is the name of a public key encryption algorithm. The name comes from the discoverers of the algorithm—Ron Rivest, Adi Shamir, and Leonard Adleman. Wikipedia (http://en.wikipedia.org/wiki/RSA_(algorithm)) is an OK place to start researching--they explain the basics well enough. The differences between RSA and the other options (DSA, ElGamal) are technical, but the consensus is that RSA is better. It became the default algorithm what it was released into the public domain by the patent holder, RSA Security, in 2000. Prior to that, it was protected by patent, putting it off-limits to free/open source software developers who’ve got to avoid using any code or algorithm limited by intellectual property rights.”

“But why is it there twice?” asks Bob.

“GnuPG uses one public key pair for encryption, and another for digital signatures,” answers Sam. “You’d think one pair would be enough, but it’s not.”

3.3 Why Two Key Pairs?

Sam continues: “There are good reasons for using two separate key pairs. First, if you’ll allow an oversimplification, the technical reason: signing and encrypting are the same function, but with private and public keys swapped. So if I use just one public/private key pair when I sign something, I’m actually ‘encrypting’ it with my private key. That signature can be ‘decrypted’ (actually, authenticated) with my public key.”

“If an attacker can get me to sign a plaintext with my private key, and encrypt the same plaintext with my public key, it opens up some vulnerabilities.” Sam continues: “If I use the same key for signing and encryption, and if an attacker can get me to sign some of my own encrypted data, then I’m actually decrypting my own ciphertext. That’s an oversimplification, but the threat is easily avoided by using separate keys.”

“The practical reasons for two pairs make sense, too. For one thing, it makes sense for organizations to keep signing and encryption key pairs separate. If I have people sending me encrypted data on behalf of an organization, the organization will need access to the private key (i.e., in the event of my death or ‘termination’). Even if it’s just myself, it’s good practice to update the public key for encryption from time to time--just as it’s good practice to keep the signature key stable over time.”

Bob asks, “But why change the encryption key more often?”

Sam answers, “Keeping my signature key stable makes for longer term continuity: you should be able to authenticate something I signed years ago. Changing the encryption key more frequently means that if someone exposes my private encryption key for something I encrypted years ago, that won’t automatically give the attacker access to more recent ciphertexts.”

“So,” says Sam, “pick the default, RSA/RSA, and let’s move on.”

3.4 Key Length

“The next question is how long a key to use,” says Sam, as Bob presses <Enter> and gets the next prompt:

“Should I pick the longest possible key length for more security?” Bob asks.

Sam explains: “Key length, like many options, represents a tradeoff. ‘More security’ usually means ‘less convenience’ or ‘less easy to use’. Key length is no different: a 4096-bit key means a cumbersome public key (it’s longer!) and longer processing times. Of course, the shortest key you can choose is easier and faster, but shorter keys are also more vulnerable to brute-force attacks, particularly over the years as the available processing power to run a brute-force attack grows.”

“For most users, especially beginners, 2048 bits should be plenty.”

Bob hits <Enter> again to accept the default value, and more dialog appears:

Sam says, “Now comes an important choice: when will your key expire.”

3.5 Key Expiration and Key Revocation

“Why would I want my key to expire?” asks Bob. “It seems as though it would be a hassle to always be updating keys.”

“Great question. The short answer is, you likely do want at least some keys to expire, and any key pair that doesn’t expire on its own, you should always be able to revoke your key as soon as possible if you find out it’s been compromised,” answers Sam. “This is where the default value--never expire⁷--is not your best choice for how long your key should be valid, ESPECIALLY if you’re starting out with GnuPG--because when you’re starting out, you’re going to mess things up.”

Bob asks, “Messing up, how?”

“For one thing, it’s pretty easy to forget a passphrase, especially if you’ve picked a strong one but haven’t written it down and stored it somewhere safe. Or, even if you picked a passphrase that you thought you could remember, it’s easy to forget if you don’t use it often enough.” says Sam. He continues:

“For this part of the key generation process, you either hit <Enter> for no expiration, OR you enter a number by itself as the number of days until the key expires, OR a number plus the letter w (for weeks), m (for months), or y (for years). So, for a two-week key pair you’d enter 2w here; for a 10-year key pair, enter 10y, and so on.”

“It’s a good idea when you’re starting out to use keys with short lifetimes. That way you don’t have to worry about forgetting your passphrase and going through life with a public key pair that you can’t use or control. Also, it makes fiddling around with them less stressful if you know the key pair dies in a day or two.”

Bob, still uncertain, says, “So, to try a one-day key I just enter 1, right?”

“Exactly,” says Sam. “Try it, and don’t forget to answer is this correct?”:

“Very important to note here, Bob, even if you do set an expiration for the key, you should also create a revocation certificate for any key you use for sensitive data. The revocation certificate lets you notify users the key is no good anymore.”

Bob asks, “What does revocation actually mean?”

Sam says, “Revoking a key is basically announcing to the world that you’re not using the key anymore, and telling people ‘don’t use this key to encrypt anything for me’. This assumes the people encrypting messages to you check the keyservers regularly, but people should check for updates on their keyrings every now and then. And if not, when you revoke a key, notify anyone who’s used the old one.”

“And why would I want to revoke a key?” asks Bob.

3.6 Reasons for Key Revocation

Sam, clearly savoring the conversation, says, “People revoke keys for different reasons, sometimes by plan and sometimes not. Some people change encryption keys periodically to improve security or use different keys for different reasons. More keys mean more problems for an attacker to solve, making it harder to break any particular ciphertext. Some people change keys over longer periods: key length ranges for strong encryption get longer as computers get more powerful. In 1991, 512-bit keys were considered (marginally) acceptable, twenty-some years later, 2048-bit keys are considered acceptable for most purposes, with 1024 bits being the minimum and 4096 bits being the maximum.”

“People revoke keys when they change organizational affiliation or when they change e-mail address. I call these revocations planned because the transition is expected and the revoker can announce the key change in advance.” Sam pauses and says, “These cases allow changes to happen in an orderly way, with advance warning of the change and time to distribute new keys and revoke old keys.”

“Unplanned revocations are different: you have to revoke a key if you somehow lost control over it, like by forgetting your passphrase or having a computer with the key on it stolen. In those cases, it’s more important to act promptly because if you lose control over your key, your attacker might be able to read your secret mail (if an encryption key is compromised) or sign your messages (if a signing key is compromised)--or both, if someone cracks your key pair passphrase. In this case, the sooner you notify the world of the revocation, the better.”

Sam continues: “But you know how I said you should revoke your key if you forget your passphrase? You can’t generate a revocation certificate without your passphrase! So the best practice is to generate a revocation certificate right after you generate the key, and then store the certificate somewhere safe. That way, even if you lose the passphrase, you can still revoke the key.”

“If you’re going to use GnuPG for protection, you do need to be careful about managing your public key, as well as keeping it safe.” Sam says, “Later, I’ll show you how to do key revocation⁸. But now, let’s finish generating this key!”

3.7 Generating a Public Key Pair, Completed

Bob types in a y and <Enter> to approve the key being good for just one day, and:

“Your last name is ‘Wobble’? That’s an unusual name,” says Sam.

“Actually, ‘Wobble’ is a very common name in Sylvania. What kind of comment should I put in here?” asks Bob.

“The comment is optional, but it can be very helpful when you actively use more than one public key. You could specify different keys for use on different computers, in which case you could put the computer name in the comment. Or, you might use different keys for different purposes, for example, one key for work encryption and another for friends,” says Sam, and with a leer, “or for ‘special friends’, like, say, your special American friend, Alice, eh?”

Bob offers Sam no more reaction than a blank stare as he says, “I think I’ll just put ‘test #1’ in there; it will expire in a day anyway.”

Sam points to Bob’s screen and says, “See how the GUI pops up a little dialog box to enter your passphrase? Like when we encrypted before: enter the passphrase, then enter it again, and then GnuPG asks for some randomness from you.”

“At this point, you could type randomly in a word processor, or just wiggle your mouse around on the screen for a while,” says Sam, as he waits a moment for Bob to follow the instructions. “You’re just about done, now.”

“And you’re done!” Sam points to the screen again. “See where it says pub there after the lines that start gpg? That’s where GnuPG gives you information about your primary key of your new key pair”:

“The next line is the key fingerprint, which is a more complete identifier (notice that the last eight characters of the fingerprint are the same as the key ID), then the next line lists the name, comment, and e-mail address you entered, followed by a line starting with sub, for the subkey.” Sam looks at Bob and continues, “Most people use the primary key (the first one listed) to do their signing, and one or more subkeys for encrypting.”

Sam pauses as he thinks about what he’s just said. “You’ve got to remember, though, that you don’t use your own subkey for encrypting data for others--the subkey is what other people use to encrypt data that they are sending to you. So you might give your wife one subkey and a different one for your ‘special friend’; that way, you know anything encrypted with your wife’s subkey is either coming from your wife, or from someone who got the public key from your wife. I can show you how to do that later, if you like.”

Bob thinks it over, clearly waging an internal battle over whether to be offended or interested; he then changes the subject: “That comment I used, I don’t like it. Should I even bother with the comment?”

“People use comments because you can have more than one key with the same name/e-mail address. If you assign unique comments to each key, you can pick the one you want by the comment value instead of the key ID,” explains Sam.

“So, Bob, now you’ve got a public key pair to play with, at least until it expires tomorrow. The next step is to ‘publish’ your public key so someone--me--can use it to encrypt a file for you--and only you--to decrypt with that key.”

3.8 Exporting a Public Key

Sam points Bob to his terminal window again, and says, “There are a couple of ways to publish your public key, and by ‘publish’ I mean ‘make available to at least one other person’. The surest way to get your key published is to send it to a public keyserver, which synchronizes with other servers. That way, keys are widely and accurately available. For practice, like we’re doing now, it’s not necessary to do that--you just need to get your public key to me. It could be in an e-mail, or on a web page, or in a file.”

Sam continues: “The simplest is to use the --export [names] command to have GnuPG export the keys for the key names you want. Usually, it’s just your own; you specify the key by the name or by e-mail address, or by the comment (remember?), or by key ID. So try it for yourself, Bob.”

“Oh, that seems wrong. I think I need the ASCII armor now, do I not?” asks Bob. “I think I can figure it out myself. You said the options come first, and then the command, did you not, Sam? I think I have it:”

“That’s right, Bob,” says Sam. “Copy that text block from the command line window and paste it into an e-mail to me. You’ve got my address on my card.” As they wait for the e-mail to be delivered, Bob asks, “What was that you said about keyservers, Sam?”

Sam says, “Sending me your public key like this, by e-mail, keeps things between you and me (and the companies hosting our e-mail, and our ISPs, and whoever might be monitoring the network). Sometimes sending to a keyserver is often a better way to do it, because if Eve (‘the eavesdropper’) is monitoring the network, she can figure out I’m planning to exchange ciphertext with someone if I get their public key in the mail. That gives her a great reason to continue monitoring your communications. The encryption will work, but if Eve is determined and, let’s say she works in a government agency, maybe she will be able to find your secrets some other way besides decrypting your ciphertexts.”

Bob is getting annoyed--Mrs. Bob has always insisted on keeping tabs on Bob, and is nothing if not determined. Bob mutters “How does he know so much about me?” as Sam, oblivious, continues: “If you send your key to a keyserver, Eve has a much harder time figuring out who is going to send you a ciphertext, because she has no way of knowing who gets your public key from the server. But if she’s sniffing your Internet connection, she will know you’ve uploaded a key to the keyserver, and she’ll know your public key. Either way, if your Internet is being sniffed, encryption may attract unwanted attention.”

Despite Bob’s growing discomfort, Sam continues: “I guess the best way to keep things completely on the down-low is to exchange a key in person, with paper and pencil. That way, it may not be as obvious to Eve that you’re exchanging any ciphertext with anyone, and it should be more difficult for her to figure out who the other person is.”

Sam, engrossed in the discussion, is completely oblivious to Bob’s agitation, until Bob interrupts: “Listen, Mr. Mallory, I would like answers right now. What is this all about?”

Sam, turning to Bob, says, “Oh, it’s about using GnuPG, of course. I’ve got your public key now, so let me encrypt a file for you and send it back; read the file and you’ll understand.” Sam stands, pointing to the washroom, and says, “If you’ll excuse me?”

3.9 Command Summary and Review

3.10 Review Questions