[tor-dev] Proposal 216: Improved circuit-creation key exchange

[Mike Perry]

Thus spake Nick Mathewson (nickm at freehaven.net):

> On Fri, Nov 30, 2012 at 12:07 AM, Mike Perry <mikeperry at torproject.org> wrote:
> > Thus spake Nick Mathewson (nickm at 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 bytes
> >
> > I 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:
> 
> 1) 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.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121201/a59ab815/attachment.pgp>