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

[Ian Goldberg]

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