REMAIL: X-Discard header line added

In an effort to make creating more traffic for the Cypherpunks
remailers easier, I have added a feature to my remailer.  Whenever it
receives a message that would otherwise be remailed but contains a
header line saying "X-Discard:" it will discard the message and act as
though it got remailed.  If all of the Cypherpunks remailers supported
an automatic discard feature, we could setup cron jobs or whatever kind
of software we want to send "junk mail" to the remailers that does not
get forwarded on.

     An idea I just had was to make the X-Discard have a counter.  If
the number is greater than zero, decrement it and forward the message
to another known remailer.  If it is less than one or non-numeric,
discard the message.  Right now, it just discards whatever message
has that header.

Example Message:
====================================
From: nobody@no.com
To: nowhere@bsu-cs.bsu.edu
Subject: Test

::
Request-Remailing-To: bob&tom@bit.bucket.net
X-Discard: Please!

Test Message
====================================

Chael

--
Chael Hall
nowhere@bsu-cs.bsu.edu, 00CCHALL@BSUVC.BSU.EDU, chall@bsu.edu
(317) 776-4000 from 8 am - 5 pm CST

On Tue, 15 Jun 1993, Chael Hall wrote:

>      An idea I just had was to make the X-Discard have a counter.  If
> the number is greater than zero, decrement it and forward the message
> to another known remailer.  If it is less than one or non-numeric,
> discard the message.  Right now, it just discards whatever message
> has that header.

Seems like a very good idea, at least for the short term, to generate
traffic.  Just make sure that you do not accept a value for X-Discard that
is too large, or else you'll find the same message floating around
(Internet Worm sytle) when you *don't* need any extra traffic!  If you
wanted to really have fun, you could also add X-Discarded-By to keep a
list of all sites the message has visitied, and make sure the same message
doesn't cycle through the same site too many times.

--
Nick MacDonald               | NMD on IRC
i6t4@jupiter.sun.csd.unb.ca  | PGP 2.1 Public key available via finger
i6t4@unb.ca                  | (506) 457-1931    ^{1024/746EBB 1993/02/23}

In message <Pine.3.05.9306151329.A26368-b100000@jupiter>, Nickey MacDonald writes:
> 
> Seems like a very good idea, at least for the short term, to generate
> traffic.  Just make sure that you do not accept a value for X-Discard that
	I don't understand what the point is in adding unnecessary, junk
traffic to the remailers. Please explain.

	Peace,
--
| Sameer Parekh-zane@genesis.MCS.COM-PFA related mail to pfa@genesis.MCS.COM |
| Apprentice Philosopher, Writer, Physicist, Healer, Programmer, Lover, more |
| "Symbiosis is Good" - Me_"Specialization is for Insects" - R. A. Heinlein_/
 \_______________________/ \______________________________________________/

> 
>      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

>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.  

The cypherpunks remailers use a little invention called 'header
pasting' where header fields may be added into the header after
receipt but before processing.  These pasted header fields may in
addition be put inside encryption wrappers, thus hiding them from the
outside world.  'Discard' headers may use this technique.  

Eric

>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.  

     Eric has already addressed this; I intend to make my remailer PGP
capable soon.  If not the one on bsu-cs, the new one will have PGP as
soon as I can get to it.

>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.

     I'm not sure what you mean about bouncing it around to different
remailers, because if there are a lot of remailers, it could take a long
time before it finally gets to the appropriate one that can decrypt the
destination information (perhaps longer than the TTL and therefore it does
not get delivered).  With encryption, the remailers don't have to know the
recipient until the last phase anyway.  In addition, they may not know the
contents of the message either.

>This would also not waste bandwidth moving useless messages around.

     Right now, we have plenty of bandwidth because the remailers don't
get much use.

     ALL:  Which is better:  X-Discard or X-TTL?  I can easily change it
to X-TTL.

Chael

--
Chael Hall
nowhere@bsu-cs.bsu.edu, 00CCHALL@BSUVC.BSU.EDU, chall@bsu.edu
(317) 776-4000 from 8 am - 5 pm CST

[...]
> >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.
> 
>      I'm not sure what you mean about bouncing it around to different
> remailers, because if there are a lot of remailers, it could take a long
> time before it finally gets to the appropriate one that can decrypt the
> destination information (perhaps longer than the TTL and therefore it does
> not get delivered).  With encryption, the remailers don't have to know the
> recipient until the last phase anyway.  In addition, they may not know the
> contents of the message either.

I set the "breakout counter" at 10 and throw it into any port on the
remailer web.  It bounces around 10 times and then the "deliver this damn
message" flag gets tripped and the TTL counter starts.  The TTL counter is
actually the number of hops from this point on that the message will
traverse looking for someone who can decode the encrypted destination
address before the message dies or is otherwise checked for problems.  It
could take a long time to deliver the message, but time latency is another
possible means of confounding traffic analysis.  What I was basically
thinking was that the breakout counter tells the message how many times to
randomly bounce around the internal structure of the remailer web (and
hopefully becoming lost in the clutter) before it tries to find someone who
can deliver it; the TTL would be used once the breakout counter had hit
zero and would try to keep a message from bouncing around forever if there
is an addressing problem.  

This would obviously increase the complexity of the system and require a
collection of remailers scattered across the net, but it seems to me to
have the advantages of providing more security as the number of remailers
grows and to allow bepopel to set up thier own forwarding and addressing
that is independant of the remailer system (you generate your own
destination certificates and can string together whatever you want in the
destination, even another hop back into the remailer system.)  It may be
overly complex, but it just seemed to me that it might offer the possiblity
of truly untracable mail: two messages sent into the same entry port with
the same destination certificates at the same time could end up coming out
of two different exit ports on the black box depending on how they bounced
around inside the system.

If you want someone to be able to send you a reply to an anonymous message
you give them a destination certificate that contains the destination you
want the message sent to wrapped in various remailer pubkeys (one or more,
it is up to you).  They do not need to know where the message is going,
they just attach the certificate to thier message and drop it into _any_
remailer and know that it will either get to the destination or get bounced
back to them.  A distributed anonymous remailer system of sorts...  

jim