Hey all, great discussion. Apologies for not chiming in earlier, I posted this to HN in the morning and left for 4th of July activities, certainly not expecting it to make the front page. Here're some thoughts and clarifications:<p>* No, I am not a cryptography expert. I've had a nascent interest in the field for awhile and this was my way of getting my feet wet while scratching an itch. I thought I'd post it on HN to get feedback and see where I might have screwed up.<p><i></i>* I'm here to learn. <i></i>*<p>We all have to somehow right? A disclaimer is a good idea, I'll add it to the README.<p>* The project was originally motivated because I couldn't find a group chat service that provided an IRC-like experience with end-to-end encryption. The closest I could find was FiSH-irssi, an irc client plugin:<p><a href="https://github.com/falsovsky/FiSH-irssi" rel="nofollow">https://github.com/falsovsky/FiSH-irssi</a><p>I wanted to try implementing something that was easer to use. I ruled out IRC over SSL because the conversation is cleartext at the server.<p>* I should have mentioned this in the README and will update it -- The design goal for this system is to enable a group of trusted friends to communicate with each other over an insecure channel without fear of eavesdropping. It is assumed that a member of the trusted group operates the server. Forward secrecy was an additional goal facilitated by changing the room key. It sounds like my implementation did not achieve the design goal. What can I do to make it right?<p>* My intention was for the secret room key to be securely shared following the RSA key exchange protocol (encrypt secret with requestor's public key and sign with sender's private key, decrypt with requestor's private key and verify with sender's public key). The problem then lies in how to properly exchange users' public keys. If I trust the server but don't want the server operator to read my conversations, is it not okay to facilitate public key exchange through the server?
Wow.<p>> WARNING: Unable to decrypt. One of you may have changed keys or might be an imposter. Run /idexch if you trust this person.<p>This may very well be the worst advice you could possibly give.<p>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.<p>Key exchanging is <i>the hardest</i> problem your app would have to overcome to actually be secure, telling your users to just do it again <i>over an unauthenticated connection</i> is just ... stupid, sorry.<p>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.<p>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.
Slightly tangential, but can people please stop naming their software "salt"? This is like the 4th or 5th relatively high profile project I've seen with that name recently :/<p>More on topic - does anyone have any good reference guides for how to not suck at cryptography, preferably more "API guide for programmers in a hurry" than "maths textbook for people who want to learn the inner details of algorithms for their own sake"?<p>(I know that knowing the internals will make you a better programmer, but it seems there are a lot of people who don't know the internals <i>or</i> externals of cryptography, and having a step-by-step cookbook which can be followed blindly would make this situation slightly less bad. Sure it might give people a false sense of security - but they already have a false sense of security from rolling their own crypto, so a cookbook couldn't be worse :P)
I'm a little confused by this. How can it be a group chat with end to end encryption? Surely everyone logged into the chat room would need to read the messages, so it's really no more secure than IRC over SSL. Or is this actually more like a peer-to-peer instant messenger?
Don't we already have a secure chat protocol, SILC? Is that not good enough to use? Maybe Cryptocat et al could implement it, rather than creating their own.
Seems very insecure - the keys are sent over the same channel as the messages? Anybody who gets access to the server can log all keys and decrypt all messages passing through.