Tox.im

Markus Ottela oottela at cs.helsinki.fi
Tue Feb 3 11:55:07 PST 2015


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.
>> https://github.com/irungentoo/toxcore/blob/master/docs/updates/Crypto.md
> ACK. So, the PDF I linked to goes a *bit* further (just a wee bit). Go 
> have a
> look at the "Crypto" section:
> https://jenkins.libtoxcore.so/job/Technical_Report/lastSuccessfulBuild/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:
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 ( 
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 6750 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20150203/1e628668/attachment-0001.txt>


More information about the cypherpunks mailing list