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