On Sat, May 31, 2014 at 05:51:16PM +0100, George Kadianakis wrote: > Hello Ian, > > hope you are well :) > > I have a question wrt a new PT and ntor. > > Yawning Angel has been developing a new PT called obfs4 (temp name), > which is basically scramblesuit using ntor and elligator2. This > results in better performance than UniformDH.
Was the performance of the key exchange in obfs3 really a bottleneck? Weird. > You can find the spec of obfs4 here: > https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt > You can read a description of the ntor handshake here: > https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt#L149 > > The protocol works fine, but it requires two shared-secrets between > the client and the server. The first is the long-term public key of > obfs4, There's a single public key for the *protocol*? What does that mean? > and the other is the "node id" of the server (defined as > fingerprint of the bridge's identity key). > > My question has to do with the "node id" (denoted as 'capped B' in the > ntor paper) . The problem is that it complicates the deployment of > obfs4, since the bridge operator has to find her bridge's fingerprint > (by looking at $DataDirectory/fingerprint) and add it to her torrc (as > part of the ServerTransportOptions line). Also, the bridge operator > needs to give a similar Bridge line to her clients. > > I was trying to understand if it's possible to simplify this, by not > requiring the bridge operator to make the effort of finding her > bridge's fingerprint. There are at least two possible ways to do this: > > a) Instead of using the bridge's identity key as the node id (which > provides some kind of (unneeded?) channel binding), just generate a > random string to serve as the node id of the bridge. As I > understand it, node id is just a 1-1 map to a specific public key, > so a big random string should be able to do the trick, right? > > b) Just discard the node id, and use the public key in its place. So > wherever 'capped B' is used, just use 'B' instead. Intuitively this > seems OK to me, but I admit I couldn't follow the whole security > proof on Appendix B, to verify that it doesn't make any difference. > > Do you think any of the above approaches is correct, without bludgeoning > ntor's security? The bigger security worry is that with bridges, you don't have the concept of a certificate. Tor nodes' public keys are certified by the consensus, but not so for bridges. However, one could suppose that "manually distributing bridge info" is a type of certificate, in which case the public key B needs to be part of that bridge line. Is it? If so, then \hat{B} indeed doesn't matter much--the IP address/port is probably fine. Thanks, - Ian _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
