If one-time presidential candidate Mitt Romney had been a cypherpunk, one can imagine him going on a different type of tone-deaf tirade on individual responsibility:

“47% of Internet users do not use any encryption at all, who are dependent on service providers, who believe these providers have a responsibility to protect their communications. … I’ll never convince them to take responsibility and care for their own privacy.”

There is a certain paradox in all the hand-wringing over Lavabit. After achieving its 15 minutes of fame as Edward Snowden’s email provider, the company shuttered its service very publicly due to unspecified government incursions, achieving notoriety and martyrdom along the way. They were soon followed by the start-up Silent Circle throwing in the towel for their private email service.

That poses one question: since when are users dependent on hosted cloud services to protect their own email? How did a movement predicated on Burning-Man-style radical self-reliance become so dependent on third-party service providers to protect email? It is as if two-decades worth of PGP and S/MIME development had been expunged from history, replaced by a brand new model of communication privacy based on the assumption that users are not capable of anything more complex than clicking web pages. It is worth revisiting that historic context around email encryption, if only to better contrast it with the fashionable web-driven services being hyped today.

End-to-end principle in action

PGP or Pretty Good Privacy started out in the 1990s, with the goal of making strong cryptography “universally” accessible to ordinary users. From the beginning the effort was plagued with regulatory and intellectual-property challenges, coinciding with the first round of cryptowars when technology industry battled the Clinton administration in an effort to relax restrictions around use of cryptography in commercial products. Unique to PGP is a decentralized peer-to-peer trust model. Sending encrypted email depends on knowing that person’s public key. But there is no centralized authority vouching for keys. Instead users vouch for each other, and establish confidence in other keys by navigating paths through already recognized keys. Trust traverses the social network– a remarkable concept, given that it was introduced a full decade before the rise of social networks, which allowed for the first time articulating those connections publicly, rendering them visible for all to see. What followed was community driven adoption, as PGP key-signing  parties started cropping up on the social agenda at IETF meetings and security conferences.

If PGP has been the grass-roots movement for email encryption, boldly fabricating new protocols and formats from scratch with nary a consideration for the patina of standardization, S/MIME is the buttoned-down corporate cousin following a conservative path of incremental change and conforming to existing organizational structures. Starting out a few years after PGP, it leveraged existing building blocks: X509 digital certificates for keys, PKCS for message formatting and MIME for email attachments. More importantly it called for a centralized, hierarchical  trust model where a single universally trusted entity– certificate authority in PKI parlance– mediates between large group of users who may not know each other personally. (Strictly speaking nothing prevents one from using self-signed certificates and manually managing trust with S/MIME. It just happens that most software implementations are not designed to play well with that approach, reflecting a design bias.)

However stark their philosophical differences may have been, PGP or S/MIME were united in one critical design principle: neither had much in the way of demands from infrastructure. Here was a great example of the vaunted end-to-end principle in action. All of the intelligence associated with encryption existed on the user’s own machine. Sure, email clients needed upgrades to recognize and process these new-fangled messages but the disruption ended there. Email servers remained the same– they could continue shuttling messages across the wire, oblivious to which ones were imbued with this magical security property. The network as we know it did not have to change. There was no separate “secure Internet,” “secure DNS” or “secure hosting provider” involved, existing alongside the vanilla Internet. Users did not have to change their ISP or obtain special “encryption-enabled” accounts from specialized providers marketing to niche audiences of the paranoid.

Cryptography goes mainstream?

Granted these early client applications left much to be desired in the way of usability. A seminal paper in usable security from 1999 by Alma Whitten and Doug Tygar was appropriately titled “Why Johnny Can’t Encrypt,” an unflinching look at the difficulties novice users faced in correctly operating PGP.

Fast forward to today. One might hope that the story has gotten better all around: export restrictions around cryptography lifted, interoperable standards codified in RFCs, ubiquitous support in software and polished user experience. Symantec acquired PGP, repackaging it as professionally supported enterprise-grade product. Meanwhile the GNU project implemented freeware clone GNU Privacy Guard. Before long it was ported to all major platforms, complete with user-friendly GUI installers on OS X and Windows. Mozilla ships the email client Thunderbird, providing easy integration with gpg clients. Meanwhile popular websites aimed at enthusiasts offer tutorials on setting up email encryption.

For skeptics who posit that the web-of-trust model for PGP with is hopelessly antiquated and can not scale beyond the rarefied community of high-minded technologists, there is comparable good news in S/MIME. Since 2000 it has been built into Microsoft Outlook and its free version Outlook Express shipping in every copy of Windows. Meanwhile rest of Windows client and server provide plenty of features to simplify roll out in enterprise setting: from issuing the certificates to automatically enrolling users for them, even integrating with smart cards for high-security use cases. All this using nothing but out-of-the-box Microsoft software installed on hundreds of millions of PCs. Surely all that enterprise experience will spill over into consumer use cases at home?

Johnny says: encryption is hard, let’s use web 2.0

A look at the “state-of-the-art” in private communication suggests otherwise. The head of the CIA attempts to use GMail draft messages to hide personal correspondence.  Misleading announcements from major companies confuse users into assuming that switching to HTTPS on the web interface is the ultimate fix for email security. Meanwhile only one leading large-scale email provider  attempts to encrypt SMTP traffic in transit, leaving bulk of traffic in the clear when crossing boundaries between different providers. Meanwhile good-intentioned journalists and clueless websites promote a host of flash-in-the-pan services with dubious architecture (and in the case of CryptoCat, impressive catalog of vulnerabilities earning a 2013 Pwnie nomination) dependent on centralized providers in the cloud.

This preference for relying on third-parties “out there” instead of managing cryptographic capabilities locally is not a new development either. Nor are the inevitable disappointments. In the early 2000s, Hushmail was considered the gold standard for safe email communication. The architecture was deemed immune to subversion by the provider itself. With all the key-management logic handled by a Java application delivered from the website each time users visited, no one seemed troubled by the possibility that website may go rogue, turn on its users and serve a backdoored Java applet instead. Until of course that event came to pass, compelled by law enforcement.

Giving up on Bring-Your-Own-Cryptography?

Lost in the public lamenting over forced Lavabit closure is the fundamental question: are these services necessary in the first place? What is preventing the ordinary GMail, Hotmail or Yahoo Mail user from employing strong encryption to communicate with like-minded users? The answer is not “Google does not support encryption.” The web interface built by Google is just one way of using GMail. Users are free to access the same service via rich client applications such as  Outlook or Thunderbird, perfectly capable of grokking S/MIME and PGP with proper configuration. It is an indication of shift in mindset. The original cypherpunk vision made modest demands on infrastructure, calling for bring-your-own-cryptography model. Users made local changes to their installed software and email routine to accommodate existing services. Their intellectual descendants expect the mountain to come to them, in the form of a convenient cloud service accessible from an iPhone, solving all those messy key-management problems, with only the monthly bill to worry about.

CP