Question on router to router communication

[Wilfred L. Guerin]

The initial design was intended to push as much data through any specific
wire or connection to provide additional cover for the trackability. There
was heated arguments about "cover noise" and constant loops being
established with continuous cyphers to eliminate entry-exit incident
tracking and provide for timed and buffered distribution. There are a lot of
ineffeciencies with this system as it currently stands, no less the use of a
single crypto method and lack of more diverse distribution models.

You can always run two services on a machine and loop to a similar
arrangement elsewhere, however it would be far more effective to use
multiple outgoing wires and multiple machines to facilitate intra-system
mixing prior to exit routes.

Remember, your https key negotiation goes on the same wire in a very
predictable manner right before your bank data does the same.

-Wilfred
Wilfred at Gmail.com

... I still find no published way to effectively protect intellectuals from
externally injected data or logistic liabilities.



On 9/6/07, Nick Mathewson <nickm at freehaven.net> wrote:
>
> On Wed, Sep 05, 2007 at 09:58:37AM -0700, Michael_google gmail_Gersten
> wrote:
> > I've noticed that my tor configured as a client will only have one
> > outgoing TCP connection to an entry node, no matter how many circuits
> > Vidalia shows as going to that entry guard.
> >
> > I'm assuming that this continues on other router to router channels --
> > if there are three circuits that go from (for example) desync to
> > Tonga, there will only be one TCP connection.
> >
> > Is this necessary from a security standpoint? Tor can be sped up if
> > that "one channel per pair" restriction can be broken.
>
> Probably, yes?  Otherwise, it is trivial for an external attacker to
> separate individual circuits and trace them more easily.  (It may be
> possible to do this anyway with traffic analysis techniques, but also
> maybe not.)
>
> For more information on the Tor design, you might want to check out
> the design paper at http://tor.eff.org/doc/design-paper/tor-design.pdf .
>
> > (Just like IP itself. A layer two connection between two nodes has (I
> > forget exactly) 8 channels, each of which can only have one
> > outstanding packet. Allowing Tor to have multiple channels between two
> > nodes will prevent a single stopped TCP from stopping all traffic
> > going that way.)
>
> Another long-term solution is possibly to switch to a UDP transport
> between Tor servers (using DTLS in place of TLS) and then provide
> reliability and ordering at a higher layer of the protocol.
> Unfortunately, this is pretty hard, and we don't have a really solid
> idea of how to do it best.
>
> yrs,
> --
> Nick Mathewson
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070906/5ceda090/attachment.htm>