From: Jim Choate <ravage@ssz.com>
Date: Sun, 2 Jun 1996 00:39:01 +0800
To: cypherpunks@toad.com
Subject: Re: Remailer chain length?
Message-ID: <199606011336.IAA11002@einstein.ssz.com>
MIME-Version: 1.0
Content-Type: text



Hi Scott,

Forwarded message:

> Subject: Re: Remailer chain length? 
> Date: Fri, 31 May 1996 14:55:58 -0500
> From: Scott Brickner <sjb@universe.digex.net>
> 
> >If this is strictly true, why not simply run several instances of a remailer
> >on the same machine. Then randomly chain them prior to sending them off
> >site. This would be a lot cheaper and faster than trying to convince
> >hobbyist to set it up or businesses to to use their profit & legal council.
> 
> Because it's not strictly true.  Implicit in traffic analysis is looking
> at the "envelopes" of the traffic.  Since this means intercepting those
> envelopes, once you've put your monitor on the first remailer at a site,
> you've probably gotten all the rest at the site for free.
> 
> I don't think multiple remailers at the same site help anything.
> 

I agree completely. If traffic analysis is going to be done on a single box
it isn't going to matter how many remailers are there.  The monitor will
simply grab them all. At this point it simply maps them thusly:


      incoming message > remailer #1 > .... > remailer #n > outgoing


That this really maps to is obvious:


      incoming message > remailer #1-#n > outgoing


The only thing this does is increase the number of valid entries in the
From: field. Succesful traffic analysis does not require that the From:
field contain only a single item. As a matter of fact it makes no difference
what the headers contain unless the body is put in some kind of envelope for
final delivery. Why? Because all one has to do is look at the body of the
text which will not have changed. This leads to a simple model, based on a
physical remailer:

        1. Physical remailer receives an evelope addressed to them.
        2. They open it and find a $1 money order (for paying the remailer)
           and another envelope with another delivery address on it.
        3. Remailer puts $1 in bank and the interior letter in the mail.

To convert this to electronic means:

        1. Remailer receives a email that is encrypted except for the
           header.
        2. Remailer decrypts mail (ie removes the outer envelope) and
           find three items, block of encrypted data (ie inner envelope)
           with header to next site and e$ token for $1.
        3. Remailer sends the data on its way.

There are a couple of points to be made.

        1. No traffic is handled in the clear except for the header to
           the current destination all others are nested in encryption.
        2. Remailer chaining is handled entirely by the customer
           (ie customer addresses the envelopes)
        3. $1 is the smallest amount normaly accepted as a fee for a
           valid contract.
        4. Remailer can't look at data because there is no way to find the
           correct sequence of keys to unlock the nested encryption.
        5. Automaticaly limits spamming unless a remailer allows cloning
           AND all recipients share a commen private key.
        6. It maps 1:1 onto the physical remailer model with the same limits
           on information at each stage. This allows one to directly apply
           the current history of precedence involving anonymity and
           physical remailers.

Under todays current legal and social structure this is the only model that
will prevent remailers from being held accountable for their traffic and at
the same time provide enough income to keep legal protection at hand. Note
that I am not saying you still can't be brought brought up on charges,
simply that you (as a remailer) now have the structure in place to fight it
succesfuly.

This is the basic model that the Austin Cypherpunks are working on at the
currrent time. The big problem we have right now is determining if the body
is actualy encrypted. We have done some basic tests of encryption-spoofing
using pgp and it is looks to be a thorny problem. It simply is not trivial
to look at a block of characters and determine if they are actualy
encrypted. You can't rely on the wrapper around the data put there by the
encryption program because this can be kept intact and the data changed. As
long as the checksum matches it all looks the same. Even if the test is done
with a dictionary  this won't help because rsa does not guarantee that once
the data is encrypted that the output would be gibberish, sort of like the
"All the monkeys in the world typing create Shakespeare" story. It is
completely feasible (though unlikely) for the encrypted text to be something
meaningful in some language or another.


                                                      Jim Choate