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
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-----
Return to June 1994
Return to “Rick Busdiecker <rfb@lehman.com>”