GnuPG + mutt + OSX + GMail

published

A little over two years ago I generated a new GnuPG key. I had been using a 1024-bit key created in 2004, so I created a new 4096-bit key. I’ve used this new key only a handful of times since it’s creation.

In early 2014 I joined Keybase with high hopes of seeing an increase in GnuPG adoption. A few folks I know use the service, and we’ve cross-validated one another; but none of them have sent me any encrypted messages. Of course, Keybase’s larger utility is as much in “proving” my various online identities as it is in facilitating encryption.

At the 2015 Ohio LinuxFest, one of the birds-of-a-feather sessions was a keysigning party. There were about a dozen of us in attendance, some complete novices and some GnuPG experts. It was a great opportunity to meet a few new folks, as well as pick up a few GnuPG best practices.

All of this took place shortly after I declared my intention to learn mutt for my day-to-day email usage. Mutt has great support for GnuPG, and I was hopeful that this support would encourage me to use GnuPG as much as mutt.

I’ve learned rather a lot in the last couple of weeks, and this post is an effort to record and share some of that information for others. Aside from a few OSX specific bits, most of what follows should be generally applicable to Linux users as well.

All of what follows is my own opinion. You likely don’t know me, so you should not trust my opinion. Do your own research, and figure out what settings make sense for you! If you find any factual inaccuracies in my suggestions, please contact me and let me know!

The default options for GnuPG are okay, but not great. Depending on your level of paranoia, the defaults may be downright disastrous. One of the more interesting documents I found was Operational PGP, which was chock full of usefully paranoid suggestions. That, combined with OpenPGP Best Practices provided the bulk of my ~/.gnupg/gpg.conf settings.

In particular, ensure that you’re not using old and insecure algorithms:

Also ensure that you’re not leaking information unnecessarily:

When using GPG Suite on OSX, be sure to make use of the GPG agent:

The agent makes it much less hassle to use GnuPG. And it will come in particularly handy with mutt, too!

There was some interesting disagreement after the Ohio LinuxFest keysigning party with respect to proper next steps. Do you encrypt the signed key that you send? Do you individually sign each user ID on a public key? Do you push to keyservers? Each keysigning party may have different norms, so be sure to get answers to these questions before taking any actions! The Debian keysigning instructions may be useful as a reference for possible best practices.

GNU/Linux users are encouraged to use caff, which handles much of the tedium of signing and sending signatures to the folks at a keysigning party. Unfortunately, caff doesn’t work on OSX (despite being in homebrew). Additionally, caff sends mail directly from the host on which it is invoked, which may not work for laptops connected to residential ISPs. You may need to correctly configure a relay host in order to make the most of caff.

With GPGME, the relevant section of my .muttrc file is this:

I realize that looks like a lot, but compare it with the recommendations from the mutt wiki.

I don’t want to type in my GMail password every time I connect, and I don’t really want to leave a plaintext copy of my GMail password in my .muttrc. Since I’m using GPG and the GPG agent, I can encrypt my password and decrypt that on the fly when mutt starts!

For lots of other great suggestions about dealing with GMail, check out GPG / Mutt / Gmail by Ben Nagy. I particularly liked the recommendations for SSL hardening, and not blindly trusting SSL certs presented by IMAP and SMTP servers.

I still use the GMail web interface with depressing frequency, despite all the effort to configure and learn mutt. I’m trying hard to use mutt exclusively, but that’s quite an uphill battle.

One of the interesting things that all of the above work does not address is shared access to my Inbox from my laptop and my mobile phone. I will not install my GnuPG private key onto my mobile phone, so any encrypted emails I may receive will need to lie unread until I can access them on my laptop. Similarly, I won’t install my private key onto my VPS server, or a Raspberry Pi at home, or any other device I’m not likely to have in my immediate possession at most times.

UPDATE: I discuss private key security in a subsequent post.

So far this hasn’t been an issue, given the paucity of encrypted emails I receive. If encrypted emails were to become more commonplace for me, I might need to revisit my policy against my private key on my phone, since my phone is where I read the surprising majority of my emails these days.


home / about / archive / RSS