iphy

I don't believe that marketing like that is the right thing to do. I want to help people be more secure, not just feel more secure through some snake oil security software. Because of that, we (in TokTok) have so far avoided any marketing, and are purely focussed on making the Tox protocol we inherited from the now mostly dormant Tox project properly secure.

Some background: TokTok was started a year ago and inherited the core code from Tox with the intention to take the project to the place it claims to be in. TokTok is not equal to Tox, and we have no control over what the Tox project presents on its website.

I do think that making such claims without any backing security proofs is quite bold. In TokTok, we've avoided that and instead say: our aim is to bring security software to everyone. We don't claim that the software is already secure, but we have confidence in the general architecture and are working towards provable security. Part of that is a formal specification (not the human language spec) helping us provide users and cryptographers with a security proof. We are aware of some flaws, and have concrete plans (roadmap) to fix them.

I know that saying things like that statement you quoted doesn't improve confidence, but I think that saying "we're very secure" without proof is simply a lie. Many projects out there, some similar to Tox, claim security but aren't actually proven secure.

We are now simply a group of people who believe in the idea and want to make it reality. I am affiliated with TokTok, not with Tox.

Regarding public acknowledgement: I will update the TokTok website shortly.

Note that kebolio is in no way affiliated with Tox or TokTok, just a random person contributing to the discussion.

I take full responsibility for everything I said, but I hope I don't need to take responsibility for other people's posts. As nbraud (who is in fact a contributor) noted, this has nothing to do with a secret club. I like to think that all actual contributors are open for discussion and willing to learn what they do not yet know.

I'm sorry, my words were poorly chosen. I am happy you reported this and I'm very happy with the discussion. This was an "if", not trying to point at you in particular.

Yeah, I can understand that reaction. When I started on Tox, I had a similar reaction. It was a project whose code base was only understood by a single person. The current specification is something irungentoo and I worked on to try and document the workings of the protocol, so that we can then make improvements and allow others to understand it.

I am working on Tox because the basic architecture is sound, even though there are some easy to fix security issues. I've started on a well-documented rewrite, but I had to put that on hold to make time for toxcore itself. Zetok has been working on a rust rewrite. I have good hopes for that project and I support it in any way I can.

We are actively working on making the 19k lines of C code better tested, better understood, and better documented. This takes time, but we're focussing on it and I believe we are making good progress.

Again, I can understand that such a statement incites fear, but saying anything else would be a lie. We're working on it.

If your intention is the same as mine (https://github.com/TokTok/website/blob/master/toktok/mission...), then I would hope we can work together in some way. Whether that means helping with discovery of security flaws, by helping us clarify sections of the spec (at this point we can't really call it a spec yet, it's more of a brain dump of the original author), or any other way, I'm happy to discuss opportunities.

If your intention is to incite rage and hatred, our discussion is over. I hope we can do the former.

EDIT: This last sentence is not intended to point at anyone in particular. It's more of a general "you". I'm thankful to zx2c4 for starting the discussion.

We are doing exactly that: we are improving the current core and at the same time modelling the behaviour in Haskell. The Haskell version does not do networking and only represents an executable model of the environment. We use that to test core functionality. See http://toktok.github.io/design/testing.

This is a much wanted feature, and I have long term plans to solve this issue together with a lot of other issues using a distributed data store (file system, database, whatever you want to call it). See https://toktok.github.io/roadmap#distributed-file-system (milestone 9). More realistically, i.e. in the nearer future, milestone 4 (https://toktok.github.io/roadmap#optimisations-for-mobile) covers a simple multi-device feature.

GrayHatter has implemented a prototype and will deliver a design document for the full implementation likely by the end of Q4. It includes profile and contact sync as well as message history sync. If we follow the intended timeline, that feature would likely land somewhere in 2017Q1. uTox and qTox have preliminary support for the prototype.

You and everybody else are invited to review the proposal when it comes out. Be sure to follow the issues on https://github.com/TokTok/c-toxcore/issues. You are also invited to join #toktok on Freenode to bounce ideas around.

Offline messaging will be partially solved by message log sync, as mentioned in milestone 4. The idea is that if you have a desktop computer at home, you could sync the message from your phone to it, and the desktop computer will deliver the message to your friend when they come online. It could be that your desktop syncs with their desktop at some point, and later their desktop syncs with their phone which is the actual delivery. In any case, this solution requires at least one of your and their devices to be online at one point. So far, we have shied away from storing large amounts of data in the network itself. I think the described solutions are sufficient for a large group of users. Federated (email-like) server-based (still distributed, just not p2p) solutions could be used for the remainder.

The preliminary plan is to deliver a high quality implementation of the Tox protocol and then deliver a high quality client. I personally don't have time to do both, and the team has very limited resources. The most actively developed client is currently qTox.

Regarding security audit: my day job is developing high security software. I could do a formal audit, and it would take about 2-3 person-weeks, and be completely useless, because it would result in a huge number of trivial issues that need to be resolved before it could identify real problems. So instead of wasting time and money on that, I've decided to go and fix those trivial issues one by one, and once I'm a bit happier with the code, I'll have two other people do the formal audit.

That works with UDP hole punching (https://en.wikipedia.org/wiki/UDP_hole_punching), and there is a branch with uPNP (https://en.wikipedia.org/wiki/Universal_Plug_and_Play) support. We still need to review that code carefully before accepting it into master.

We're in the process of writing a specification (https://github.com/TokTok/spec) and new implementation in Haskell (https://github.com/TokTok/hs-toxcore). There is also a Rust implementation in the works (https://github.com/zetok/tox).

As for security risks and mitigations, I'd like to do that when we have a web presence with space for it. Right now, the web presence is fairly poor (http://toktok.github.io/). The specification contains some security risks and mitigations.