From: Jim McCoy <mccoy@ccwf.cc.utexas.edu>
Date: Tue, 15 Jun 93 09:42:56 PDT
To: cypherpunks@toad.com
Subject: Re: REMAIL: X-Discard header line added
In-Reply-To: <9306151537.AA07449@bsu-cs.bsu.edu>
Message-ID: <199306151642.AA07985@tramp.cc.utexas.edu>
MIME-Version: 1.0
Content-Type: text


> 
>      In an effort to make creating more traffic for the Cypherpunks
> remailers easier, I have added a feature to my remailer.

Do you mean easier to create more flow to thwart analysis or easier for an
observer to determine which messages it does not need to examine after
reaching a certain line in the header.  This seems like a nice effort, but
will not deter traffic analysis in the slightest.  Headers are always
unencrypted, so anyone watching the flow will be able to write a 3 line
perl script to filter out all of these messages and there is nothing a
header line can do to hide this discard information.  

What might be more usefull is a counter that signals the remailer system to
stop passing a message and unwrap part of the message and act upon the
instructions there; thus the counter would let tell the system how long to
bounce the message around internally and when the counter hits zero it
could send the message on to the target.  For example you could create a
little MIME x-anon-remailer body part that contains lines with the the
final destination wrapped in the remailer pubkeys.  When the counter hits
zero the remailer checks the x-anon-remailer body part of the line that
matches its pubkey, decrypts that line to get the final address and then
sends the message on.  In this sort of system all you would really need to
do is send someone a message with your destination address wrapped in one
anon remailer pubkey.  When Alice replies to Bobs message she includes the
x-anon-remailer body part which has the line provided by Bob (or several it
Bob provides more than one).  Alice sends this message to any remailer
entry point and the message gets bounced around the system until the
counter hits 0.  At this point the remailer checks to see if it can decrypt
any of the destination lines, if not it ups the counter by one (and maybe
sets a TTL counter so that messages that have destination keys corrupted do
not float forever...) and tosses it back into the system, if it can decrypt
one of the destination keys it sends the message off to the address Bob has
provided inside the destination key (Bob could even have the destination
key send it the message into another remailer system if he is sufficiently
paranoid).  This would make traffic analysis much harder because once the
message enters the remailer system it bounces around so much; the remailers
become a black box that deliver the message without really knowing anythign
about it until the last phase of delivery.

This would also not waste bandwidth moving useless messages around.


jim