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.
<br><br>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.
<br><br>Remember, your https key negotiation goes on the same wire in a very predictable manner right before your bank data does the same.<br><br>-Wilfred<br><a href="mailto:Wilfred@Gmail.com">Wilfred@Gmail.com</a><br><br>
... I still find no published way to effectively protect intellectuals from externally injected data or logistic liabilities.<br><br><br><br><div><span class="gmail_quote">On 9/6/07, <b class="gmail_sendername">Nick Mathewson
</b> <<a href="mailto:nickm@freehaven.net">nickm@freehaven.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Wed, Sep 05, 2007 at 09:58:37AM -0700, Michael_google gmail_Gersten wrote:
<br>> I've noticed that my tor configured as a client will only have one<br>> outgoing TCP connection to an entry node, no matter how many circuits<br>> Vidalia shows as going to that entry guard.<br>><br>
> I'm assuming that this continues on other router to router channels --<br>> if there are three circuits that go from (for example) desync to<br>> Tonga, there will only be one TCP connection.<br>><br>> Is this necessary from a security standpoint? Tor can be sped up if
<br>> that "one channel per pair" restriction can be broken.<br><br>Probably, yes? Otherwise, it is trivial for an external attacker to<br>separate individual circuits and trace them more easily. (It may be
<br>possible to do this anyway with traffic analysis techniques, but also<br>maybe not.)<br><br>For more information on the Tor design, you might want to check out<br>the design paper at <a href="http://tor.eff.org/doc/design-paper/tor-design.pdf">
http://tor.eff.org/doc/design-paper/tor-design.pdf</a> .<br><br>> (Just like IP itself. A layer two connection between two nodes has (I<br>> forget exactly) 8 channels, each of which can only have one<br>> outstanding packet. Allowing Tor to have multiple channels between two
<br>> nodes will prevent a single stopped TCP from stopping all traffic<br>> going that way.)<br><br>Another long-term solution is possibly to switch to a UDP transport<br>between Tor servers (using DTLS in place of TLS) and then provide
<br>reliability and ordering at a higher layer of the protocol.<br>Unfortunately, this is pretty hard, and we don't have a really solid<br>idea of how to do it best.<br><br>yrs,<br>--<br>Nick Mathewson<br><br></blockquote>
</div><br>