Remailer REORDER not DELAY
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-----
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-----
I think that there's a reasonable compromise in here somewhere. It might even address some other concerns that people could have about the costs of running remailers, e. g. storing a zillion messages for 24 hours. How about something like this: - The remailer is configured by its maintener with a maximum desireable time delay and a maximum desireable message queue size. People who do not like the values selected are free to shop elsewhere :-) - When a message arrives, it is assigned a latest output time based on the time that it is received, the remailers maximum desireable time delay and a random factor. - When the remailer's message queue size is greater its maximum desireable size, the message due to be sent next is sent regardless of its latest output time. - When a message's latest output time arrives, it is sent regardless of the remailers message queue size. You might even want to have some other remailer configuration parameters, like: - a maximum number of messages sent out during some arbitrary time interval (message/minute, e. g.) - a minimum interval between messages being sent. These two examples might force the queue size to be considerably larger than its maximum desired size during usage peaks. None of this addresses a situation where a single message is received during an arbitrarily long time period, although none of the other proposals addresses that situation. Although I can imagine how Mallet might abuse this if he coudl control the remailer's net connection, personally, I don't think that it's a problem that merits much consideration. In the absense of a suitably powerful Mallet or other serious networking problems, it's likely that such a situation is just an indication that the remailer isn't very popular. BTW, what possible benefit is there to knowing that a particular message was sent by a particular remailer? As a recipient, should I `trust' a remailer more than I trust, say, a digitial signature from the sender? Could someone describe a situation where this would provide useful information? In other words, why *not* simply encode with the recepient's public key and restrict the usage of the remailer's private to decoding incoming messages? Rick
Excerpts from internet.cypherpunks: 12-Jun-94 Re: Remailer REORDER not DE.. by Rick Busdiecker@lehman.c
I think that there's a reasonable compromise in here somewhere. It might even address some other concerns that people could have about the costs of running remailers, e. g. storing a zillion messages for 24 hours.
[scheme to send out messages in pseud0-randon spurts deleted] I belive the problem is that you can trace a message back to its source by anazyzing when the messages are sent. Let's say you're watching Angie's net connection because you think she is guilty of Thoughtcrime. At 12:34, Andie sends an encrypted message to soda. Say that soda hasn't received any messages for 5 hours before 10:14, then receives 4 between 10:15 and the time Angie's mailer connects to port 25 of soda's remailer. You wait until soda spits out 4 messages, then the 5th is Angie's. You do this through the entire remailer chani, and when Angie's message gets to its destination, you can see it, and trace it back to her. This is bad. Now, if soda had queued a few messages, then spit them out in random order in random chuinks, traffic analysis would be much less effective. For examples of how evil traffic analysis can be, just watch a few episodes of Deep Space Nine. I shudder whenever Otto says "Quark, you have sent 5 messages to the Romulan high command this week." or whatever. Jer darklord@cmu.edu | "it's not a matter of rights / it's just a matter of war finger me for my | don't have a reason to fight / they never had one before" Geek Code and | -Ministry, "Hero" PGP public key | http://www.cs.cmu.edu:8001/afs/andrew.cmu.edu/usr25/jbde/
I belive the problem is that you can trace a message back to its source by anazyzing when the messages are sent. Let's say you're watching Angie's net connection because you think she is guilty of Thoughtcrime. At 12:34, Andie sends an encrypted message to soda. Say that soda hasn't received any messages for 5 hours before 10:14, then receives 4 between 10:15 and the time Angie's mailer connects to port 25 of soda's remailer. You wait until soda spits out 4 messages, then the 5th is Angie's. You do this through the entire remailer chani, and when Angie's message gets to its destination, you can see it, and trace it back to her.
You can also tell it comes from the remailer because it is encrypted to allow you to verify exactly this. I am not interested in hiding the path information, I *want* to certify where it came from - *not* who(!) is sending it or *what* is in it. I can see not knowing or being able to prove the pathway as a possible hole for interjecting bogus packets. Now, about this re-sending issue. If I rcv. a packet at 10am and it gets a random time-stamp there is no guarantee when it will be sent other than within 24hrs. It may or may not be sent in the 5 hr. gap in your example, no way to know really.
This is bad.
Now, if soda had queued a few messages, then spit them out in random order in random chuinks, traffic analysis would be much less effective.
The random order is what does it, not the # of packets sent out. the randomness in leaving the site is more important than how many.
For examples of how evil traffic analysis can be, just watch a few episodes of Deep Space Nine. I shudder whenever Otto says "Quark, you have sent 5 messages to the Romulan high command this week." or whatever.
Excuse me?.....DS9?...
Jer
darklord@cmu.edu | "it's not a matter of rights / it's just a matter of war finger me for my | don't have a reason to fight / they never had one before" Geek Code and | -Ministry, "Hero" PGP public key | http://www.cs.cmu.edu:8001/afs/andrew.cmu.edu/usr25/jbde/
Date: Tue, 14 Jun 1994 12:52:46 -0400 (EDT) From: Jeremiah A Blatz <darklord+@cmu.edu> Say that soda hasn't received any messages for 5 hours before 10:14, then receives 4 between 10:15 and the time Angie's mailer connects to port 25 of soda's remailer. You wait until soda spits out 4 messages, then the 5th is Angie's. If the messages are been randomly ordered, you do not know this. Angie's message could be the first message sent out after it is received. I was attempting to address the possibility of unnecessarily long delays and message queue build up during a period of high use. During a low usage period, the scheme that I outlined should act like the one that Jim choate outlined. If there are long enough delays between messages, none of the proposed schemes interferes with traffic monitoring. Rick
participants (4)
-
fnerd＠smds.com -
Jeremiah A Blatz -
Jim choate -
Rick Busdiecker