Tox Protocol Specification
toktok / spec Goto Github PK
View Code? Open in Web Editor NEWTox Protocol Specification
Home Page: https://toktok.ltd/spec
License: GNU General Public License v3.0
Tox Protocol Specification
Home Page: https://toktok.ltd/spec
License: GNU General Public License v3.0
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?
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.:
(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.
If I understand the protocol correctly, friend requests have onion routing enabled. A friend request can also have a piece of text attached to it.
So like, can't we enable full onion routing with this design? That is, to send every message with onion routing.
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.
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).
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.
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.
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?
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?
Issue by GrayHatter
25 Oct 2016 at 22:26 UTC+2
Originally opened as TokTok/c-toxcore#210
Attacker goal | Security property | How ToxCore deals with that? |
---|---|---|
Compromise messages | Confidentiality of messages | Messages encryption provided by NaCl. |
Alter sent messages | Integrity of messages | Provided by NaCl, if the message is altered in anyway, decryption will fail, and the message will be dropped. |
Inject false messages | Authenticity of messages | NaCl provides authentication via crypto_box (poly1305). |
Identify as another person | Authentication of communication partner | Once Identity is established through Long Term Public Keys, Communication will only be established with that keypair. (Side |
Block communication | Availability of communications | P2P connections, and Nat Hole punching makes Tox censor resistant but not completely unblockable. |
Learn communication metadata | Privacy protection | Toxcore doesn't leak personal metadata above IP:Ports, but makes no attempt to obfuscate it's data usage profile. |
Prove what was said | Deniability of message content | NaCl crypto_box provides deniablity |
Prove that two persons communicated | Deniability of the conversation | Unknown |
Learn past communication after compromise | Forward secrecy | Forward Secrecy from instance to instance (instances can last years). |
Prolong a successful attack | Future secrecy | Unknown |
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.
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 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.
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.
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.