Tox.im

[rysiek]

Dnia wtorek, 3 lutego 2015 21:52:34 piszesz:
> Just because it could be worse doesn't mean it couldn't be better.

True. But the state of affairs right now is that people are massively using 
Skype. So even not-so-well implemented free-software crypto peer-to-peer 
audio-video and IM app is a step-up (as long as it's not being sold as end-
all-problems-heal-your-dog-panaceum).

And I would not call Tox snakeoil mainly because snakeoil salesmen *ignore* 
criticism and *willfully and knowingly* sell bullshit; Tox is at least 
*trying* to get things working and properly implemented, as far as I can see.

So there's a huge difference in (perceived? apparent? true?) intentions.

> Thanks for the whitepaper, I'll have a look when I've the time.

It's 7 pages, hardly a "white paper", and the Crypto section is about 6 lines. 
It's a stub, but it does contain *some* info.

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

Yeah, and I stand by my "still better than Skype, and no intentional nastiness 
so far found". ;)

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

Yes. But now we're discussing the proto and the implementation, so I assume we 
moved forward from the "is it snakeoil" question. At least I hope so.

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

"Using seatbelts only means that the type of the car accident has to change:
 faster and with flying debris."

I'll take the seatbelts, though. I'm fine with making the attacker spend a bit 
more time and resources if they want to get me. There are no bulletproof 
solutions anyway.

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

And the point here is... what exactly? "Don't use encryption, because it 
*might* be broken one day?"

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

And that changes... what exactly? This affects *any and all* desktop-usable 
security solutions, so let's just assume that this is the baseline we have to 
work with and assess the solutions on their own merits, eh?

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

Thanks.

-- 
Pozdrawiam,
Michał "rysiek" Woźniak

Zmieniam klucz GPG :: http://rys.io/pl/147
GPG Key Transition :: http://rys.io/en/147
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 931 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20150203/e7082654/attachment-0001.sig>