I’ve been posting a lot about GPG and public key encryption lately, so I thought I should at least give some pointers for how to set it up on the Mac. This post is based off of directions written up by Daniel Morrison and Matt Slack, so kudos to them.
Getting up and running with GPG on the Mac is quick and very easy. Everything you need is available from the Mac GPG project on sourceforge:
- GNU Privacy Guard (currently version 1.4.1) installs the command-line tools.
- GPG Keychain Access is a simple GUI for managing and creating keys.
- GPGPreferences is a System Preferences panel for managing GPG from the GUI.
- Optional tools such as GPGFileTool (encrypt/decrypt files) and GPGDropThing (drop text to encrypt/decript) are available at the project page
After you have those installed, you need to generate a key pair. Open GPG Keychain Access and select “Key->Generate…”. Of all the options you are presented with, the only one you should need to think about is the key size. While 1024 is secure, 2048 or 4096 are obviously better. Larger sizes can slow you down if plan to encrypt large files, but are unnoticable for email. Note: the larger the key, the longer it will take to generate (one-time process only), so go grab a cup of coffee if you do 4096, unless you have a shiney new MacBook.
Install plugin for Mail Clients
Plugins for your mail clients will allow you to encrypt, decrypt, and sign messages in Mail. Since email is (probalby) the reason we want GPG, it makes a lot of sense to install them.
If you have commercial PGP installed it is best to uninstall before installing an email plugin. Apple Mail, for example, will not work with both. You can uninstall just the PGP email plugin by deleting it from your /Library/mail/bundles directory.
Use It!
What’s the point in having it if you aren’t going to use it? Upload your public key to one of the key servers. Get your friends and coworkers to generate public keys and start sending eachother secure mail (if you don’t have any friends or coworkers, feel free to download my public key and send me an encrypted email).
Daniel Morrison had an interesting post today about online sites using public key encryption (GPG, PGP, etc.) to reduce or eliminate phishing attempts and give mail recipients confidence in the validity of the messages. This is a great idea and something that I definitely think needs to be explored.
It reminds me of a post that I had on my old blog—which is no longer online and I can’t seem to find a backup of—so I thought I would try to re-articulate my thoughts.
Public key encryption could be used as a basis for an anti-spam and anti-phishing system. Mail services like Google, Yahoo, Hotmail, and others could transparently integrate public key encryption support. When you sign up for an account with these providers, they could generate a key and use it to automatically sign outgoing messages.
This solves the half of the problem—all outgoing email would be signed—but what about verifying incoming messages? How do people get my public key to verify my signature? The problem is that public key encryption is based on a distributed trust model. There intentionally isn’t an authority that says who can and can’t be trusted like there is in the SSL world. It’s based on the “I know and trust Joe, Joe knows and trusts Bob, therefore, I trust Bob” model.
At the very least, these mail services could allow you to add other people’s public key into your address book. This would be a solution for the security conscious, but in all reality, most users just wouldn’t do that. So how does my mail client get Joe’s public key to verify his signature without Joe sending it to me and me having to think about it?
Since public key encryption uses email addresses as the human identifier, why not make mail servers into key servers? Similar to the OpenID concept where your home website or blog becomes your identity provider, mail providers could run key servers that make the public key available for all of the email addresses that they serve. This could be combined with a model similar to Sender Policy Framework (SPF), where mail providers use special DNS records to specify where their key servers are for specific domains. Mail services could then transparently lookup public keys and verify incoming mail. This is a slight variation to the distributed trust model, but it is still distributed. I might not be able to trust everyone that I am getting email from, but I can at least verify that they are who they say they are.
While this method alone doesn’t eliminate spam, it would eliminate phishing. As an added benefit, everyone would have the ability to send encrypted email (I imagine the NSA wouldn’t support this solution). There’s nothing that prevents spammers from signing their messages, but if they did, it wouldn’t take long for them to be blacklisted.
Recently I had a client who wanted to store server backups on their hosting provider’s FTP server. The only problem is that those backups contained confidential customer data. So I came up with the idea of using a public GPG key to encrypt backups before copying them to the FTP server.
A little searching revealed that a lot of other people have also used this method. A great guide for getting set up to do this can be found here.
I already had a GPG key pair, so all I had to do was import my public key on the server, change the trust settings, and write a few bash scripts to dump the DB, create an encrypted tar archive, and FTP it.
Here are the commands I used to encrypt the database dump and tar archive:
# dump PostgreSQL data and encrypt it
pg_dump dbname | gpg -r C0E3268C -e -o /tmp/backup.sql.gpg
# tar the directories I want to backup and encrypt them
tar -c /var /etc | gpg -r C0E3268C -e -o /tmp/backup.tar.gpg
