On Wed, Mar 07, 2007 at 12:07:25AM -0500, James Muir wrote: > 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?
I believe that k_1 is redundant with respect to TLS's security, yes. (d_1 isn't redundant -- each MAC is with respect to cells that start or finish at that hop, so d_1 isn't used except for control cells to/from N_1 and if the user decides to exit from N_1.) In any case, the AES overhead doesn't seem so bad. Our profiling goals have been to get us back to the state where the crypto is the limiting factor, and I've seen 1Ghz pentiums push 10MB/s of Tor traffic assuming there aren't bottlenecks elsewhere. Getting rid of the public key pieces of the handshake was a smart move though. Let me take your proposal a step further though: why not get rid of k_2 and d_2 too? After all, since people only exit from the end of the circuit in practice, and if the real attack we fall to is the end-to-end correlation attack, isn't it adequate for our encryption and our integrity checking to be just at the end-points too? And the answer is yes, except we're hoping for breakthroughs on the research side that can give us some amount of protection against the end-to-end attack, and I'm guessing that having a more uniform protocol may be handy at that point. On the third hand, you make some good points, and as long as we use TLS correctly, it seems that first layer of AES can be discarded with little ill effects, even if we end up doing mixing or delaying later, and even if the user decides to exit from the first hop. If you wrote up a "spec proposal" for the idea, I bet it would make it pretty far. (One ill effect might arise because the rotation schedule for the TLS keys is way less frequent than for a quick circuit. But if the user is using CREATE_FAST, then he doesn't actually have perfect forward secrecy from that hop anyway.) (I wrote this draft last night but didn't send it, and now others have responded -- I agree with them too.) --Roger
