Privacy and Anonymity in Email

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:

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.