On 03.02.2015 20:38, rysiek wrote:

     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.
     [1]https://github.com/irungentoo/toxcore/blob/master/docs/updates/Cr
     ypto.md

     ACK. So, the PDF I linked to goes a *bit* further (just a wee bit).
     Go have a
     look at the "Crypto" section:
     [2]https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessful
     Build/artifact/tox.pdf/
     So, at least not a "we hold your keys -- FOR SAFETY!!1!" kind of
     snakeooil.
     Half of an "AOK" from me here.

   Just because it could be worse doesn't mean it couldn't be better.
   Thanks for the whitepaper, I'll have a look when I've the time.

     *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.

     True. One has to consider their own threat model and assess if Tox
     is the
     answer. Tox does *not* provide anonymity, it at least *tries* to
     provide OTR-
     like features (encryption, integrity, etc.).

   IIRC the DH signing keys are bound the the account ID. Appelbaum
   recommended in his 31c3 talk 'Reconstructing Narratives' that users
   rotate their OTR keys often and verify the hash using off-band channel.
   I'm not sure it's a convenient thing users have to re-add their
   contacts every time the DH signing key needs to be refreshed. It's sort
   of good thing users are immediately using the public signing key (Tox
   ID) but the issue is, while the Tox ID doesn't have to be secret, it
   must be authentic: so users unaware of this can be subjected to MITM
   attack.

     *7. Neglects general sad state of host security *

     Well, yes, and my beef with Tox is also that the private keys do not
     require a
     passpharse to unlock. So that's a no-no in my book.

   This only changes the type of attack: a keylogger has to be used along
   the private key exfiltration tool.

     Still, this doesn't look like snakeoil; rather like a good idea with
     not-so-
     stellar execution, which *might* get better.
     Am I missing anything?

   I would argue the current OTR/PGP/ZRTP implementation has limited
   lifespan regardless of execution, given the fact intelligence community
   is expanding end-point exploitation to mass surveillance levels:
   methodology is changing, not the scale:
   [3]https://www.youtube.com/watch?v=FScSpFZjFf0&t=37m35s
   There's a lot of misconception on 0-days being expensive
   'one-time-hacks' that must be used only when necessary. How many
   anti-virus programs detect and report these? What percentage of users
   are running some sort of IDS? How many users assume sudden system crash
   is due to malfunctioning exploit/payload? A 0-day is more like a master
   key for given OS with average lifespan of 300 days (
   [4]http://users.ece.cmu.edu/~tdumitra/public_documents/bilge12_zero_day
   .pdf )

     Could we have a *separate* thread for it? I'm really interested in
     having a
     more in-depth discussion of Tox and this could potentially hi-jack
     this
     thread. Much obliged.

   I agree it should be separate. I tried to keep that section short and
   the intention
   was to provide contrast and show each of these can be addressed
   simultaneously.

References

   1. https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.md
   2. https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/artifact/tox.pdf/
   3. https://www.youtube.com/watch?v=FScSpFZjFf0&t=37m35s
   4. http://users.ece.cmu.edu/~tdumitra/public_documents/bilge12_zero_day.pdf