From the PoW of Stef's seven rules of thumb to detect snake oil:

1. Not free software
https://github.com/irungentoo/toxcore/commit/dcc3921682c8bededfac7d76f4976fd56b051c72
"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
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.
https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.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 (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:
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:
 https://github.com/irungentoo/toxcore/tree/master/docs
 https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artifact/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?