From: Jim choate <ravage@bga.com>
Date: Sat, 11 Jun 94 15:54:02 PDT
To: fnerd@smds.com (FutureNerd Steve Witham)
Subject: Re: Remailer REORDER not DELAY
In-Reply-To: <9406110028.AA05143@smds.com>
Message-ID: <199406112253.RAA05183@zoom.bga.com>
MIME-Version: 1.0
Content-Type: text


> 
> Jim choate <ravage@bga.com> writes:
> 
> > 2. messages will be cached and re-transmitted after a random delay. I intend
> >    to generate a random number between 0 and 24. When the appropriate hour
> >    arrives all messages with that time stamp will be sent encrypted.
> >    I would suggest getting a random number between 0 and 1440. This will
> 
> I waited for a good reply to this and didn't see one.  Smart people have 
> commented on this before and no one in this round seems to be remembering.
> 
> Delay--time--isn't what matters.  It's confusion about which message is
> which that matters.  So if I get 10 messages in one minute, I can scramble
> the order and send them out the next minute, and I've done my job--at
> least the order-scrambling part.  (You also need to pad or packetize
> messages.)
> 
> So use serial numbers, not times!  Send a message for every one you get, 
> keep a fixed number of messages queued, and add dummies if necessary
> to keep things moving.
>
Wrongo...the random time stamp does randomly re-order then. As to bogus
messages, not on my system you won't....

I have a system which runs of a SLIP feed and bandwidth is sacrosanct.
If you would like to pay for an additional line to handle the added 
load then fine but my pocket book won't support it. And when one makes
the consideration of the future where there will be many small systems
with minimal bandwidth and monetary resources then I realy doubt they 
will be interested in any system which slows down or otherwise wastes
a precious and critical resource.

I also oppose the implied synchronicity of your methods as well. I am 
looking at a resonably secure asynchronouse method of making the 
traffic analysis difficult (the real reason for all this mumbo jumbo
in the first place). Why should I provide a potential monitor with the
information that a certain amount of information going out will be 
bogus? This also relates to my comments concerning the use of the other
'feed' systems around me.

> > On the issue of traffic analysis:
> >
> > It occurs to me that simply monitoring a remailers feeds and their traffic
> > analysis will provide enough information to determine the difference between
> > bogus (ie random generated) and real traffic...
> 
> Why not have the dummy message forwarded in a long enough chain and back to 
> you?  Then you could swallow it or turn it into another dummy, depending on
> whether you need to hurry your queue right now.
> 
> I don't think the amount of dummy traffic is a big problem.  You only need
> enough to keep your queue flowing.  Plus, if the remailers only generate
> dummies when necessary, the total dummy traffic is self-regulating, since
> multi-hop dummies are x-lax for every remailer they pass through.
> 
> I like thinking about the traffic pattern with get-one-send-one remailers:
> A user sends a message, and it seems to bounce from remailer to remailer
> to remailer...to a final recipient--but no, it was all a shell game!
>
You obviously don't pay all the costs for your feed or else you are very 
rich...


> -fnerd
> 
> 
> 
> 
> - - - - - - - - - - - - - - -
> the snack that eats like a food
> -----BEGIN PGP SIGNATURE-----
> Version: 2.3a
> 
> aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K
> ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz
> 3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG
> sRjLQs4iVVM=
> =9wqs
> -----END PGP SIGNATURE-----
>