On Fri, Mar 15, 2002 at 04:37:58AM +0000, jft 628 wrote: > On Wed, 13 Mar 2002 17:07:59 -0800, William Ahern wrote: > > > >On Thu, Mar 14, 2002 at 12:17:02AM +0000, jft 628 wrote: > ><snip> > > > >be careful. anonymous re-mailers do not deal w/ real-time communication. > >you > >can describe both in terms of packet-based communication, but the devil is > >in the details. a good remailer, a mixer, queues some amount of messages, > >then chooses message out of the queue randomly to send so that you cannot > >correlate a message going in w/ the one coming out of the remailer. the > >best > >an attacker could do is say, the message i was tracking that came in could > >be one of 5 leaving. if you follow those five to the next hop, you have the > >same dilemma, you track more and more, and your attack become intractable, > >if not impossible. > > > >unless you erase the correlation, the _quality_ of anonymity is spurious at > >best. the problem in real-time is how long do you wait to queue enough > >packets and still claim real-time. real-time SMTP is different than > >real-time HTTP, which is different than real-time telnet, from than > >real-time voip, etc. the only concrete solution i know of is for each node > >to continually send a steady of strem of packets between nodes, and to > >inject real packets into the stream, aka padding. > > > >but this is resource intensive, and most applications try to ignore the > >issue. if the public TCP/IP network topology were 100% even, you might get > >away w/ it. but as it is, its probably much easier to leverage these > >correlation attacks than most people give credit, because all kinds of > >traffic converge at specific points (MAE-EAST, etc) which becomes a birds > >eye view of a huge swath of the internet. > > > <snip> > > I see what you mean about the different degrees of real time. However, > wheather you are distributing documents or data, getting it out "real-time > SMTP", but not necessarily "real-time voip", seems okay to me. Data has to > propagate as quickly as possible. But it does not need to propagate > instantaneously. So maybe a mixer style approach is okay... > you probably want to mix anyhow, but volume is important. some e-mail mixes queue mail for hours. smtp has no delivery time guarantee, so technically its okay. but if you don't pad traffic, then your delivery latency of messages is tied directly to your traffic volume, i.e. if a node gets a message, it has to wait for at least 2 more (for a minimum of 3) to arrive before mixing them and forwarding.
maybe some scheme that pushes traffic towards nodes to balance latency/volume w/ bandwidth/throughput. sounds complicated tho. anybody have any ideas/comments/shoot-downs? :) _______________________________________________ freenet-tech mailing list [EMAIL PROTECTED] http://lists.freenetproject.org/mailman/listinfo/tech
