[lawl]

Wow.

> WARNING: Unable to decrypt. One of you may have changed keys or might be an imposter. Run /idexch if you trust this person.

This may very well be the worst advice you could possibly give.

Suppose Alice and Bob already have a conversation. Then Eve wants to start MITM'ing during middle of the conversation and has already missed the key exchange (where she could easily switch Alice and Bob's public keys because your application doesn't even try to authenticate). Now she just needs to corrupt the packages so your app tells them to do a key exchange again and now can easily switch alice and bobs public keys for a set of her own ones and read everything.

Key exchanging is the hardest problem your app would have to overcome to actually be secure, telling your users to just do it again over an unauthenticated connection is just ... stupid, sorry.

Plus from glancing over it it lacks things like session keys etc.? Though that might well be in the NaCl lib, so I'm not sure about this.

I'd just ask you to label this as POC or something, because no one should use this application for anything that needs to even remotely stay secret.

[laumars]

This is one of the reasons why I think HTTPS isn't as secure as many perceive. Users have become so acclimatised to ignoring SSL warnings due to mixed content, expired or self signed certs and browsers have made it so inconsequential to skip said warnings that many users wouldn't think twice about ignoring those errors if there was a genuine MITM attack.

[jeztek]

That's fair, I modeled some aspects of the system after FiSH-irssi, which also doesn't have user authentication or MITM attack mitigation. That'll teach me to post to HN prematurely. Both SSL with proper endpoint authentication (and session keys) and user authentication are on the todo list.