Concern about onion path structure disclosure

[nazar-pc]

I've read the spec and then looked at the c-toxcore implementation to double check if I understood it correctly, looks like I've got it right.

The issue

The thing that bothers me a lot about onion path construction and handling in current form is that each node that participates in onion path (including initiator and receiver) knows exactly where in the onion path it is located.

In other words, if my machine relays traffic, I know for sure whether I'm the first node in onion path (receives data from initiator), second node or the third node (which sends data to the receiver).

This knowledge escalates #61 and makes it even easier to accomplish that I have thought it would be.

Potential solution

Essentially, I'd prefer to have onion path in which no one except initiator and receiver knows who they are.

I'm thinking about not nesting each encrypted layer into another, but rather concatenate them. This way we can just unwrap the beginning, look if it was targeted to us, if not - add encrypted address to the end and forward packet further. Using this technic no node in the middle will know how many addresses were unwrapped before it and how many left after.

Concerns with solution

I'm not crypto expert, so I'm not sure if lack of wrapping into multiple encrypted layers reduces effective security. Especially for the address appended to the end of the packet that moves unchanged encrypted pieces closer to the beginning of the packet. It feels like it shouldn't (assuming secure encryption method and only protection against limited observer that can't observer the whole onion path), but would be nice if someone can confirm this.

Further thoughts

This approach would allow us to even hide exact number of hops used in onion path from everyone except receiver if we want to do so (we can append some random bytes to payload and only receiver will not that). Also implementation will become much smaller and more generic than current hardcoded handle_send_1, handle_send_2 and the likes.

[GrayHatter]

The onion doesn't work in tox the way it works in Tor.

It's a mistake to try to coerce it to function like that.

(This is not a argument against your concern, you're completely correct. It's an argument against the onion)

[nazar-pc]

Sorry for possibly mixing Tor's and Tox's terms or something, I've read a few different specs recently and might get confused in the process.

[zugz]

• Saturday, 2017-09-23 at 12:10 +0000 - Nazar Mokrynskyi notifications@github.com:

The thing that bothers me a lot about onion path construction and handling in current form is that each node that participates in onion path (including initiator and receiver) knows exactly where in the onion path it is located.

Yes. This does sometimes make life easier for an attacker, but are there any attacks which are possible with this fact which would be rendered impossible by adjusting the protocol to hide this information? I don't see any. Note in particular that if an attacker controls the destination of a request and another node in the path, they can see if that node is the middle or exit node by observing the IP addresses of neighbours.

[zugz]

• Saturday, 2017-09-23 at 10:09 -0700 - Gregory Mullen notifications@github.com:

The onion doesn't work in tox the way it works in Tor.

It's a mistake to try to coerce it to function like that.

This is off-topic, but it occurs to me that actually Tox's use-case is strongly analogous to that of Tor's hidden servers. In both cases the problem is to allow Alice to anonymously initiate communication with Bob based only on publically available information about Bob (the ToxID for Tox; a .onion address for Tor), without leaking Bob's location.

Tox's current solution is very different from Tor's, but it isn't clear to me that it would be a mistake to take lessons from Tor.

[nazar-pc]

Agree, it might not completely eliminate some attacks, but I'm throwing concerns to the public to discuss whether this is something that needs to be fixed i future or not. Also it is interesting how combining hardening of this aspect and https://github.com/TokTok/c-toxcore/issues/596 would work together. There are always attacks that are impossible to completely eliminate, but sometimes very possible to make them practically out of reach for most attackers except powerful governments.

[nazar-pc]

I've been thinking about this issue and some others for my project and come up with early protocol framework that hides more information than Tox's onion currently (fixes this particular issue) and is much simpler than Tor's onion implementation. It also is more uniform than Tox's routing handling, so that there will be no need to create separate functions for different node positions in onion path. If someone have a bit of free time I'd be thankful for any feedback: https://github.com/nazar-pc/ronion/blob/master/spec.md Implementation doesn't exist yet.

UPD: Implementation is already in the repository.