Issue by GrayHatter
25 Oct 2016 at 22:26 UTC+2
Originally opened as TokTok/c-toxcore#210

Initially asked on IRC, but didn't get any answers.

To find the peers we have announced ourselves to, our friends will find the peers closest to our real public key and ask them if they know us.

This seems to contradict "prevent peers that are not friends from finding out the temporary DHT public key from a known long term public key". Can someone clarify this? Does implementation rely on client to be non-malicious and not disclosing this association?

if the specfication could be more detailed, there would be getting more people involved in this project. And compared to the toxcore project one year ago, its decument does make great progress. I had read the code at that time. And I have read it again recently. But it's a little bit difficult to make it totally understood.

Would you please share with us a nice doc of how it is done? With links, math papers, how much time would it take to break the cipher, etc?

I've been researching this related topics for a while and I have a concern regarding the onion path construction. Kind of related to #56, but from a different angle.

Background

If I understand it correctly, Tor's onion proxy uses directories to fetch random slice of onion routers for building its circuits. This is their way to avoid connecting to nodes directly, but those directory nodes are considered trusted. In Tox there are no such nodes by design (bootstrap nodes are trusted to some degree though, but they are a bit different) and everything is connected directly, which can be used to figure out who have constructed onion path (if my understanding of current Tox's behavior is correct).

The issue

Currently when constructing onion path through 3 nodes, the middle node can scan previous and next node for known peers, take own known peers and the intersection of these 3 sets will very likely contain the node that have constructed onion path.

Potential hardening

I think it could be a good idea to have a dedicated method in DHT for fetching information about all the known nodes (not just search for some of them, but literally all known nodes). Then, by collecting a lot of nodes in this way, filter out those which we've connected to recently and only after that select potential candidates for onion path.

When we select second and third node that we've never connected before (or at least recently), it would mean that middle node will have to collect information about known peers of known peers, namely one step deeper. Assuming that the first node in onion path (that we should be connected directly) has enough known nodes (can be made a requirement for such a node), this makes an intersection of potential candidates bigger. How much bigger and whether that is statistically enough is an open question.

Please consider using the signal and noise pipes protocols.
Signal (formerly axolotl) and noise are very good protocols, well-reviewed and offering very desirable features that go beyond what otr has to offer, e.g.:

• end-to-end encryption
• deniable authentication
• perfect forward secrecy
• future secrecy
• deniability of the conversation (of having exchanged messages at all)
• group chat encryption

(c.f. #50, but since that ticket is about threat model and not concrete protocols, I opened this ticket.
c.f. TokTok/c-toxcore#426 )
Ref: https://eprint.iacr.org/2016/1013.pdf https://whispersystems.org/docs/
ps.: the pre-keys exist to enable offline messaging, but they do not require a server at all, so it can work in a p2p system like tox as well.

Here is the quote from the spec:

If we are announcing ourselves we must put our real long term public key in the packet and encrypt it with our long term private key. This is so the peer we are announcing ourselves to can be sure that we actually own that public key.

Shouldn't it be and sign it with our long term private key instead?

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.

Reading the spec I have a few more questions. I'll combine them into a single issue since they are related.

The spec says that nodes for onion path include DHT nodes and TCP relays. Can someone clarify how many nodes does Tox keep in memory or somewhere else to choose from while building a new onion path? There is quite a lot of numbers specifying timeouts, but this information seems to be missing. I'm asking because this it is very important to have a huge number of known nodes that are not yet connected to each other (meaning they are unlikely to be started by the same person, which is the case while we traverse deeper into DHT), but this will require a lot of time/bandwidth. In BitTorrent DHT it is less of an issue, but in Tox this is a crucial piece used for anonymity.

The next part is probably because I'm lacking some general understanding of onion routing at the moment, but I'd be thankful for clarification or links to relevant specifications.

So when selecting the nodes for future onion path, the node should connect to them and share public keys with each node that is going to be a part of the future onion.
If this is the case, how does this happens exactly?

Also since we are connecting directly to those nodes prior to constructing onion path this should reveal a lot of information about future onion path to someone who is eavesdropping our Internet connection.

Feel free to point me at specific sections of the spec if I'm missing something obvious.

The elliptic curve Diffie-Hellman key exchange, especially one that's ephemeral, would encourage more secure message transport, than just describing the algorithm to be used as generic, non-ecliptic Diffie-Hellman.