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.
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, 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?
Thanks!