ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Privacy and Anonymity in Email

by David Mertz
06/12/2003

As convenient as email is, it leaves much to be desired in terms of protecting the privacy of messages. There are two aspects to the limitation. On the one hand, email messages are very susceptible to interception and tampering by a variety of parties (ISPs, hackers, government, spammers, and others). On the other hand, email does not directly provide for anonymous communication (an important bastion of freedom of expression). Technical means can largely bridge both these gaps. This article provides a rundown of techniques for encryption, remailing, identity masking, and authentication of messages. Both existing tools and general programming techniques are addressed.

Type Zero Anonymity

In the beginning was anon.penet.fi. In 1993, Julf Helsingius created a server—a Mail Transport Agent (MTA)—that would allow users to register anonyms. A user, Alice@sender, could send a message to anon.penet.fi that had an extra field indicating the intended destination, Bob@recipient; the MTA would assign a random anonym to Alice, replacing occurrences of the address Alice@sender in the message header with nymA@anon.penet.fi. The massaged message would be sent on to Bob and a reply sent to Alice indicating her personal anonym. In the future, Alice could continue to use the same anonym by adding a field to the messages she sent through anon.penet.fi. If Bob wanted to respond to Alice (not knowing her real identity, of course), he could simply mail a message to nymA@anon.penet.fi. When Bob responded via anon.penet.fi, by the way, he was also assigned an anonym; but Alice already knows Bob's email address, so any direct response that mentioned Alice's message would let Alice determine Bob's identity.

While users in 1993 may not have fully appreciated the fact, there are two rather distinct privacy issues at play. One is sender anonymity, the other is recipient anonymity. Later systems divorce these two issues and do not necessarily address both.

As it turns out, Helsingius' MTA had both technical and legal vulnerabilities. At the time, many people contemplated the technical issues. To deal with interception of messages, you could send PGP encrypted messages using a server's public key. To complicate traffic analysis—an attacker correlating incoming and outgoing messages—random delays in forwarding can be introduced. If the incoming message were encrypted, the outgoing version, moreover, would not contain the same payload.

What killed anon.penet.fi had nothing to do with technical issues though. Instead, it was the less contemplated legal vulnerabilities that proved crucial. A variety of groups that were politically opposed to anonymous speech undertook the destruction of anon.penet.fi. Government agencies spread disinformation about illegal child pornography being distributed via the MTA, which the press lapped up. The linchpin turned out to be the Church of Scientology's (mis)use of copyright claims in an effort to find disaffected members. Faced with warrants—and thereby the potential compromise of the anonymity of all users—Helsingius decided in 1996 to shut down the service altogether.

Shredding the Records

The problem with anon.penet.fi, in retrospect, proved to be its single point of vulnerability: namely, the identity database. In practice, the weakness was legal, but it is easy to imagine a scenario where hackers somehow obtain access to the database. As soon as the database is compromised, so is the anonymity of every user.

Around the time of the closure of anon.penet.fi, or even a bit earlier, privacy advocates started thinking about ways to eliminate an identity database from the system of anonymity. The first solution implemented was Cypherpunk Remailers, also called "Type I" remailers (with the central-server model rebranded as "Type 0"). Notice the plural in the name. With a Type I protocol, a single message is forwarded between several systems before reaching its destination, with identity stripped at each link. Moreover, and perhaps even more importantly, Type I remailers never create a database of identities.

Under the Type I protocol, a user must construct an intended chain of remailers, encrypting a message in a separate layer for each remailer. Each remailer publishes a PGP public key that users may use for an encryption layer. When a Cypherpunk remailer receives a message, it strips off a layer using its own private key, finding the identity of the next remailer within the decrypted bundle. For example, for Ei a remailer, Ri is its public key, Ai its address, and B the destination address, a three link route looks like:

Alice --[E1(A2, E2(A3, E3(B, M)))]-->
	R1 --[E2(A3, E3(B, M)))]-->
	R2 --[E3(B, M)]-->
	R3 --[M]-->
Bob

Each remailer is able to decrypt the bundle it receives, but it cannot itself look more than one link ahead (the one it should forward to), let alone determine the final destination. Moreover, after the first link, the sender's identity has been removed: the first link only knows the sender, not because of anything in the bundle, but from who sent the bundle in the first place.

The Type I protocol, notice, is only really a way to protect the anonymity of senders. Some developers have tacked on "Nym Servers" that allow users to create anonymous identities. Despite some improvements in encrypting identity storage, however, there is still basically a point of attack on these Nym Servers. Nym Servers are also far from easy to work with.

Mixing it Up

Cypherpunks remailers were a good step toward improved security, but Type I remailers are still vulnerable to traffic analysis by an attacker, Eve, with sufficiently ubiquitous monitoring. If Eve can watch all the traffic on R1, R2, and R3 in the above example, she reliably determines that the same message underlies each link. If M is itself encrypted, perhaps Eve cannot read the message, but she can still establish the communication. Even if Eve cannot observe R2, she can use latency timing to plausibly correlate the message leaving R1 with the one arriving at R3. Moreover, if Eve can do a little more than merely observe, she can monitor such latencies with her own test packages sent through the same chain.

Mixmaster Type II remailers address many of the vulnerabilities of Type I remailers. Rather than simply forward each package to the next link as soon as it is received, a Mixmaster node will save messages for variable durations, bundling collections of messages together for transmission to a downstream node. Type II remailers are much more resistant to traffic analysis, unreliable nodes, and other attacks than are Type I remailers.

There are a few drawbacks to Mixmaster remailers, however. Mixmaster remailiers absolutely require custom software to use. While Cypherpunk remailers do require a fluency with PGP, and take more work than simply sending a message with a MUA, you do not need a dedicated application, per se. There are many Mixmaster clients available, but your favorite MUA is not one of them (at least, not without add-ons). The other disadvantage with Mixmaster is that there is simply no facility for anonymous recipients, only for anonymous senders.

Mixminion, which is still in very early stages of development, is the standard implementation of the Type III anonymous remailer protocol. That is to say, it is intended to supercede Mixmaster. It will provide features such as allowing responses to anonymous messages (single use, not persistent, however). Despite improvements over Type I, Type II remailers are still vulnerable to an attacker who can ubiquitously monitor traffic and mount sophisticated "flood" and "trickle" attacks. In time, sophisticated Type III remailers will be generally available, but testing and analysis is still needed.

Transparent Recipient Anonymity

I have implemented a system that, I believe, fills a gap in the current anonymity infrastructure. The Gnosis-Anon protocol has an experimental implementation (and more detailed FAQ).

The purpose of Gnosis-Anon is to allow very easy creation and use of persistent anonymous recipient identities. All you need to do to find an anonym is visit the Gnosis-Anon webpage (or use the XML-RPC interface), and find, for example that .rNCOolqsVQYu@gnosis.cx is an anonym for mertz@gnosis.cx. Obviously, this particular anonym has been compromised in advance. If you send mail to an anonym, Gnosis-Anon will act as an MTA, and forward the message to the anonymized recipient.

In some respects, Gnosis-Anon simply repeats one of the two elements of anon.penet.fi, but with a crucial difference. Gnosis-Anon maintains no database that maps anonyms to identities, but instead calculates the mappings algorithmically, using encryption keys. This technique provides resistance against a "passive subpoena attack". That is, if an attacker obtains access to the secret key material, the most she is able to establish is a subjunctive: if a message had been sent to an anonym, it would have been forwarded to a specific identify. Gnosis-Anon has neither the means to determine whether that forwarding ever actually occurred, nor whether any one ever did a lookup on the identity in question.

Moreover, Gnosis-Anon provides keys of varying durations, from one-day to permanent. You can configure other durations easily. Once a key has expired and been expunged, Gnosis-Anon has no way to establish even the subjunctive fact of a mapping. By implication, of course, after key expiration, Gnosis-Anon also cannot forward an anonym produced with an old key.

The scenarios that require an anonymous recipient are probably more limited than those that require an anonymous sender, so the application of Gnosis-Anon is limited. But the protocol is also perfectly compatible with prior use of an anonymous sender protocol, like Mixmaster, before a message arrives at an anonym. As well, in contrast to the difficult configuration procedure of Cypherpunk nyms, finding and using a Gnosis-Anon anonym is trivially easy, and the only tool you need to use is your favorite MUA.

Encryption Resources

David Mertz , being a sort of Foucauldian Berkeley, believes, esse est denunte.


Return to ONLamp.com.

Copyright © 2009 O'Reilly Media, Inc.