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