From: nobody@indirect.com
Date: Sat, 30 Oct 93 08:20:51 PDT
To: cypherpunks@toad.com
Subject: ANON: anonymous mail
Message-ID: <199310301519.AA08057@indirect.com>
MIME-Version: 1.0
Content-Type: text/plain


-----BEGIN PGP SIGNED MESSAGE-----

I thought I'd describe why you would want to pad anonymous mail.

Currently, the destination and contents of email you send isn't private.  It
is possible for any number of people to snoop your mail as it travels to its
destination.

For privacy, you can encrypt your mail.  Suppose Alice has an email account
as learns that email is about as private as a postcard.  She decides to
encrypt all of her email, and all of her correspondents agree to do the 
same.  So now, nobody can read her mail.

But, who she communicates with still yeilds information.  This is called 
traffic analysis, and I won't go into it here.  

So, enter anonymous remailers (see Chaum's "Untraceable Electronic Mail").
Currently several people on this list are experimenting with and running
anonymous remailers.  The remailers accept instructions (optionally 
encrypted) and resend messages, making it look as though the mail originates
from the remailer.

Now Alice sends and receives all her encrypted mail from an anonymous
remailer.  Somebody snooping Alice won't learn the contents of her mail,
or even with whom she communicates.  (She could even keep private what
USENET news she reads by borrowing a trick from Mr. Slippery in "True Names"
 - just download everything and read what you want at home.)

Another security enhancement is chaining the anonymous remailers, 
instructing one to mail to another, and so on, eventually delivering mail. 
Alice and her friends do the same, and they continue to privately 
communicate, keeping their various identities secret.  If the snooper just 
watches the first remailer, he will learn that her mail goes to another 
remailer, etc.  Now the snooper would need to watch more remailers to figure
out who Alice is talking to.

- From time to time, people suggest a probabalistic remailer, either 
forwarding mail to another remailer, or delivering it immediately.  This
actually reveals the final destination to more remailers than before.  For
example, if Alice chains mail A-B-C-final, then only the C remailer knows
the final destination.  But if the remailers implemented some probabalistic
scheme, then each one will have to be given the final destination.

To make it harder for a snooper, the remailers decide to cache their
remailing requests, sending them out periodically instead of immediately.
Now, a snooper would see a steady stream of mail into the remailer, and
nothing coming out until suddenly, the remailer sends out all of its queued
messages.  If a large number of messages are stored to be remailed later, 
the snooper isn't able to easily match up incoming and outgoing messages.

Now we come to message padding.  If a snooper watches the incoming and
outgoing mail, perhaps the size of the mail will provide enough information
to link sender to destination, even if it is cached and remailed along with
several other messages.  So, to defeat this, the remailer can pad all 
messages to be a certain length.

The best way for this to work is if a snooper can't figure out what is
padding and what isn't.  For plaintext and digitally signed (only)
documents, this is not too difficult.  But, for encrypted messages, if the
remailer could insert padding into the encrypted text itself, or add in 
padding which would be ignored upon decryption, then it would be very 
difficult, if not impossible, for a snooper to determine what is and what
isn't padding.

The system implemented at the elee9sf@menudo.uh.edu remailer is a simple
type - it pads the message body to a certain length.  But it is pretty
obvious what is padding and what isn't - so if a snooper is in a position
to determine the length of a message (say they are trying to match up
source and destination), they probably will be able to read the message
and throw the padding out on their own.

A better system would be one that pads inside encrypted text.  This can be 
done with a pgp encrypted message by padding the end of ascii encrypted text
and adjusting a few bytes (length fields, etc.).  The message can still be 
decrypted, and the excess padding bytes will be ignored.  Such a system is 
in the works... and it is reasonable to pad encrypted messages since it is 
much harder to detect and you will probably encrypt text sent through an 
anonymous remailer to get the maximum benefit.  (If you don't mind everyone
reading what you wrote you could use a dc-net and generate plaintext :-)

Another useful technique is an anonymous pool, where everybody in the pool
gets every message.  Since everybody subscribing to the list receives
every message, it would be extremely difficult for a snooper to determine
to whom such a message is really intended for.  You could use a newsgroup 
for the same purpose - post encrypted text to some group and your friend 
would read the group and retreive the message.  

Also, from time to time people wonder about errors and whether failed mail
can be bounced back or whatever.  The difficulty here is that the anonymous
remailers try to keep information about source and destination to a minimum.
For instance, a message may be routed through several remailers; the 
previous hop may be another remailer, so it wouldn't be useful to bounce the
message back.  Some remailers drop bounced mail, others wind up appending to
a log file.  A good solution currently implemented at extropia.wimsey.com is
to use an anonymous pool for error reporting.

Karl Barrus
<klbarrus@owlnet.rice.edu>

-----BEGIN PGP SIGNATURE-----
Version: 2.3a

iQCVAgUBLNH9eYOA7OpLWtYzAQEPzQP/QYeciQf7TKimj67xQRWScov848bcauF6
hlFOfoF4MFSm7mhD1bPks7xiwZuYO6P+MwkaeMqBKYQfWzBi37Blx5PNo3iK6Dmk
pmeGsYqew34oPxk7Exvsu7uOcKhFAhBcEWvElJ+ytMjEbuY8EsHoGGETXpPVK87C
OFkNxCrdqYY=
=J/5q
-----END PGP SIGNATURE-----