Ian Goldberg iang@cs.uwaterloo.ca writes:

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?

Oops, I'm sorry for the confusion.

It's _not_ the hardcoded public key for the *protocol* (the backdoor is not so obvious!).

Each obfs4 bridge generates a long-term keypair in its first run and lives by it. It's the long-term public key that each obfs4 bridge has. I guess you can think of it as the identity key of the bridge on the obfs4 layer.

...

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?

Yep, you read me correctly.

And yes, the public key B is part of the bridge line and mandatory for the ntor handshake.

If so, then \hat{B} indeed doesn't matter much--the IP address/port is probably fine.

Yep, that's what I gathered too.

Unfortunately, the server-side obfs4 might not have access to its address/port (it normally knows that it has to bind to 0.0.0.0:<port>, not the actual external IP address).

So we were considering whether generating a random nodeid would be OK for security. Or even omitting the nodeid completely, and just using the public key B in its place (since \hat{B} is just used as an one-to-one map to a B) Or does this complicate the security proof?

Thanks!