Live data from Hacker News

Tox: secure messaging for everyone

tox.im

21–30 of 214 posts

Re: Tox: secure messaging for everyone

#21
Tox aims to be a secure replacement for Skype.

There's several other similar projects, but they are usually hard to set up and use for an average user.

Tox is FLOS software developed by community, and currently licensed under GPLv3. We are considering changing the license to something more permissive, so it would be possible to put it on the App & Win8 Stores.

Currently, it is in really early stages of development. But we already have basic IM, and nCurses interface. We use NaCl library for encryption and will probably add FFmpeg for video.

We are working on a cross-platform GUI using Qt5. Please note that the screen-shots on the main website are only mockups, and (in my opinion) should have been labeled as such.

Since the website is down, here's some links:

Subreddit: http://www.reddit.com/r/projecttox/

Core code: https://github.com/irungentoo/ProjectTox-Core

Qt GUI code: https://github.com/nurupo/ProjectTox-Qt-GUI

Website code: https://github.com/stal888/ProjectTox-Website

IRC Freenode chanel: #InsertProjectNameHere

Re: Tox: secure messaging for everyone

#23
So this appears to naively use DJB's NACL/crypto_box construction, which is a curious choice given the existence of OTR for messaging protocols which would handle things like session key negotiation and provide deniability.

First, If I'm reading the source correctly, they are doing public key encryption for every message. Which, ok, DJB was a fan of at least for DNSCurve, but is generally regarded somewhat dimly for efficiency reasons. So I guess this puts them on one extreme of the Bell Curve or the other. I wonder which?

[EDIT, removed point about nonce's in handshake]

Funnily enough, at first glance it looks like they covered at least some of the obvious issues: they do at least attempt to authenticate the session key and the crypto_box's use of a Nonce prevents replay and re-ordering attacks.

How do they handle video chat? Crypto_box won't work there naively sense packets will get lost and the nonce's won't be in sync.

Re: Tox: secure messaging for everyone

#25
post #13

Earlier quoted context omitted.

According to another comment, it's a product of 4chan, so the offensive verbiage is unsurprising.

Yes, it was made on 4chan's /g/ imageboard.

Good to know different kinds of fags are still an important demographic there. (Normal, new, moral, etc)

Re: Tox: secure messaging for everyone

#27
post #16
post #2

It might be useful to mention more about how encryption is done on the website itself since that is the main selling point. As it stands I have to go through the source code.

Even if you do go through the code and don't find any bugs/backdoors, doesn't mean there are none. Both encryption and secure communications are pretty hard to implement right.

Right. That is always the case. I was only referring to a high-level description about the kind of encryption being used and what made it secure.

Re: Tox: secure messaging for everyone

#30

Unconvinced. * Lossless UDP? Is there a reason not to do TCP? * There is no way to know if the public key is genuine, so the system is very sensitive to MITM. * The key exchange is inadequate. Why not do DH if it's just to have session keys? * The system is very easy to brute force as the acknowledgement is based on a known plain text. This is very bad . A quick glance at https://github.com/irungentoo/ProjectTox-Core…

I can't think of a real-time streaming multimedia application that uses TCP. It probably exists, but nobody uses it; it's simply easier and more efficient to deal with lossy formats over a medium that doesn't care about data loss.

(Note that I said real-time. Buffering is fine for one-way communication, lousy for conversations)

Post reply on HN