Re: Question on router to router communication

["Wilfred L. Guerin" <wilfredguerin@xxxxxxxxx>]

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

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

On 9/6/07, Nick Mathewson <nickm@xxxxxxxxxxxxx> 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