[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3. Remailer Support

This is a long chapter describing an advanced feature; you may want to skip it on first reading.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1 Remailer Introduction

There are several anonymous remailer services running on the Internet. These are programs that accept mail, strip off information that would identify the origin of the message, and forward the mail to the designated recipient. This simple scheme alone, however, is insecure if the anonymous remailer becomes compromised (or if the remailer was set up by an untrustworthy party in the first place). Whoever controls the remailer will have access to the identities of senders and recipients.

One solution to this is to use chains of remailers that send encrypted messages. For example, suppose Bill wishes to send a message to Louis using a chain of remailers A, B, and C. He writes the message (possibly encrypting it for Louis), then encrypts the result (including the fact that Louis is the recipient) using a public key supplied by remailer C. Then he encrypts this result using a public key supplied by remailer B. Then he encrypts this result using a public key supplied by A and sends the message to A.

When A receives the message, it decrypts the message with its key to produce something encrypted for B, learns that the next remailer in the chain is B, strips off the information that the message came from Bill, and sends the message on to B. B then decrypts, learns that the next remailer in the chain is C, strips off the information that the message came from A, and sends the result to C. C then decrypts, learns that the destination is Louis, strips off the information that the message came from B, and sends the result to Louis. With this arrangement, only A knows that the original message came from Bill, and only C knows that the intended recipient is Louis. In general, the sender and recipient can both be known only to someone who has compromised all remailers in the chain.

If Bill wishes, he can include an encrypted "response block" in his message to Louis, which defines a remailer chain that Louis can use to reply to Bill. Louis can use this chain without knowing who Bill is – only the last remailer in the chain need know the final recipient. Bill can also establish a pseudonym for use in signing his anonymous messages.

More sophisticated systems split the message into multiple pieces to further disguise the path it takes through the network. Special client programs are used to construct and encrypt the pieces.

Mailcrypt includes facilities for sending messages via remailers, for defining chains of remailers, for generating response blocks, for using pseudonyms, and for interfacing with remailer client programs.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2 Types of Remailers

There are currently three classes of remailer networks in use, not counting the original single-hop address-rewriter machines (like the late penet.fi).

Cypherpunk (Type 1)

Machines in the original cypherpunk remailer network accept messages with commands to send a portion of the message out to another machine. By wrapping the final message text in layers of encryption like an onion, the message is sent through chains of remailers, each machine decrypting one layer and sending the rest out to the next hop.

One disadvantage of this scheme is that the message gets smaller by a fairly constant amount on each hop, making traffic analysis easier to perform.

Mailcrypt automates the process of wrapping your final message in layers of encryption for each remailer along the desired chain. Type 1 remailers are handled by mc-remailer-scheme-type1.

Mixmaster (Type 2)

The next generation of remailers use a special client program (written in C) to encode the message differently. The message is broken up into multiple identically-sized pieces, which follow separate paths through the network, and are recombined at the far end. At each hop, random padding is added to make sure that all inter-node messages are exactly the same size. This makes traffic analysis more difficult. Periodic dummy messages are also sent to further complicate attacks.

The most common type-2 client program for Unix is named “mixmaster”. There are two different versions, with fairly different interfaces. Mailcrypt supports both.

The older version comes from a package named “mix-2.0.3”, and has an interface that modifies a message in-place. The mailcrypt interface to this is through mc-remailer-scheme-type1 and behaves much like the normal encryption interface: you hit the button and your email is modified in place; the To: header is replaced with the target of the first remailer in the chain. As you can imagine, this API is problematic, as large messages must be split into multiple pieces.

The modern type-2 client program is an updated version of “mixmaster”, from a package named “mixmaster-2.9.0” (distributed at ‘http://mixmaster.sourceforge.net/’. This version does not modify the message in place; rather it accepts an email message on stdin and sends the resulting series of packets directly. The mailcrypt interface to the new mixmaster is through mc-remailer-scheme-mixmaster. When you chose “encrypt for remailer” within this scheme, the message is sent directly to the client program and delivered immediately, bypassing your MUA mode’s normal “send” command.

Mixminion (Type 3, under development)

A new generation of remailer networks is under currently development (at ‘http://www.mixminion.net/’). One notable improvement is the addition of automatic reply blocks. A major flaw of the type-2 network is that to give someone the ability to reply to a message, you have to give them a type-1 reply block. This makes the response more vulnerable to traffic analysis. Mixminion message can be formed in such a way that the response path is automatically embedded in the outgoing message.

Mixminion uses a client program (called “mixminion”) which behaves just like the modern “mixmaster” client. Through mc-remailer-scheme-mixminion, mailcrypt supports a command to send the body of the current message to the mixminion client.

Mixminion is under development, please check the web page for the current status before using it.

The remailer scheme currently in use is determined by the mc-default-remailer-scheme variable. Set this to one of mc-remailer-scheme-type1, mc-remailer-scheme-mixmaster, or mc-remailer-scheme-mixminion. For example, use the following in your ‘.emacs’ to make C-c / r always use the modern mixmaster client:

 
(setq mc-default-remailer-scheme 'mc-remailer-scheme-mixmaster)

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.3 Remailer Quick Start

To use Mailcrypt’s remailing facilities, you need to configure them first. Begin with the following steps:

  1. Download Levien-format list of remailers from ‘http://www.tahina.priv.at/~cm/stats/rlist.txt’ (as of 2007-03-01) and save the file to ‘~/.remailers’. See the variable mc-levien-file-name to chnage the file name anad location. Mailcrypt will parse this the first time you access a remailer function.
  2. Look over the ‘.remailers’ file and find the ones you want to use. The lines that list remailers and their capabilities look like ones below. It is best to consuts remailer statistics page to determine the most reliable candidats for chaining.
     
    $remailer{"frell"} = "..."
    $remailer{"starwars"} = "..."
    
  3. Add their PGP public keys to your keyring. You can for an armored keyring full of remailer public keys. Note that Mailcrypt requires that you have the public keys of all the remailers you want to use, and therefore that the remailers support PGP encryption.

    The list of remailers and their keys (as of 2007-03-01) can be found at ‘http://www.noreply.org/echolot/thesaurus/’. With gpg, after each key has been saved to a file, the entries can be imported into separate public keyring with command:

     
    gpg --no-options --no-default-keyring \
        --keyring ~/.gnupg/pubring-remailer.gpg \
        --import *.key
    

    In order for gpg to use separate keyring, the new keyring file must be configured to ‘~/.gnupg/gpg.conf’ by adding this line:

     
    keyring pubring-remailer.gpg
    

Note: Downloading the remailer list and their keys need only be done once, although repeating them from time to time is probably a good idea, since remailers come and go.

Now test the remailer functions. First compose an outgoing Email message (using C-x m, for example) addressed to yourself. Type C-c / r. Choose a remailer; use <TAB> to get completion on its name. The buffer will be rewritten for anonymous mailing through that remailer.

Note that you can only select a single remailer when you rewrite the message. To send the message through multiple hops, either rewrite the message multiple times, or define a chain of remailers that can be referred to like a single remailer. Remailer chains are described in the next section.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.4 Remailer Chains

mc-write-mode binds the function mc-remail to the key C-c / r. Depending upon the current remailer scheme, this function may pass the message directly to a remailer client, or may simply rewrite the message for a remailer or chain. For “type1” remailers, the resulting buffer is just a new Email message, so it can itself be rewritten for another remailer; this is one way to manually construct a remailer chain.

Mailcrypt also has powerful facilities for defining automatic chains. We will start with an example. Suppose you have put the following into your ‘.emacs’ file:

 
(setq mc-remailer-user-chains
      '(("Foo" "alumni" "robo")
        ("Bar" (shuffle-vector ["replay" "flame" "spook"]))
        ("Baz" "Foo" "Bar" "rahul" "Bar")
        ("Quux" 4)))

This code defines four chains. The first is named "Foo" and consists of "alumni" and "robo", in that order. The second is named "Bar" and consists of "replay", "flame", and "spook" in some random order (a different order will be chosen each time the chain is used). The third is named "Baz" and consists of 9 remailers: The two from "Foo", followed by a permutation of the three from "Bar", followed by "rahul", followed by another permutation of the three from "Bar". Finally, the fourth is named "Quux" and consists of a random permutation of the four best remailers as ordered in the ‘~/.remailers’ file.

Now whenever you are prompted for a "remailer or chain", the chains "Foo", "Bar", "Baz", and "Quux" will be available, including <TAB> completion on their names. By capitalizing their names, you guarantee they will show up near the top of the completion list if you type <TAB> on an empty input.

Now for the gritty details. mc-remailer-user-chains is a list of chain definitions. A chain definition is a list whose first element is the name (a string) and whose remaining elements form a remailer list. Each element of a remailer list is one of the following:

  1. A raw remailer structure. This is the base case, but you will probably never want nor need to deal with these directly.
  2. A string naming another remailer chain to be spliced in at this point.
  3. A positive integer N representing a chain to be spliced in at this point and consisting of a random permutation of the top N remailers as ordered in the ‘~/.remailers’ file.
  4. An arbitrary Emacs Lisp form, which should return another remailer list which will be spliced in at this point and recursively evaluated. Mmmm, Lisp.

So, in the example "Bar" above, shuffle-vector is actually a Lisp primitive which returns a random permutation of the argument vector. (Which brings up a side note: A remailer list can be a vector instead of a list if you like.)

So where do the definitions for "replay" etc. come from?

There is another variable, mc-remailer-internal-chains, which has the same format as mc-remailer-user-chains. In fact, the concatenation of the two is always used internally when resolving chains by name. The "internal chains" are normally generated automatically from a Levien-format remailer list, which lives in ‘~/.remailers’ by default and is parsed at startup time. The parser creates several chains, each containing a single remailer, and names each chain after the respective remailer.

Thus "replay" (for example) is actually the name of a chain whose single element is the remailer at <remailer@replay.com>. So "replay" is a valid name of a chain to include in the definition of another chain, as was done above in the definition of "Bar".


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.5 Response Blocks

Mailcrypt can generate a response block for you. Just type C-c / b in an outgoing mail buffer. That will prompt you for a chain to use, and will insert the response block at point. Note that you can use any chain you want for your response block; it need not be related to the chain you (later) use to remail the message.

If instead you type C-u C-c / b, you will be dropped into a recursive edit of the innermost part of the response block. This text is what you will see at the top of the message when the response block is used. This text is the only way to identify the response block, since it will be used to mail you through anonymous remailers.

You probably won’t need to use the C-u feature, since by default the response block contains the date, ‘To’ field, and ‘From’ field of the message you are composing. However, if you want your response block to point to a USENET newsgroup instead of your Email address, you may edit the innermost part of the response block to have a ‘Newsgroups’ line instead of a ‘To’ line.

Inserting a response block also updates the ‘Reply-to’ hashmark header field. So, when your recipient replies to your message, the reply will automatically be addressed properly. This only works if the last remailer in the chain used to encrypt the message supports hashmarks (the response block chain doesn’t matter). If the last remailer does not support hashmarks, Mailcrypt will generate an error when you try to use the chain.

Note that you should insert your response block before you encrypt the message for remailing. Also, see Remailer Security.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.6 Pseudonyms

Mailcrypt supports pseudonyms. Type C-c / p in an outgoing message buffer and you will be prompted for a pseudonym to use. Your pseudonym will show up in the ‘From’ line that the recipient sees. Your pseudonym may either be a complete ‘From’ line (including an Email address), or just a full name (with no Email address). In the latter case, the Email address will automatically be set to <x@x.x>, an invalid address designed to prevent sendmail from going rewrite-happy.

If you have one or more pseudonyms which you normally use, and you aren’t afraid of revealing them if your account is compromised, you can set up a default list of pseudonyms with lines like the following in your ‘.emacs’ file:

 
(setq mc-remailer-pseudonyms
      '("Elvis Presley" "Vanna White" "Charles Manson"))

Then those names will be available for completion when you are prompted for your pseudonym.

You should insert your pseudonym before you insert a response block, so that the response block will contain the ‘From’ line as well as the ‘To’ line. That way you can tell who you were pretending to be when you get a reply to your message.

Note: Many remailers do not support pseudonyms. In addition, the Levien format does not (yet) indicate which do and which do not, so Mailcrypt can’t warn you when your pseudonym isn’t going to work. The only way to be sure is to send yourself a test message, and to try different remailers until you find one or more which work. On the bright side, only the last remailer in the chain needs to provide such support; none of the others matter.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.7 Remailing Posts

Mailcrypt knows how to rewrite USENET posts for anonymous or pseudonymous remailing. Just compose your post or followup normally, and use C-c / r to rewrite it for a remailer chain. You don’t even need to start your newsreader to make a post; you can just compose a message in mail mode and replace the ‘To’ line with a ‘Newsgroups’ line before doing C-c / r.

Mailcrypt will generate an error if the last remailer in the chain does not have both the post and hash (hashmarks) properties. The hashmarks are used to preserve ‘References’ and similar headers, so your anonymous or pseudonymous followups will thread properly. The variable mc-remailer-preserved-headers controls which headers are preserved when rewriting a message, but you should not need to change it since the default value is reasonable.

Before rewriting, you can use C-c / p to insert your pseudonym, and C-c / b to insert your response block, just like when composing mail. In this case, the response block will include the ‘From’ line and the ‘Newsgroups’ line (which is the news analogue to the ‘To’ line).


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.8 Mixmaster Support

(note: this chapter describes mailcrypt’s support for the “old” mixmaster interface. For a description of mailcrypt’s support for the modern mixmaster client see Mixmaster and Mixminion.)

Mixmaster is a newer type of remailer which provides excellent security against traffic analysis and replay attacks. (For more information on these attacks and Mixmaster, see Lance Cottrell’s FAQ at ‘http://mixmaster.sourceforge.net/faq.shtml’.

If you do not use Mixmaster, you may skip this section entirely; Mailcrypt’s default configuration treats Mixmaster as if it did not exist.

If you have the Mixmaster executable installed, you can tell Mailcrypt to use it by placing lines like the following into your ‘.emacs’ file:

 
(setq mc-mixmaster-path "mixmaster")
(setq mc-mixmaster-list-path "/foo/bar/baz/type2.list")

mc-mixmaster-path is a string representing the Mixmaster executable. mc-mixmaster-list-path is the complete path to the type2.list file.

Once these variables are defined, (and if the remailer scheme is set mc-remailer-scheme-type1, see Types of Remailers), Mailcrypt will automatically try to use the Mixmaster executable whenever possible. Specifically, when you rewrite a message for a chain, Mailcrypt will find maximal length sub-chains which have the mix property and will use the Mixmaster executable to rewrite for those sub-chains.

This allows arbitrary intermingling of Mixmaster and normal (also called Type 1) remailers, but you should note that this is not recommended. The recommended procedure is to have a single Mixmaster sub-chain which is most or all of the whole chain.

There are advantages and disadvantages to having the Mixmaster sub-chain at the end of the whole chain. The primary advantage is that Mixmaster remailers support multiple recipients. The primary disadvantages are that they do not support pseudonyms nor posting.

So here, as always, it is the last element of the chain which needs to support the special features you want. In general, the remaining elements do not matter, and the superior security of Mixmaster remailers is a good argument for using them for the bulk of your chains.

Mixmaster remailers also have a "Type 1 compatibility mode" which you might want to invoke to use a pseudonym or make a post. You can do this with the function mc-demix. Here is an example of its use:

 
(setq mc-remailer-user-chains
      '(("Foo" "vishnu" "spook")
        ("Bar" "Foo" (mc-demix "replay"))))

This makes "Bar" a chain of three remailers, and guarantees that the last one ("replay") will be used in compatibility mode.

Note that Mixmaster remailers cannot be used for response blocks. Mailcrypt will ignore the mix property when generating a response block.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.9 Mixmaster and Mixminion

Mailcrypt now contains preliminary support for the modern mixmaster client, as well as the experimental mixminion client. This support is accessed through the mc-remailer-scheme-mixmaster and mc-remailer-scheme-mixminion scheme settings.

Both of these clients operate in a mode where the completely absorb the message body. When run, they accept the text on stdin, decide upon a remailer chain, construct the message packets, then transmit the packets directly. Unlike the type1 (and older mixmaster) interface, once these client programs finish, the message has been sent and the user’s MUA buffer is no longer needed. Note, in particular, that this bypasses the MUA’s “send” command.

To make sure that the user does not accidentally use the MUA mode to send the message (non-anonymously), Mailcrypt will attempt to erase the message buffer and To: header. Some MUA modes may also have support code which will delete the message buffer altogether.

Mailcrypt will also ask “Do you really want to send this message” before running the client program. This is your last chance to avoid sending the message.

The modern client programs are designed to convey message bodies, not the headers-plus-body that usually make up an email message. Email headers, even with the obvious ones like From: and Message-Id: stripped out, are too likely to leak information, making it possible for the message recipient to figure out who sent the message. Any extra information about the kind of system used to construct the message serves to reduce the “anonymity set”, the set of possible message senders. A smaller anonymity set means less anonymity.

The client programs have command-line arguments to add certain headers (like Subject:) back into the message. Different clients (and different versions of the same client) offer different options. Where possible, Mailcrypt will take the headers from your message and pass them to the remailer client program. Note that most clients only allow a single recipient to be named.

Mailcrypt support for modern remailer clients is still preliminary. It does not yet provide control over several options offered by the clients. Features not useable include:

Mixmaster

Newsgroup-posting

Nym support

Automatic sign/encrypt

reply-chain generation

file attachments

Mixminion

reply block generation

In addition, both clients offer ways to influence the chain of remailers to use for the message. Mailcrypt does not currently offer a way to access this control: messages will be sent using the default client settings (which usually means a chain of four reliable hops).


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.10 Remailer Security

Keep in mind that there is only one person fully qualified to protect your privacy: you. You are responsible for obtaining a list of remailers and their public keys; you are responsible for choosing which of them to use and in what order. There are public lists of remailers and keys (the Quick Start section above relies on them), but you pay for the convenience by putting your trust in a single source. This is one reason Mailcrypt does not access these public lists automatically; you need to get into the habit of watching what goes on behind the scenes. You should also try to learn something about the remailers themselves, since you are relying on them to help protect your privacy.

How many remailers should you include in your chain, and how should you choose them? That depends on whom you perceive as a threat. If the threat is your ex-spouse or your boss, even a single remailer is probably adequate (more won’t hurt, but will cost in latency). If the threat is the Church of Scientology, you probably want to use a fair number of remailers across multiple continents. If the threat is a major world government, well, best of luck to you.

Also, there is a huge difference between chains suitable for regular messages and chains suitable for response blocks. Some remailers don’t even keep mail logs (at least, their operators claim they do not), so it may be literally impossible to trace a message back to you after the fact if you chain it through enough remailers. Response blocks, on the other hand, have your identity buried in there somewhere. In principle, at least, it is possible to compromise the keys of all the remailers in the chain and decrypt the response block. So you should either use very long and strong chains for your response blocks, avoid using response blocks at all, or only use response blocks which themselves ultimately point to a newsgroup.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.11 Verifiable Pseudonyms

Here is a plausible sequence of operations when using the remailer support in Mailcrypt:

  1. You create a public/private PGP key pair. You give it a User ID which is your pseudonym. You upload the public key to the key servers or otherwise distribute it. (Be aware that anyone who compromises your account can read the IDs on your secret keyring, thus discovering your verifiable pseudonyms.)
  2. You compose an Email message, Email reply, news post, or news followup.
  3. You insert your pseudonym with C-c / p.
  4. (Optional) You insert your response block with C-c / b.
  5. You type C-c / s to sign the message. The mc-sign function understands pseudonyms.
  6. You type C-c / r to rewrite the message for remailing. (Or use C-u C-c / r to view each step of the rewriting as it happens.)
  7. You type C-c C-c to send the message.

Now the recipient(s), reading your message through mail or news, can verify your pseudonymous signature; thus you have started to create a verifiable pseudonymous identity. If you use it consistently, it will develop a reputation of its own. With Mailcrypt, using a pseudonym is almost as easy as using your real name (and your followups in news will even thread properly). Welcome to the new age of letters…


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12 Remailer Tips

This is a collection of tips for using Mailcrypt’s remailer support.


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Build Daemon user on May 28, 2014 using texi2html 1.82.