[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Remailer REORDER not DELAY
Jim choate <[email protected]> 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-----