Live data from Hacker News

Tox: secure messaging for everyone

tox.im

31–40 of 214 posts

Re: Tox: secure messaging for everyone

#31

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…

>Lossless UDP? Is there a reason not to do TCP? Hole punching. >There is no way to know if the public key is genuine, so the system is very sensitive to MITM. If you want to add someone you need their public key (their id) which is 32bytes (It's small because we use ECC instead of RSA). Unless someone somehow replaces the key (your id) when you give it to your friend the system should be secure. >The key exchange is…

Your answer raises my eyebrows even more.

I ask why you don't use DH and you answer "because we want forward secrecy". DH has been designed for perfect forward secrecy. Therefore I fear we might have some sort of misunderstanding here.

You don't want to permit known plain text attack as "in depth defense" approach. If there is ever any weakness in your software, you want to make it very hard to exploit it. Known plaintext will make exploiting weaknesses in your PRNG very easy for example.

As for your last comment... If someone ever changes the behavior of read_packet, you're dead. So I'm sorry, but you have potential buffer overflow. Think in 4 dimensions Marty! :)

Re: Tox: secure messaging for everyone

#32

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…

> Nonce's are "Numbers used ONCE", they 1) don't need to be secret and 2) ARE NOT encryption keys.

We know.

Putting the nonces in the handshake along with the session public key was simple.

In the NaCl docs it is advised that if you can keep the nonces secret that you do so.

Re: Tox: secure messaging for everyone

#33

Since you managed to kill the website: https://github.com/irungentoo/ProjectTox-Core Tox is a completely decentralized secure messaging service which aims to replace skype. It it still in heavy development. So far we have IM working almost perfectly but no completed GUI yet except for a basic ncurses interface used to test the core. For the detailed info on how everything works see: https://github.com/irungentoo/Proj…

Hey, congrats on the hard work. I'm going to try it out. Is there a bird's-eye-view on how you have made it secure?

Re: Tox: secure messaging for everyone

#34
post #8

Github maintained by someone with a troll username? Comments like this: > IMPORTANT: release two major sanctioned UIs, one for autists, one with inbuilt support for the previous list so that plebs can't get confused with setting it up and autists don't complain about it getting in their way. de geso > I would suggest a "Advanced options" where the autists can rejoice with all kinds of options (and it doesn't frighten…

>Github maintained by someone with a troll username?

>Comments like this

>> IMPORTANT: release two major sanctioned UIs, one for autists, one with inbuilt support for the previous list so that plebs can't get confused with setting it up and autists don't complain about it getting in their way. de geso > I would suggest a "Advanced options" where the autists can rejoice with all kinds of options (and it doesn't frighten the normalfags, since it's not shown by default). Also, 2 UIs would be chaos to maintain.

The project originated from 4chan's /g/ (technology) board. It works differently from Reddit and HN, since there's no karma, and the comments are anonymous.

This caused it to develop a unique culture. On one hand, it enables people to express their real opinions without being afraid of getting downvoted by hivemind. On the other hand, it attracts trolls and causes a lot of rudeness and offensive behaviour.

I like the website, because you can see the true nature of people, and you don't feel the pressure to say what everyone else wants you to say.

>Talk about not needing to be an expert to use it, but then a "learn more" button sending people to github?

We were working on this for only about a month, and Tox is not even in the alpha stage yet. Once we get the GUI working properly, we will surely upload binaries to the website.

Re: Tox: secure messaging for everyone

#35
Minor contributor here: we've been trying to recruit help from HN multiple times with no luck. /g/ recognizes that the dev talent on the web resides here, so if you have a mastery of any of the needed skills (C, GUI design) we'd love your help.

Re: Tox: secure messaging for everyone

#36
As a naive potential user I am willing to take the assurance of proper crypto and forward secrecy. What needs to be addressed also is the issue of metadata. It is the broad collection and easy analysis of metadata -- NOT content -- that makes NSA monitoring so sinister. By knowing all about who you connect with, when, for how long, and with what regularity, they can know a vast amount about you.

What of the who/when/how-long/how-often metadata is evident when using Tox? As compared to normal skype or IM, that is?

Re: Tox: secure messaging for everyone

#37

Earlier quoted context omitted.

>Lossless UDP? Is there a reason not to do TCP? Hole punching. >There is no way to know if the public key is genuine, so the system is very sensitive to MITM. If you want to add someone you need their public key (their id) which is 32bytes (It's small because we use ECC instead of RSA). Unless someone somehow replaces the key (your id) when you give it to your friend the system should be secure. >The key exchange is…

Your answer raises my eyebrows even more. I ask why you don't use DH and you answer "because we want forward secrecy". DH has been designed for perfect forward secrecy. Therefore I fear we might have some sort of misunderstanding here. You don't want to permit known plain text attack as "in depth defense" approach. If there is ever any weakness in your software, you want to make it very hard to exploit it. Known plai…

DH wasn't designed for forward secrecy.

Re: Tox: secure messaging for everyone

#38
post #8

Github maintained by someone with a troll username? Comments like this: > IMPORTANT: release two major sanctioned UIs, one for autists, one with inbuilt support for the previous list so that plebs can't get confused with setting it up and autists don't complain about it getting in their way. de geso > I would suggest a "Advanced options" where the autists can rejoice with all kinds of options (and it doesn't frighten…

>Github maintained by someone with a troll username? >Comments like this >> IMPORTANT: release two major sanctioned UIs, one for autists, one with inbuilt support for the previous list so that plebs can't get confused with setting it up and autists don't complain about it getting in their way. de geso > I would suggest a "Advanced options" where the autists can rejoice with all kinds of options (and it doesn't fright…

And another thing: /g/ in particular is known for much pointless banter arguing over the best GNU+Linux distro or giving minor tech support to non-natives of /g/. Attempts have been made before to make something substantial on the board and this time it seems we can do it.

Re: Tox: secure messaging for everyone

#40

Earlier quoted context omitted.

>Lossless UDP? Is there a reason not to do TCP? Hole punching. >There is no way to know if the public key is genuine, so the system is very sensitive to MITM. If you want to add someone you need their public key (their id) which is 32bytes (It's small because we use ECC instead of RSA). Unless someone somehow replaces the key (your id) when you give it to your friend the system should be secure. >The key exchange is…

Your answer raises my eyebrows even more. I ask why you don't use DH and you answer "because we want forward secrecy". DH has been designed for perfect forward secrecy. Therefore I fear we might have some sort of misunderstanding here. You don't want to permit known plain text attack as "in depth defense" approach. If there is ever any weakness in your software, you want to make it very hard to exploit it. Known plai…

Please explain how DH was designed for perfect forward secrecy...

Please explain why shown plain text in this context would make exploiting weaknesses in their PRNG any easier...

Post reply on HN