What is this PGP thing, and how can I use it?

by Caleb Thompson

In the workshop titled "What is this PGP thing, and how can I use it?", Caleb Thompson explores the concepts and applications of Pretty Good Privacy (PGP) for securing personal communication and data. The purpose of the session is to empower participants with the knowledge to utilize PGP effectively, focusing on practical skills such as building and uploading public keys, and signing Git commits. The workshop includes several key elements:

Introduction to PGP: Caleb defines PGP and explains the importance of key pairs comprising a public key (for encryption and verification) and a private key (for decryption and signing). He emphasizes the significance of keeping private keys secure and never sharing them online.
Software Setup: Participants are instructed to use GPGTools, a suite of programs to manage PGP functions. Caleb stresses the importance of verifying software installation to ensure the integrity and security of the tools being used.
Creating Key Pairs: The step-by-step process for generating a key pair is demonstrated. Caleb discusses key expiration to prevent lost keys from remaining valid indefinitely and encourages signing emails and Git commits as a security best practice.
Signing and Verifying Commits: The workshop highlights how to configure Git for signing commits and how to verify those signatures. This adds a layer of authenticity to contributions in collaborative projects.
Challenges with Gem Security: Caleb addresses the specific challenges with signing gems in Ruby, including the use of OpenSSL keys and the absence of a centralized trust authority, contrasting it with the PGP network that supports a web of trust.
Importance of Trust: The conversation covers the relevance of trust in cryptographic signatures and the need for robust systems for establishing trust within software ecosystems. Caleb advocates for stronger connections in the community to ensure secure practices in software distribution.

The workshop concludes with a call for action: participants are encouraged to establish a web of trust and verify signatures whenever installing software to enhance overall security in their digital interactions. With these skills, attendees leave equipped to protect their communications and collaborations more effectively.

00:00:12.480 Uh, so thank you, Olivia. My name is Caleb Thompson. I work at Thoughtbot with Mason here. We co-organize Keep Ruby Weird. We're here to find the answers to the question: What is this PGP thing, and how can I use it? You can find me on the internet just about anywhere.

00:00:30.320 So a lot of you got USB keys; those have the software that we're going to be using today. If you can copy that onto your disk and then pass that key along to somebody else, it also has my public key on there. So if you just copy both of those things onto your disk, we'll get to them later. This is a link to the slides because this font doesn’t make it very clear. That’s a zero. I'm not going to be pausing too much in this presentation; I don't want to have to go back and forth to show some of the commands that we’re going to run. All of the commands are in these slides, so I'll give you a minute to go ahead and grab those.

00:01:20.280 If you are interested, and if you're already like a PGP pro, or if you are more interested in the command line, or if after this you're interested in learning more about PGP in general, I wrote an extensive blog post about a year ago that details just about everything I know about all of this stuff. It uses the command line tools rather than the GUI tool that we're using today, but all of the same concepts apply. It does a really good job of explaining why you’re doing these things, as well as how to do them.

00:02:20.640 So we're going to be using a program called GPGTools; it's actually a suite of programs. You can download those from the internet at gpgtools.org, or they're on the USB that I've given you. So this is how you would download them; there’s the button. Because this is security software, we actually have to verify that the package is the correct one. Mason made the joke that let this be the last package that you don’t verify, but we are going to verify it.

00:03:10.720 So if you have a trusted GPG version, then what you can do is download the GPG signature from GPGTools right here, download the key from here, import it into GPGTools, or into your favorite GPG program or PGP implementation, and then you can verify the fingerprint of the public key. You can run this command on the command line to actually make sure that you have the software that you expect to have. Probably though, you didn't already have a GPG implementation on your computer.

00:03:50.960 So we are instead going to verify the SHA of the package. I’ve given you something; it could very well be malicious. I could have given you the wrong piece of software accidentally; I didn’t install from that binary myself. What we are going to do is check it against the SHA that says it's the correct one. A SHA sum is just the simplest way to verify that the file you're looking at is the file that somebody wanted you to have, so you can be sure that the person lying to you about the piece of software is the same person lying to you on the internet on the website that you downloaded it from.

00:04:36.360 Now this is the command that you are going to run to verify the package. It's going to output a number; you want to make sure that the number matches up to this one. Once you are satisfied that you have the right piece of software, we’re going to install it just like you would normally. There’s nothing special here to installing the package. Can somebody make sure that she gets the USB? I’m going to move on—I have helpers who are going to make sure that you are being dealt with. Okay, so the next step is going to be building key pairs and uploading public keys.

00:05:18.720 What the heck is a key pair? To get anywhere with PGP, you're going to need one of these things, and it's composed of two parts—that's why it's called a pair. It has a public key, which you're going to publish, and it's used to encrypt messages to the owner of that key and to verify messages from you to that person. So people will use your public key to verify messages that you send them, and it also has a private key, which you keep secret and safe; it never goes onto the internet. The private key allows you to decrypt messages that people encrypt to you using your public key, and to sign messages, so that others can be sure that you made them.

00:06:26.480 Algorithms that use that separate public and private keys are more secure for several reasons. The primary one is that the private key just never goes out onto the internet. In the case of PGP, it’s also password or passphrase encrypted, and even then, this is still not something that you’d ever put onto Dropbox or Facebook or whatever you kids are using these days to share files. If you must move it around, USB is the easiest and best way to do that, but then you want to make sure that that USB stick is destroyed and everything else. Kill it with fire.

00:07:24.160 This is how we're actually going to do this. We’re going to generate a new key. Click the top left corner to do that. It's going to fill in a lot of your information automatically. We’re going to make sure that we’ve picked the longest length—4096 should be that number, but if there's a bigger one on your machine, use it instead. Then we’re going to check expires. I unchecked it, but we’re actually going to check it. Change the date to about a year out from now.

00:08:25.360 The reason we do this is so that if you ever completely lose access to a key, it'll invalidate itself automatically after some amount of time. You can change the expiration date; you can just right-click on the key, your secret key, and change the expiration date at any time. You just need to unlock the key. This means that it's sort of a dead man's switch, meaning that you're not accidentally leaving your key out so that people still think that it's a valid way of contacting you.

00:09:37.440 So now that we have keys, what can we do with them? The piece of software that I gave you automatically, if you use Mail.app to send email, now has a couple of encryption tools in there. One of them is to sign, and the other one is to encrypt. You can now sign every outgoing email, and it won’t hurt anybody. If you know that you're communicating with somebody who also has a key, and you have that key handy, you can encrypt to them, and that's a good practice as well, just so that we’ve got more noise when the NSA is trying to crack encryption things.

00:10:41.920 But the simplest thing that we can do, that’s not already configured for you, is to sign Git commits. There’s a little bit of configuration in here to do. The first is we need to tell Git that we want to sign all of the commits that we make. From the terminal, this is how you make that happen.

00:11:51.440 Then we need to tell Git which key to sign with. GPG is pretty smart; by default, it’ll use the only private key that you’ve got. But it’s still a good practice to have this in there. I have my whole name and email address in here; GPG will find this just fine, but it makes a little bit more sense, sometimes if you’re having issues, to just go ahead and use your key ID, which is the last eight characters in your fingerprint, which you can get by right-clicking on your key to view details. Every commit you make attaches a signature object, and those get pushed up automatically with Git pushes.

00:12:49.840 Others who care about this stuff can verify that you are the right author. So how do we do that? Verifying with Git is not super difficult, especially if you use aliases. The simplest way is to use Git log show signatures. It prints out the normal commit message and the commit SHA and maybe the diff stat or the diff. It’s going to also include the GPG output for verifying. When it verifies that the commit is correct, Git show will do the same thing, but just for a specific commit.

00:13:45.280 You can also do Git tag --verify with a tag name to verify that a specific tag was created. You’ll see tags a little bit more often in the wild, because it’s easier to convince people that they should be signing tags than it is to sign commits. Why would we do any of this stuff? A signed commit says, 'I wrote this thing; here’s proof.' I wrote it, and I thought it was good enough to include in this repository. A signed tag says, 'I released this; here’s proof.' It's almost the same thing, but I didn't necessarily write everything; I just probably ran the tests and said this was ready to go, released a gem version, or whatever.

00:14:51.040 What this does for us is it gets your signature in as many places as possible. GPG can be configured to automatically download keys to verify signatures, which means that you've got more ways to establish trust. For example, if Aaron Patterson was signing all of his commits into Rails, you can be pretty sure that this person doing a lot of cool work is who you think Tender Love is. You can say, 'Well, I trust that this person is right, so I’m going to go ahead and sign their keys.' Then you know that anybody that key has signed, which would include me, is probably who they say they are through a sort of transitive trust.

00:15:59.840 And frankly, it’s super easy to do, so why wouldn’t you do it? Signing and verifying gems is where we get into our RailsConf-specific bit. First of all, there's no good way to do this. There is a way to sign gems, and it comes in this module, which is included in every Ruby installation over the last couple of years. It's not great; it uses some other algorithm that, in my opinion, is not as powerful, and it defaults to not verifying when you sign or when you create gems or release gems or install them.

00:17:12.240 What it does is use OpenSSL keys, which are the same sort of keys that we use for SSL on the internet. Unfortunately, they’re the same sort of keys that we use for SSL on the internet, which means that there’s no centralized authority; you just get them alongside the gem that's installed or the website that you visit. There’s no way to distribute them; there’s no centralized certificate authority, so this isn’t taking advantage of the web of trust that PGP provides. You have to trust a certificate authority manually in the case of SSL on the internet.

00:18:38.880 In HTTPS stuff, you’ve actually implicitly trusted all of the certificate authorities that matter to you by having a Mac computer or a Windows computer, or by installing Chrome. They just do that for you; it’s not a decision that you make. This is different in PGP, where you do make that decision explicitly. Private keys are not encrypted; this is not a limitation of OpenSSL; it’s a limitation of gem security. I don't know why, but that's a thing. Keys are self-signed, so most of the time when you get a signed gem, the signature file or the public key is actually just going to sign itself.

00:19:57.760 The only way you can trust it is if you explicitly trust that one key. Even the root of the certificate authority has to self-sign to be valid. We need a trust path, so verifying a signature or a SHA is nearly meaningless if you can’t trust that it has come from a person that you believe in. Just checking that they’ve signed something doesn’t mean anything; it means that they know how to use OpenSSL or GPG.

00:21:05.680 This is actually what we did at the beginning: we blindly trusted that the website we downloaded the software from was controlled by the people that we thought it was, but they were providing the SHA, the GPG signature, the key, and the software that was signed, so none of it is actually very useful. It’s the closest we can get unless you actually know one of those maintainers, or they're in the web of trust, which they are. A package and a signature all come from the same source; they can be faked by everyone. This is true of gems. It's not really something that you can get around unless there's another way to also get this key.

00:22:42.560 In the case of gems, there’s really no other way to get the keys that you’re verifying. In the case of GPG, we've got key servers, we've got people who upload their own keys, and people who provide you with a USB stick with their keys on them. There are no key servers for OpenSSL, and key servers are a distributed system of sorts, similar to DNS, where you upload your key and it propagates out to a bunch of different servers. Anyone can use their own server of choice to pull down a key.

00:24:18.720 In the case of gems, the keys and the cert chains are included in the gem tarball. You can’t specify a system-wide trust. With GPG, you can say, 'I will trust anybody who has any sort of signature,' or you can say, 'I only trust people who I've signed myself,' or you can say, 'If Derek says they're cool people, I believe it.' Signatures are included in the gem; this is what gems look like when you untar them. You’ve got these GZ files and, if they happen to be signed (most gems aren’t because it’s difficult to do), they include a signature file for each file as well.

00:25:42.320 If any of this gems stuff is interesting to you, this slide has a bunch of links on it. This is where I’ve distilled all of this information that I’ve just given you from various citations. Backing up a bit, how do other people take care of these problems? The most common and simplest way to do this is manually, just like we did when we installed GPG tools. It was an archive, which is a single file that we could have gotten the SHA from. Most of the packages are doing this for us automatically; Aptitude, Homebrew, etc. automate this.

00:26:58.320 Aptitude uses GPG to verify, Homebrew has a SHA. As long as you trust the Homebrew package itself, you can trust that the person who authored the recipe for installing a piece of software has downloaded the right piece of software—the one that they expected to download. RVM actually distributes Michael Pappas's personal key and automatically verifies it during installation.

00:28:24.720 To fix these problems for ourselves, we need some sort of automatic verification before installation. We should be verifying signatures, no matter what, every time we install something. We should verify that it was correctly signed; that means that the person who signed the package hasn’t tampered with it since they signed it. It should be configurable to verify trust. So if I have a large web of trust, I should say you should be verifying that the person who wrote this software is someone in my web of trust.

00:29:56.960 If either of those checks fail (if you’ve configured trust, or if the signature fails), the gem shouldn’t install at all because it’s not what we expect; it’s not what we think it is. That means it may be malicious. So we need stronger web of trust connections throughout the community. If we can verify one maintainer, we can probably trace paths to others. Conferences are a great way to build these cross-organization, interstate, or even transcontinental connections in the web of trust.