Show HN: Terminal-based group chat with end-to-end encryption
1–10 of 45 posts
Re: Show HN: Terminal-based group chat with end-to-end encryption
#2Seems 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.
Re: Show HN: Terminal-based group chat with end-to-end encryption
#3I'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?
Re: Show HN: Terminal-based group chat with end-to-end encryption
#4hn is not your mother's refrigerator door.
Re: Show HN: Terminal-based group chat with end-to-end encryption
#5I'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.
Re: Show HN: Terminal-based group chat with end-to-end encryption
#6Seems 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.
From a very cursory look at the source code, it seems like every user share their public keys and the room keys are encrypted with these keys. So looking at server logs don't give you the room keys.
The public keys are sent across the same channel, though, and I don't see any mechanism in place to prevent the server from replacing that public key with their own (man in the middle attack). Maybe I'm missing something.
Re: Show HN: Terminal-based group chat with end-to-end encryption
#7Seems 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.
From a very cursory look at the source code, it seems like every user share their public keys and the room keys are encrypted with these keys. So looking at server logs don't give you the room keys. The public keys are sent across the same channel, though, and I don't see any mechanism in place to prevent the server from replacing that public key with their own (man in the middle attack). Maybe I'm missing something.
What's more, if you can't vet who joins the channel, then you can still have eavesdroppers listening in. So it's really no more secure than IRC over SSL (in fact probably less so because at least with SSL, eavesdroppers would need either access to your channel or to the server. So PMs and private channels are secure. With this, everyone shares the same certs so even your PMs are at risk).
> I don't see any mechanism in place to prevent the server from replacing that public key with their own
I'm not sure that's possible without exchanging the cert via peer-to-peer. In which case, you've already solved the toughest bit of the chat protocol (the handshake and coordination across the clients) so you might as well go fully peer-to-peer and do away with the server entirely.
Re: Show HN: Terminal-based group chat with end-to-end encryption
#8kba, your comment is dead, though insightful.
Re: Show HN: Terminal-based group chat with end-to-end encryption
#9Don'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.
Re: Show HN: Terminal-based group chat with end-to-end encryption
#10I'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?
[deleted]