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.
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,
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
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
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
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.
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.
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.
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.
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
firstname.lastname@example.org. 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.
Given the short length of this article, I cannot address
cryptography issues. Some general introductions can be found at:
Andre Bacard's Anonymous Remailer FAQ is worth reading, especially for its caveats.
The Mixmaster project maintains a list of Frequently Asked Question about Mixmaster remailers.
The W3-Anonymous Remailer is a Web-based interface to the Mixmaster network.
GNU Privacy Guard is an excellent and popular implementation of RFC2440 (OpenPGP) symmetric encryption.
Other versions of PGP (free and commercial) are available.
David Mertz , being a sort of Foucauldian Berkeley, believes, esse est denunte.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.