[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On Fri, Nov 30, 2012 at 12:07 AM, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:
> Thus spake Nick Mathewson (nickm@xxxxxxxxxxxxx):
>
>> 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.

So unless there's something above that I'm getting wrong, this is a
topic that I'd like to come back to in a week or two, once I'm dug out
from under the stuff I want to get in before the Big Feature deadline
[1].  Stuff I should expand on then includes:
  * "Replay caches can afford be fuzzy and imperfect "
  * "GPUs vs smartphones"
  * etc

[1] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/024
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev