Law in the Internet Society

Better Living Through Opportunistic Crypto

This paper addresses a question similar to that posed by DavidHambrickPaper1, but looks at it from a technical perspective rather than a speculative one. All sorts of governmental shenanigans are made possible by the use of clear text communication, and encryption technology (”crypto”) has been around (and mostly free of export control) for Internet ages. Why haven’t we put two and two together, and how can we learn?

When We Use Crypto, and when We Don't

The average consumer uses crypto mainly to protect shopping, banking, or password information. The availability of a secure method for transmitting credit card numbers (and non-liability guarantees from credit card issuers) were prerequisites to the current proliferation of electronic commerce.

Except in the case of online banking, rarely does the average netizen secure content. Login and credit card information might be secured, but the flow of web content is normally in clear text. For instance, Gmail users who haven’t set a preference will have their login and password protected while the content of their inboxes streams across the Internet in unprotected clear text.

And What if We Don’t?

Some content probably should not be encrypted -- transmitting common web content in the clear allows for efficiency gains through caching of commonly accessed files. Even this data is not “safe” to transmit in the clear, because much of even this seemingly innocuous data can be mined and misused, but I am more concerned about data unique to individual users, from the content of e-mails and instant messages to search results.

This paper focuses on third-party eavesdroppers, and ignores as intractable what happens to the data after it’s reached its destination (e.g. Gmail or Columbia’s mail servers). Protecting data stored on remote servers comes at the expense of convenience -- for instance, if one were to use a browser plugin that allowed seamless encryption and decryption of Gmail, the account would be useless from a computer without this plugin and would not be able to take advantage of Google’s indexing resources. Google, for its part, would be unable to insert context-sensitive advertisement and gain no advantages from allowing this use, save goodwill. As web services become more popular, the possibility of the government’s obtaining information from Google might eclipse that of the government (or others) obtaining information from a surveillance dragnet on the wires, making this paper less relevant. Providers like Google are more likely to set up encryption for communication between the web service and the user, which reduces the threat from third parties.

Increased levels of encrypted traffic, in addition to preventing third-party eavesdropping, help protect other unrelated users of encryption. When most (or even a substantial amount of) network traffic is encrypted, suspicion no longer automatically falls on encryption users. The only user sophisticated enough to use encryption in a small town in China gives herself away, but in large cities corporate VPNs make for less effective monitoring.

PGP Is Hard; Let’s Go Shopping

The increased computing cycles required to conduct encryption and decryption are becoming less relevant with increasingly powerful hardware. Indeed, some network card manufacturers have released network cards with coprocessors designed to take the offloaded work of encrypting network traffic from the main CPU. Certainly, though, even with today’s processors, encrypted traffic will require more effort than unencrypted traffic.

A pretty good system for encrypting files and text has been in the hands of the public for years, but it’s (at least perceived as) too complicated to catch on. Widespread public adoption of encryption requires a seamless implementation, and PGP isn’t it--the steps required to operate a “Web of Trust” (which PGP uses to avoid dependence on a centralized authority) scare off casual users.

When we do use crypto, we most often use it in the seamless system behind TLS/SSL (the technology used to secure web transactions). In this system, the browser ships with digital certificates for trusted “Certification Authorities,” which charge for and deliver digital certificates to web site operators. These digital certificates perform two related functions--they not only enable encryption but also authenticate the server to the user. The need for a (sometimes expensive) centrally-issued certificate (not strictly necessary, but preferred to avoid Big Scary Warnings) deters many small-time operators from setting up encryption, while not providing that much of an advantage in the authentication realm, even when not broken.

Low-Hanging Fruit

The most successful introduction of crypto is that which requires no user intervention. Without a centralized system, it is not possible to authenticate without user intervention, but “mere” encryption is a worthy piece of low-hanging fruit. Although an unauthenticated session permits some attacks, it still frustrates data mining. Inter-personal messages also often require considerable individualized effort to impersonate successfully, making the authentication function less important. Opportunistic encryption, or encryption that occurs whenever it is possible while maintaining unencrypted interoperability,

One particularly successful example is that of Off-the-Record (OTR) messaging, a method for encrypting instant messages. Although proxies and plugins are available for grafting OTR onto existing programs, a Free instant messaging program named Adium integrates OTR, defaulting to opportunistic encryption. Because Adium is a popular instant messaging client on the Mac OS, many instant messaging conversations between barely-savvy Mac users are encrypted end-to-end with no user intervention. Although OTR provides authentication as well as encryption, conversations will show as “unverified” but proceed with encryption even if the user does not understand the authentication step.

Another example is the opportunistic use of encryption between mail servers. Even though the mail servers do not authenticate each other, the data remain protected from any third-party eavesdroppers. Remarkably few servers do this (look for “TLS” in your e-mail headers, if you’re curious). Given the long availability of encryption technology and slow uptake, adoption of encryption for users who think they have "nothing to hide" seems to depend entirely on the willingness of users to lift their fingers (or of their providers to do the job).


Webs Webs

r2 - 03 Jan 2009 - 05:48:13 - DanielHarris
This site is powered by the TWiki collaboration platform.
All material on this collaboration platform is the property of the contributing authors.
All material marked as authored by Eben Moglen is available under the license terms CC-BY-SA version 4.
Syndicate this site RSSATOM