On Wed, Mar 13, 2002 at 05:07:59PM -0800, William Ahern wrote:
> On Thu, Mar 14, 2002 at 12:17:02AM +0000, jft 628 wrote:
> <snip>
> > Above are the design goals of layer 2. I am not an expert in the area, so
> > I am hesitant to share the rough idea I have of how
> > they could be achieved. But from what I read of anonymous remailers, it
> > seems like you could use the same basic notions
> > here. That is, a node on the network communicates via anonymous
> > remailer-type things. Certain configuration information
> > would have to be set for a networked node, such as what anonymous remailers
> > are trustworthy for what types of data, and
> > reliableness. So then the two participants in a message exchange each have
> > a "line of defense": their list of anonymous
> > remailer-type things through which the message passes. (The configuration
> > information itself could be shared between users at
> > layer 4.)
> <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
[snip]
PipeNet solves this problem by using discrete units of time in which
messages must arrive. This does not use undue amounts of bandwidth, though it
allows the network to be easily disrupted by an attacker. PipeNet is specified
at http://www.eskimo.com/~weidai/pipenet.txt.
>
[snip]
> _______________________________________________
> freenet-tech mailing list
> [EMAIL PROTECTED]
> http://lists.freenetproject.org/mailman/listinfo/tech
--
--Spike Gronim
[EMAIL PROTECTED]
_______________________________________________
freenet-tech mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/tech
