I made sure to make the packets in Tox as easy to parse as possible which greatly lowers the chances of fatal packet parsing bugs being present.
As for the main tool I use to find bugs, it's asan (the clang address sanitizer) which is much more useful than static analysis for finding actual bugs.
Of course the main thing I do to try to prevent bugs is reread the code again and again which is what catches pretty much everything.
It's open source so anyone can run their favourite tool on it,
>Proplex, a long-time member of the Tox-Foundation and in charge of both infrastructure and marketing, called out tox devs because the 2 people in charge (irungentoo and stqism) were dealing with money in a shady way and he got suspicious
We barely get any donations. We barely have money and we are very transparent about it, look at our donations page.
>After he went away and stopped to pay for the website and other servers (he hosted everything)
He disappeared one day, didn't warn us or anything and took everything (including backups) with him.
>Tox devs got angry and tracked his online activity by his browser UA, read his private email sent to his @tox.im address and considered breaking into his VPS account
Yes because I wanted to know if he had done anything weird on the site. We never considered breaking into his account. His tox.im mail was never remade on the new tox.im mail server so all emails sent to it ended up in our catch all email.
>Members of the Tox Foundation such as stqism try constantly to sneak in copyright changes
I'm a member of the Tox foundation and I don't sneak in copyright changes in my repo. He also didn't try to sneak it in. I never merge pull requests before reading everything first.
>After it got out of hand and too many people called out the Tox Foundation, this happened
Yes and I explained exactly what happened. What is the issue?
>irungentoo enforced censorship on his github repo to try to cover everything up
Because kicking trolls is censorship?
>irungentoo claims Tox is secure just because he uses a secure primitive
Scroll down to my next comment in that thread.
Sorry for my previous comment. This one should be better.
First of all the choice of C is because it was the language I was the most confidant writing secure code in. I'm not going to learn a new language and then right away start try to write secure code with it.
Clang has some great tools I use like the various sanitizers. Static analysis sucks and almost never finds any real issues but we still use it.
If you think toxcore should use protocol buffers, feel free to port it. This is an open source project and contributions are welcome. If you do a better job than me then I will merge your contribution. We are at #tox-dev on freenode.
You are just some troll trying to kill our project with fabrications and lies. You twist the truth to fit your own agenda.
The guy in question tried to damage the project on his way out so yes I grepped our server logs for his ips because I wanted to know if he had tried anything weird.
This guy posting this comment here is someone who decided to start this war against the project after I refused to kick someone who actually did something from our project. He posts this bullshit everywhere.
Our threat model is an attacker that wants to read and record the contents of conversations between everyone, they have the ability to modify/add/remove and log any packets. We assume they do not have any access to the actual machines Tox is running on.
The main goal of Tox is to make it hard for a global threat to conduct mass surveillance on everyone at the same time without sacrificing performance.
If the majority of the people using Tox have "nothing to hide" and use it because it works better than skype, the minority that does need the crypto will be able to use it without being discriminated against.
describes the protocol used to connect securely to friends after they find themselves.
This protocol has PFS, message padding to prevent length based leaking and should be immune against replay attacks.
What makes it secure is that you know the long term public key of your friends making it really easy for the software to establish secure connections to them.
>There is no way to know if the public key is genuine, so the system is very sensitive to MITM.
If you want to add someone you need their public key (their id) which is 32bytes (It's small because we use ECC instead of RSA). Unless someone somehow replaces the key (your id) when you give it to your friend the system should be secure.
>The key exchange is inadequate. Why not do DH if it's just to have session keys?
The key exchange is designed that way because we want forward secrecy.
>The system is very easy to brute force as the acknowledgement is based on a known plain text. This is very bad.
Can you please elaborate on this. If you are speaking about the the second part of the crypto handshake I can assure you that the fact that the plaintext is known is not a problem.
>I found a potential buffer overflow at line 143. If an attacker sends a large file, what happens?
The function read_packet is hard coded to never return something bigger than MAX_DATA_SIZE.
http://dl.ifip.org/db/conf/aims/aims2009/BocekPHHS09.pdf
seems to be the correct link.