| In case people are wondering what stavrosk is referring to, kba wrote: I'm tired of people labeling their applications as "cryptographically secure" with no proof of correctness or any kind of guarantee. It's just a blunt and stupid statement. The author of this clearly has no cryptographic expertise and just wrongly applied a cryptographic scheme. In the description, it reads "[..] messages are encrypted and decrypted at the end points such that malicious machines on the network cannot eavesdrop on the conversation, including the chat server," but no effort is made in the client code (client.py) to ensure the server works as it should. Yes, the server can't eavesdrop on the data as-is, but that means you have to trust the hosting provider is using exactly your server.go, thus you have to trust the server completely after all. And if you do, why bother trying to hide it from the server in the first place? I'd feel even less safe using this than IRC over SSL. The major problem with this is that you're trying to do something impossible. In order to have a secure connection between two or more people, you need to either have a key in place or establish one. Both of these options are extremely hard to achieve. In the former, you have a to get a key in place (which can't get transferred through the server for obvious reasons), so that has to be established before any confidential data is being transferred. This is clearly not happening. The latter option is a key exchange protocol such as Diffie–Hellman. This can work; you can in fact make a key exchange between two parties where an eaves-dropper will be none the wiser for listening in. But then you have another problem: authenticity. You have no guarantee that you are in fact talking to who you think you are. Your system makes no effort to overcome either of these challenges. |
deadchat implements the latter option. The secret room key is shared using the RSA key exchange protocol but you're right, there's currently no way to guarantee that you're talking to who you think you are. User authentication is on the todo list.
I think there's still value in hiding the conversation from the server even if you must still trust the server to not behave maliciously. If some three-letter agency contacts the server operator asking for a back channel to listen in, he or she could respond that it's not possible without malicious intent towards a user:
http://www.macobserver.com/tmo/article/apples-imessage-encry...