Hacker News new | ask | show | jobs
by bajsejohannes 4736 days ago
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.

1 comments

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.

You can vet who joins the channel by denying unauthorized users the room key. Users who don't have the key cannot post messages to the room.

User authentication, so someone is not able to impersonate you, is on the todo list but it is assumed that the server is trusted and won't go swapping public keys on you. A chat system that doesn't trust the server would need an entirely different design. You need to trust the server to perform basic actions like broadcast your message to the other users in the room.

If that's the case, why go through all this hassle? Simply use IRC with SSL and you have exactly the same level of security. As long as you trust the server, you are fine.
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...

Point taken, you're correct - 1.1 is bigger than 1.0, and if the choice is open, choosing the 1.1/semi secure option is definitely better.