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

[George Kadianakis]

Ian Goldberg <iang at 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!