From the PoW of Stef's seven rules of thumb to detect snake oil: 1. Not free software [1]https://github.com/irungentoo/toxcore/commit/dcc3921682c8bededfac7d7 6f4976fd56b051c72 "Licenced the code under the GPL for now." (Free software? Good. But, "for now" ? Is it going to change?) 2. Runs in a browser No. 3. Runs on a smartphone [2]https://wiki.tox.im/index.php/Multiple_Devices Has been suggested but not yet implemented. 4. The user doesn't generate, or exclusively own the private encryption keys The user is in control, yet the source of randomness and crypto implementation are not explained properly. The wiki talks about public keys and PFS without explaining the relation between the two. [3]https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypt o.md 5. There is no threat model "With the rise of government monitoring programs" implies it's designed to be secure against state surveillance. "Tox does not cloak IP addresses when communicating with other users" In disclaimer it is also just stated that "Tox prevents message contents from being read or altered by third parties, or anyone else other than the intended recipient", yet it doesn't even bother to evaluate the system against HSAs or MSAs. Instead, the threat model seems to revolve around developer anonymity ([4]https://wiki.tox.im/DevAnonymity). "Potential harassment by the government and trolls" seems to include people pointing out issues with the software as well. 6. Uses marketing-terminology like "cyber", "military-grade" It doesn't, although it does say "leading-class encryption", and the logo is yet another unnecessary lock. 7. Neglects general sad state of host security This. The developers think it is obvious for every user, that if the endpoint device is compromised, there is no security. This is horrible since average computer user is still mainly occupied with thoughts "I need a firewall" or "I might get a virus" -- not "The government might exploit unpatched OS or exploit a 0-day" or "The company behind my proprietary OS might be issued a subpoena to include a backdoor". It's not the job of Tox developers to patch OS, but it's their job to warn users there are attack vectors the developers are not in control of. They have refused to do so, which limits the users ability to make informed choices depending on their threat model. ---- For some time I've wanted to evaluate TFC from these perspectives as well: 1. Not free software It is, and it will always be. 2. Runs in a browser It doesn't, and never will. 3. Runs on a smartphone Only the handler of encrypted messages might in future run on smartphone (or proprietary OS), the TCB's never will. 4. The user doesn't generate, or exclusively own the private encryption keys The user does, and the user is also in control of the circuit that generates the encryption keys. 5. There is no threat model The whitepaper has a five-page dissection about different attack vectors, what TFC is secure against and what it is not. 6. Uses marketing-terminology like "cyber", "military-grade" It never has and it never will. 7. Neglects general sad state of host security This was the starting point. Key-exfiltration-wise, it is immune against post exploitation of TCB-modules. On 03.02.2015 18:13, rysiek wrote: Yo, don't you die on me! Lately I started testing Tox, it's actually usable, voice and video, and file transfers work, it looks neat. Question is (to quote Tolkien, whom I'm sure we all love and cherish): "Is it secret? Is it safe?" So we have this: Dnia sobota, 5 lipca 2014 22:36:50 stef pisze: afaics there's a traffic analysis weakness in all messages, it discloses both public keys of the peers in public: [5]https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.md#cry pto-request-packets We also have a brave soul (not me) that attemted writing proper protocol documentation for Tox, and started diving into the code. The docs seem lacking, the only things we've been able to find are: [6]https://github.com/irungentoo/toxcore/tree/master/docs [7]https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artif act/tox.pdf/ Not *that* helpful, but look at the Crypto section in the PDF: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Tox uses crypto_box() from the NaCl crypto library for all the cryptography in Tox. Unless otherwise noted, all keys refer to keys generated with crypto_box_keypair(), all encryption is done with crypto_box() and all decryption with crypto_box_open(). For performance purposes the functions to precompute the shared secret and encrypt and decrypt messages with it are used extensively in Tox; however, this is not relevant to this document. The function crypto_box() provides fast public-key authenticated encryption. For exactly how it works read the NaCl docs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hmmm... So, the brave RFC-writing soul got some questions. Maybe somebody here has access to some answers? Questions being: - does the transport layer have encryption? (does the middle layer do that all or...?) - where is the documentation of the cryptography? - is there any hmac done at all? - what is the tox id for a seed with all 0? - how does the tox implementation handle different byte alignment? - how does the tox implementation handle different byte endiness? - how well stressed is the tox implementation? benchmarks? - where is the rest of the documentation? - where can I find a full view of how tox works from bottom to top? Anybody? References 1. https://github.com/irungentoo/toxcore/commit/dcc3921682c8bededfac7d76f4976fd56b051c72 2. https://wiki.tox.im/index.php/Multiple_Devices 3. https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.md 4. https://wiki.tox.im/DevAnonymity 5. https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.md#cry 6. https://github.com/irungentoo/toxcore/tree/master/docs 7. https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artifact/tox.pdf/