Re: one less onion skin
On Wed, Mar 07, 2007 at 09:29:43AM -0500, Paul Syverson wrote: [...] My kneejerk response is that (a) the overhead from this vs. everything else in Tor is very small, This was one of the major reasons for not doing it at the same time as CREATE_FAST. Assuming that TLS conns are mostly longer-lived than circuits, then circuit PK should strongly dominate link PK. The same amount of data, however, goes over TLS as over circuits. Given those (fuzzy, inaccurate) assumptions, it follows using CREATE_FAST should have been sufficient to get rid of 33% of the server-side PK. Dumping the first circuit hop's AES, however, would only get rid (at best) of 12.5% of server-side AES, so it wasn't as immediately clear of a win. (There are 8 server-side AES operations on all the data now: the first two servers in the circuit need to a TLS decrypt, a circuit decrypt, and a TLS encrypt; the third server does a TLS decrypt and a circuit decrypt.) AES was between 8 and 20% of server CPU time the last time I looked; this change would save at most 2.5% of server CPU, which doesn't really make it seem like low-hanging fruit to me. -- Nick Mathewson pgpIDyZo3wm3Q.pgp Description: PGP signature
Re: one less onion skin
Is it because the ORs don't know where they are in the circuit? Of course OR3 knows it's at the end, but the others either recognize or relay. Steve James Muir wrote: A typical Tor circuit looks like OP -- OR1 -- OR2 -- OR3 where the three -- links are all TLS connections. TLS protects the OP's communications from adversaries outside the network, but another layer of crypto (used inside TLS) is needed to protect them from the onion routers themselves (e.g. we don't want OR1 to learn the identity of OR3). Thus, the onion proxy (OP) negotiates AES keys and MAC keys with each onion router; call the AES keys k_1, k_2, k_3 and MAC keys d_1, d_2, d_3. My question is this: why bother with k_1 and d_1? the communications between OP and OR1 don't need to be protected from the other onion routers. I understand the reason for using k_2,d_2 and k_3,d_3, but k_1,d_1 doesn't seem to be adding anything. -James
Re: one less onion skin
Steve Southam wrote: Is it because the ORs don't know where they are in the circuit? Of course OR3 knows it's at the end, but the others either recognize or relay. I agree that not using k_1, d_1 would allow OR1 to determine that they are the first node in a circuit. However, Tor clients already leak this information. The key agreement with OR1 is done using a CREATE_FAST command rather than a normal CREATE. So, once an OR receives a CREATE_FAST it knows its position in the circuit. (it might be that Tor clients which are also onion routers themselves do not send CREATE_FAST... I am not sure) So the question is, if we have already leaked this information, are we wasting CPU cycles doing AES with OR1? -James
Re: one less onion skin
I'm not sure if this really happens, but if you have a connection open to an OR and a new circuit is required through it, couldn't ORn-1 send a CREATE_FAST to ORn? Steve Southam wrote: Is it because the ORs don't know where they are in the circuit? Of course OR3 knows it's at the end, but the others either recognize or relay. I agree that not using k_1, d_1 would allow OR1 to determine that they are the first node in a circuit. However, Tor clients already leak this information. The key agreement with OR1 is done using a CREATE_FAST command rather than a normal CREATE. So, once an OR receives a CREATE_FAST it knows its position in the circuit. (it might be that Tor clients which are also onion routers themselves do not send CREATE_FAST... I am not sure) So the question is, if we have already leaked this information, are we wasting CPU cycles doing AES with OR1? -James
Re: one less onion skin
Steve Southam wrote:
I'm not sure if this really happens, but if you have a connection open
to an OR and a new circuit is required through it,
couldn't ORn-1 send a CREATE_FAST to ORn?
I suppose that could happen, since the OP controls what commands are
sent down the circuit to OR_{n-1}. However, I don't think it would be a
good idea. If OR_{n-1} sent a CREATE_FAST message to OR_n then OR_{n-1}
would learn the value of the AES key that OR_n shares with the OP.
The only legitimate situation in which a CREATE_FAST should be used is
to do key agreement with OR_1.
-James
