[tor-dev] obfs4 and ntor (question wrt node_id)

[George Kadianakis <desnacked@xxxxxxxxxx>]

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!
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev