Earlier this week, Felten made the observation that the government eavesdropping on Lavabit could be considered as an insider attack against Lavabit users. This leads to the obvious question: how might we design an email system that’s resistant to such an attack? The sad answer is that we’ve had this technology for decades but it never took off. Phil Zimmerman put out PGP in 1991. S/MIME-based PKI email encryption was widely supported by the late 1990’s. So why didn’t it become ubiquitous?
Usability. It’s a huge pain to set up and manage PGP encrypted email, even among a small group. See, for example, Whitten and Tygar’s paper on this exact topic. Closer to home for me, every member of the 2007 California Top to Bottom Review of electronic voting systems used OpenPGP for our internal communications. We even cheated and had a shared private key for our shared mail alias, rather than per-user private keys. While in the end it did work, particularly making it easy to clean things up when our work was finished — everybody just deleted their copy of the private key and we no longer had to worry about all the copies of the ciphertexts floating around — we had all sorts of weird hiccups along the way, and we’re talking about a group of security professionals. The S/MIME universe with hierarchical PKI seems to work reasonably well in closed, centrally administrated domains (i.e., internal email for a single company), but cross-domain secure communication again never really took off.
Features. I was an early beta user of Google’s Gmail and I was immediately hooked. Having instantaneous search over all my email was a powerful feature. Now, with a decade of my email all indexed and available, it’s invaluable. If I was using PGP or something like it, then I’d be giving up on all of Gmail’s search features. And then there’s Gmail’s truly effective spam filtering. Prior to Gmail, I spent a lot of effort training a local Bayesian filter, and it never came close to what Gmail does. In an encrypted world, the servers in the middle can’t help you as much with reducing spam. The more data they’ve got, the better they can protect you against spam, phishing, malware, etc. (These same benefits apply to many other webmail services; I’m not trying to argue for the superiority of Gmail relative to other webmail services.)
Speed. A big part of why Gmail is fast, even when you’re using a slow crappy connection, is that a lot of the data stays on the server. If somebody emails you a big attachment and you forward it on to somebody else, it’s never downloaded to your browser. It just gets passed along. Everything about webmail (or custom smartphone email apps) is built around speed. Conversely, with encrypted email, your client would need to download everything, assemble the new email, encrypt it, then push it back upstream. On a crappy connection, this would be unacceptably slow.
If you want to have communications where a man-in-the-middle attacker can’t read your messages, then you need to have local cryptographic secrets. There’s just no way around it. Even if you try to be clever, supporting features like search over encrypted data on the server, you’ll never approach the efficiency and features available when the server can see the plaintext of your email.
Is there an alternative? It might be possible to build a distributed social network that does the right thing. (Diaspora isn’t dead yet, but clearly isn’t ready for prime time. Daniel Sandler and I came up with something similar in 2008/2009 called FETHR. FETHR has very strong integrity but no privacy features. Frientegrity adds privacy.) One clever part of trying to build traditional public key cryptography into a social network is that the social network effectively implements a PGP-style web of trust. If Alice comments on one of Bob’s posts, and everything is digitally signed and hash-chained together, then you now have a path from Alice that implicitly endorses Bob’s public key. This effectively solves one of the hardest parts of the puzzle: scaling up the public key discovery and validation problem. Unfortunately, once you start properly encrypting messages, the server again can’t help you with spam and malware (although it’s easier to ignore people who you’re not “following”, which is a partial win). Neither the Diaspora, FETHR, nor Frientegrity designs make any attempt to unlink the sender from the recipient. Users could potentially follow one another through Tor, although that would put a lot of stress of Tor if the system got too big; it also wouldn’t help when you want to comment on a post with your real identity rather than anonymously. Potentially worse, every user in these systems is effectively divulging the volume of data they’re publishing; any post-facto observer of your published/encrypted timeline can see when you’re active and when you’re not.
Suffice to say, that at least for the foreseeable future, you won’t be abandoning your favorite webmail service, at least for the bulk of your emailing needs. If you anticipate needing to communicate securely, even in the face of compromised email servers, then you’re going to want to dive into the world of OpenPGP. If you want to defend against an observer reconstructing your social graph, off-the-shelf tools aren’t going to help you and you’ll need to cobble things together on your own.