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.
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_2and the likes.