Private I: Encrypting email with public keys

In recent weeks, I’ve written about protecting data stored locally on a hard drive, against both people with physical access and potential remote attacks. But your data is much more vulnerable in transit, as it passes between end points or via servers.

This problem is effectively solved for instant messages with iMessage, which uses strong end-to-end encryption designed in such a way that—Apple says—not even they can decrypt your messages. This is accomplished by creating local encryption keys through a process that can’t be reverse-engineered on their side. Even though iMessages pass through intermediate points on the Internet, there’s no opportunity for others to grab the plain text, images, and audio within. (The same is true with FaceTime audio and video.)

But it’s still a mess for email, whether Mail in iOS or OS X, or third-party email software. The problem arises from email protocols working too well. Yes, I know how that sounds, as Apple’s Mail app frustrates on both its platforms. But the diversity of what you can choose among native and Web apps has to do with no company or organization controlling how email works. iMessage is entirely Apple’s ecosystem, which is the case for most messaging systems, including Facebook’s WhatsApp and the messaging component of Microsoft’s Skype. In contrast, there are thousands of native email programs across all platforms and all time, and hundreds remain in wide use.

The problem with email

The email protocols comprise POP3 (ancient and still in use) and IMAP for email retrieval and synchronization, while SMTP handles sending. Because they emerged from the dawn of Internet, they have evolved in fits and starts with weird vestigial pieces. Email continues to function because of compromises and a tacit agreement that nobody can break or refuse to support major components—partly because no one controls a big enough piece to force change.

One of the biggest problems past and present in Apple’s Mail.app is, in fact, because Google has an odd setup for its IMAP service, and Apple dances around fully embracing it. Google can’t break IMAP entirely, because then millions of users who pull in Gmail messages through Outlook or other software would be out in the cold, and potentially switch away. (Android has three separate email apps, in fact: two that work with Gmail in different ways, and third for “regular” email accounts.) Likewise, Apple can’t invent a new, superior way to send email because every mail server in the world would need to be updated to receive it.

In the last few years, enough standardization and upgrading have taken place that one aspect is well secured: the connection between an email client and an email server. Email flows from a client to a server run by your ISP or company or email host, and from there typically directly to the recipient’s corresponding email server. By default, Apple’s mail clients and those of other companies try to set up a new account to use SSL/TLS, the same session-based encryption technology used for secure Web interactions.

But SSL/TLS protects just the link between an email client and an email server. The data is encrypted in transit for that session, and then decrypted at the server, before being packaged and sent on to the next server. Now, in practice, even that’s becoming more secure. Most email servers—all of those run by major companies—are in data centers. And after the Edward Snowden disclosure, Google and other companies have stepped up the security of links among their own data centers.

The weak points still remain when email is decrypted, whether it’s for microseconds on a server before being wrapped up to send to another server over an encrypted link, or for much longer, when a server communicates insecurely—which is typical—with another email server. At those weak points, a criminal or government agent could gain access.

The key to security is…keys

iMessage suffers from none of these weaknesses because of its strong end-to-end encryption. So how can we achieve the same in email? Through the use of public-key (PK) cryptography, something that’s been available for encrypting documents and email messages since 1991 in one form or another. A decade ago, I reviewed an updated and well-designed commercial version of PGP (originally standing for Pretty Good Privacy) in Macworld, and hoped it would usher in a new age of encrypted email. I guess I’m a pretty optimistic fellow.

Still, hope springs eternal, and I think we’re ripe for another pass at PK becoming something that could be used readily and safely, rather than by those with command-line facility. Let me first explain public-key cryptography briefly. In the next column, I’ll explain how to use it practically—on a Mac at least.

Public-key cryptography relies on an algorithm that can create a set of numbers used to derive two complementary keys: one public, one private. The public key may be freely distributed, and, in fact, should be widely sent about and associated with one’s identity. (More on that in Part 2, as well.) The private key must be kept utterly secure, because its possession allows the party to “prove” that they are you! There’s no known or practical way to derive the private key if you have the public one at present, nor likely in the foreseeable future.

With someone else’s public key, you can encrypt a message that only he or she can decrypt with the corresponding private key. You can also take a message and “sign” it, producing a cryptographic summary that allows anyone with your public key to confirm that the message wasn’t tampered with and that only you could have signed it.

PK isn’t practical to encrypt long messages, and the genius of PGP’s inventor, Phil Zimmermann, was using the public-key portion only to encrypt a strong symmetrical session key—an encryption key unique to the document that both encrypts and decrypts the data—and that could only be extracted with the right private key. (When a message is sent to several people, the session key is encrypted with each party’s public key separately.)

The power of the PGP approach, which is instantiated as free software under the GPG (GNU Privacy Guard) name, is that it solves the problem of how to share a strong encryption key without it being compromised, because that session key could be used by any party to decrypt a message or encrypt new ones that can’t be verified on their own. The PK portion lets you share the document’s key safely.

But you can see the problem immediately, and the reason why PGP and its variants remains in low use a decade after my optimistic review. In order to use PGP, all your recipients need to have tools to manage finding and using public keys and to validate that they belong to the parties who claim them, and have access to email plug-ins that interact with your local private key and your storehouse of others’ public keys to manage encryption and decryption.

In Part 2, I’ll explain what’s changed and how to put this into practice.