Thus spake Nick Mathewson (nickm@freehaven.net):
On Fri, Nov 30, 2012 at 12:07 AM, Mike Perry mikeperry@torproject.org wrote:
Thus spake Nick Mathewson (nickm@freehaven.net):
Title: Improved circuit-creation key exchange Author: Nick Mathewson
Summary:
This is an attempt to translate the proposed circuit handshake from "Anonymity and one-way authentication in key-exchange protocols" by Goldberg, Stebila, and Ustaoglu, into a Tor proposal format.
It assumes that proposal 200 is implemented, to provide an extended CREATE cell format that can indicate what type of handshake is in use.
Protocol:
Take a router with identity key digest ID.
As setup, the router generates a secret key b, and a public onion key B with b, B = KEYGEN(). The router publishes B in its server descriptor.
To send a create cell, the client generates a keypair x,X = KEYGEN(), and sends a CREATE cell with contents:
NODEID: ID -- H_LENGTH bytes KEYID: KEYID(B) -- H_LENGTH bytes CLIENT_PK: X -- G_LENGTH bytesI mentioned this on the ntor ticket (#7202), but it's probably worth repeating here in case anyone has any suggestions or ideas:
I responded on that ticket a little when you posted it. I think that a proof-of-work idea is interesting and worth analyzing, but probably out-of-scope for #7202 and ntor work in 0.2.4. Here's why:
- The ntor handshake will the force multiplier worse for the
attacker, not better. So this doesn't seem like a regression that should block ntor. 2) We have 10 days left before the implementation deadline for new features in 0.2.4, and negative 20 days left for the deadline for brand-new feature proposals in 0.2.4 [1]. 3) I am sure that we would design something better if we take the time to learn the literature better and write some proposals than we would if we scramble to get something into 0.2.4.
You're right. I didn't mean to distract from finishing ntor on time for 0.2.4.x, I was just curious if anyone else had any ideas. Ntor is pretty darn important by itself, and is also an improvement against this attack, and it should also now be much easier to change the CREATE handshake than it used to be.
I also checked the source, and it does seem like there's no obvious way to send multiple RELAY_COMMAND_EXTENDs down the same circuit. circuit_extend() will tear down a circuit that has circ->n_chan set when it gets a new extend command, and it sets n_chan in the same codepath.
So if nothing else, the attack is somewhat hard to run at full link speed while still using intermediate nodes. You gotta do a lot of circuit parallelization, which would allow you to be fingerprinted at Guards more easily as an attacker than I initially thought.