1997-09-26 - Re: Remailer Attack

Header Data

From: “Robert A. Costner” <pooh@efga.org>
To: cypherpunks@cyberpass.net
Message Hash: 2dd59fb42adad1e378becbdc68589a9e925d698ff7f62be27b2c8b5bd0b49be7
Message ID: <3.0.3.32.19970925200257.030c1640@mail.atl.bellsouth.net>
Reply To: <199709252158.XAA21054@basement.replay.com>
UTC Datetime: 1997-09-26 00:13:03 UTC
Raw Date: Fri, 26 Sep 1997 08:13:03 +0800

Raw message

From: "Robert A. Costner" <pooh@efga.org>
Date: Fri, 26 Sep 1997 08:13:03 +0800
To: cypherpunks@cyberpass.net
Subject: Re: Remailer Attack
In-Reply-To: <199709252158.XAA21054@basement.replay.com>
Message-ID: <3.0.3.32.19970925200257.030c1640@mail.atl.bellsouth.net>
MIME-Version: 1.0
Content-Type: text/plain



At 11:58 PM 9/25/97 +0200, Anonymous (Monty Cantsin) wrote:
>The remailers should all have about the same latency.  0 seconds seems
>like a good Schelling point.  What would it take to reduce remailer
>latency to under 60 seconds for most of the remailers?

By latency, I assume you mean the lag time from when the message is sent,
till when it is received.  There are several possible reasons as to why a
remailer message is subject to a longer lag time than you like.

Remailer software is often a work in progress.  Changes are made on a
regular basis.  A recent change to correct one problem recently had the
effect of spinning off multiple copies of some of the remailer sub
programs.  As more and more copies went into memory, the machine got slower
and slower.  Programming changes are not an uncommon thing.

But remailers are subject to the same forces as other things on the
internet.  Email is particularly well suited for asynchronous
communications, so email is often left to drag behind while other processes
continue.  I've seen email I send to lists take hours to appear back to me.
 In addition to this natural internet force, remailers can be throttled to
go slow.  There are a number of options that can be selected by the
administrator to keep the remailer running slowly.  One of the more
externally obvious is the reordering pool.  A reordering remailer is
designed to fool traffic analysis by sending messages out in a different
order from what they come in.  By design a message must wait to be
delivered.  A user option in remailers will allow the sender to specify an
additional wait time to add to the system generated latency.

What would it take to get latency to under 60 seconds?  More remailer
traffic would help.  If instead of 100 messages per hour a remailer was to
receive 1,000 messages per hour there would be less need to throttle the
system and introduce lags to foil system traffic.  The reordering pool
would be flushed much more quickly.  You asked about hardware, there are
places where faster, or more hardware might help.

The truth is not everyone wants to reduce latency.


  -- Robert Costner                  Phone: (770) 512-8746
     Electronic Frontiers Georgia    mailto:pooh@efga.org  
     http://www.efga.org/            run PGP 5.0 for my public key






Thread