Re: one less onion skin

[Roger Dingledine <arma@xxxxxxx>]

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