1994-06-11 - Remailer REORDER not DELAY

Header Data

From: fnerd@smds.com (FutureNerd Steve Witham)
To: cypherpunks@toad.com
Message Hash: b3e7b8096ee402a9b4fa31dfe0db04588b6e1cb888e203784e521dfa1ae7b373
Message ID: <9406110028.AA05143@smds.com>
Reply To: N/A
UTC Datetime: 1994-06-11 00:30:47 UTC
Raw Date: Fri, 10 Jun 94 17:30:47 PDT

Raw message

From: fnerd@smds.com (FutureNerd Steve Witham)
Date: Fri, 10 Jun 94 17:30:47 PDT
To: cypherpunks@toad.com
Subject: Remailer REORDER not DELAY
Message-ID: <9406110028.AA05143@smds.com>
MIME-Version: 1.0
Content-Type: text/plain


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.

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

-fnerd




- - - - - - - - - - - - - - -
the snack that eats like a food
-----BEGIN PGP SIGNATURE-----
Version: 2.3a

aKxB8nktcBAeQHabQP/d7yhWgpGZBIoIqII8cY9nG55HYHgvt3niQCVAgUBLMs3K
ui6XaCZmKH68fOWYYySKAzPkXyfYKnOlzsIjp2tPEot1Q5A3/n54PBKrUDN9tHVz
3Ch466q9EKUuDulTU6OLsilzmRvQJn0EJhzd4pht6hSnC1R3seYNhUYhoJViCcCG
sRjLQs4iVVM=
=9wqs
-----END PGP SIGNATURE-----





Thread