Tox.im

[Markus Ottela]

 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?
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 7608 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20150203/63dea2d8/attachment-0001.txt>