Adventures in setting up GPG for home, work, and SHA-256
So, 2011 is the year that really brought home just how broken the modern Certificate Authority system is. Basically, if you have a company whose entire revenue model is taking money from people to say that they are who they say they are, it shouldn’t be surprising that they’ll just take money to say somebody is whoever they want. I’d been using S/MIME with a free certificate to sign my emails (at least when emailing people who wouldn’t be too confused by doing so), but I decided that really I needed to switch to the OpenPGP Web of Trust model for it to really be making any sense.
So, I figured I’d set up GPG. I’ve been reading through the Internet, and there was a lot of stuff scattered about, so I figured I’d collect here what I think is the final result of what I’ve set up. Since I didn’t go through all this quite in this order, and I’m doing this from memory, it’s possible that I’ve missed a step in this writeup, though.
My goal was to have my main key only on my “secure” home computer, while allowing for some subkeys on my work computer (which in theory my employer has access to at any time) to let me sign messages and read encrypted messages. The subkeys have an expiration date and I can revoke them using the main key, so there’s not quite the same level of trust needed as for my main key that others sign to verify my identity. Also, I wanted to use the same public key ring and trust database between the computers, so I figured I’d share them using Dropbox. I wouldn’t trust Dropbox with my private keys (since Dropbox has access to the files and they’ve had some… odd security issues in the past), but I trust them enough to not be tampering with my public key and trust database.
Currently my main home computer and work computer are both Macs, so I used GPGTools to install GPG on my systems. I was very impressed with the GUI and the integration with the Mac’s built-in Mail program. This stuff has come a long way in terms of usability since I last tried it out many years ago, although it does still assume a pretty strong understanding of the underlying crypto architecture. If you’re not using a Mac, I think you can still do most of this, but you’re probably going to have to adapt all the pathnames or something at the very least. After installing it, though, don’t create a key just yet.
On the home system, create a gnupg folder in your Dropbox folder. Move the gpg.conf file that it created in ~/.gnupg to ~/Dropbox/gnupg/ and then make a symlink from the old location to the new. That way, you can share your config between your computers, and the program will be able to find it in the dropbox since there’s a symlink.
Add the following lines at the end of that gpg.conf:
`personal-digest-preferences SHA256
cert-digest-algo SHA256
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
primary-keyring ~/Dropbox/gnupg/pubring.gpg
trustdb-name ~/Dropbox/gnupg/trustdb.gpg`
The first three lines there tell it to prefer SHA-256 for the hashes that get signed, instead of the default (which I think is SHA-1?). You may want to put SHA512 instead of SHA256 if you’d prefer, but I think SHA-256 should be good enough, and definitely better than SHA-1. (I mean, Bitcoin uses SHA-256 for just about everything.) And the last two lines tell it to have your public keyring and your trust database in your Dropbox.
Now that you’ve specified your preferred hash, you can go ahead and create your key, either through the GUI or with gpg --gen-key. Make it an “RSA (sign only)” key. I went with a 2048 bit key, but I’m somewhat regretting not making it a 4096 instead. Hopefully, it doesn’t really matter in practice, but I wouldn’t recommend less than 2048. I don’t see any advantage in the main key expiring ever, so I didn’t put an expiration date on mine at least. Maybe there’s a reason out there, but nothing I saw on the Internet really convinced me that it did more than force you to update the expiration date later. But maybe if you think you’ll lose the key at some point, it could make some amount of sense.
I then added a photo to my key, to help really make it identify me. But I would understand if you wanted to skip that step. I’m not quite sure how it’ll work to try to update the photo if I grow old and my picture doesn’t identify me well or something, or if I’d need new signatures then. Photos seem to manifest themselves in the key similarly to a user-id, and it’s not something I’ve fully wrapped my head around yet.
Now you can generate an RSA (encrypt only) and RSA (sign only) subkey. I did it through the GUI, and for the subkeys I do think it makes sense to set an expiration date. In particular, one reason I’m using subkeys is so that I can and encrypt on my not-completely-under-my-control computer at work (which I’m fairly confident is trusted enough for what I want), but having the keys automatically expire seems like a good plan.
Now, the important step of backing up the keys now that we have them all in place. I ran “gpg -o 081287DC.gpg --export-secret-keys 081287DC” to get a file named after my key id (although you should run it with your key id instead), and saved it as an attachment in my KeePassX database. My KeePassX database is encrypted and stored on Mozy along with the rest of my digital life, so I’m pretty confident that I’ll always have access to my secret key now. (Also, the passphrase for my secret key was generated by KeePassX and stored there with it.) Once it’s safely stored, I ran “srm 081287DC.gpg” to securely delete the file, although that’s probably overkill since it is encrypted with the passphrase.
Next, I wanted to also store a version of my secret key that was just a subkeys and not the main key, for me to use on my work computer. This is pretty similar, but using “gpg -o 081287DC-subkeys.gpg --export-secret-subkeys 081287DC” instead to just get the subkeys. I also stored this file in my KeePassX database so that I could retrieve it on the work computer, and then srm‘d it as well.
Now, on the work computer you need to install GPGTools, and then delete the ~/.gnupg/gpg.conf file and replace it with the symlink to ~/Dropbox/gnupg/gpg.conf so that it will use your custom config. I created a new main key and encryption subkey for my work email address, but that’s really separate from what I’m trying to show with this writeup. I saved my 081287DC-subkeys.gpg file from my KeePassX database to a file, saved the public key to a file with “gpg -o 081287DC-public.gpg --export 081287DC“, deleted my public key from the database with the GUI (since for some reason it will only import a private key if the public key isn’t there already), and imported it with “gpg --import 081287DC-subkeys.gpg 081287DC-public.gpg“. If this all worked right, then “gpg -K” should show the main key as “sec#” meaning that it doesn’t have that secret key, but the subkeys show up without the # there. Then, of couse, srm the private subkeys file.
So, I think that I’ve got it all set up now, to be able to sign keys and manipulate my subkeys at home, sign and encrypt emails and documents at both home and work, and verify files at either place with the same public keyring (meaning that I only need to add new contacts at one place and I can use them at both). I could see people using this technique with something like a laptop too, where you trusted a computer enough to have signing and encryption-reading on it, but didn’t want to trust it with everything and wanted to be able to revoke the subkeys on it or have them expire.
The tricky part now of course is getting connected into the web of trust. I’d love to get my key signed by any of you that I know, and if there are any keysigning parties in the central Massachusetts area or if there’s somebody around who’s well-connected in the web of trust that would be willing to meet me somewhere to verify my identity, I’d appreciate it.
My fingerprint is 9CB1 D991 BFFC 7068 6C64 C89F 3475 92ED 0812 87DC.