Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Terminal-based group chat with end-to-end encryption

github.com

Post reply on HN
Print view View original

31–40 of 45 posts

Re: Show HN: Terminal-based group chat with end-to-end encryption

#31

Post by laumars »

ancarda wrote: post #29

>TODO: Disallow unicode usernames Can anyone explain why this is necessary?

I think it's just to stop name spoofing using unicode characters. ie pretending to use a registered nick by using characters that look similar. As a non-unicode example: "Bob" looks like "B0b".

Personally though, I'd rather welcome that kind of abuse but not exclude other people from countries who don't use the Latin alphabet. As demonstrated above, it's impossible to automatically moderate username abuse entirely anyway - as you can just start using non-unicode characters or even punctuation such as periods after the username. And if the chat protocol is built in a secure way (which this is not), then there should be other mechanisms for ensuring that Bob is in fact "Bob" and not "B0b" nor "Bob."

Re: Show HN: Terminal-based group chat with end-to-end encryption

#32

Post by j_rogers »

jdiez17 wrote: post #16

Please, please, please, please, please, stop releasing hobby applications that use cryptography. You're bound to do it wrong. Please stop it.

Can you point to a flaw in the cryptography? Otherwise, while I understand where you're coming from I think your criticism is misguided. Cryptography is very interesting and is fun to implement. It is also difficult to get right. Does that mean hobbyists shouldn't implement it? No, it just means that you shouldn't expect security from hobbyist implementations. I find it disconcerting to see comment after comment on HN tearing people down for working on projects that interest them.

The point of criticism is to help people improve. By effectively saying, "You're not cut out for crypto, don't even bother," you do a disservice to others and contribute negativity that HN doesn't need.

Re: Show HN: Terminal-based group chat with end-to-end encryption

#33

Post by jeztek »

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:

* 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.

* I'm here to learn. *

We all have to somehow right? A disclaimer is a good idea, I'll add it to the README.

* 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:

https://github.com/falsovsky/FiSH-irssi

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.

* 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?

* 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?

Re: Show HN: Terminal-based group chat with end-to-end encryption

#34

Post by jeztek »

lawl wrote: post #24

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…

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.

Re: Show HN: Terminal-based group chat with end-to-end encryption

#35

Post by jeztek »

dfc wrote: post #11
StavrosK wrote: post #8

kba, your comment is dead, though insightful.

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 decrypt…

In response to kba:

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...

Re: Show HN: Terminal-based group chat with end-to-end encryption

#36

Post by jeztek »

laumars wrote: post #7
bajsejohannes wrote: post #6

Earlier quoted context omitted.

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…

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.

Re: Show HN: Terminal-based group chat with end-to-end encryption

#37

Post by zimpenfish »

lelandbatey wrote: post #25
gojomo wrote: post #18

Earlier quoted context omitted.

How will people learn if they don't try? The problem is not creating and releasing such applications; the problem is overclaiming their security, or putting early confidence in them. Crypto is hard, we get it. Beginners and non-experts are going to mess it up, we get it. Even experts almost always mess it up, we get it. Still, a good programmer of crypto software (or even just, "wise user of battle-tested crypto libr…

Yeah, my question is what is anyone supposed to do? What if we want something to be secure? Are we supposed to just say "well, I'm never supposed write anything involving crypto"? How do we do things right? Seriously.

(I'm very much not any kind of expert on Crypto but...)

Probably when you understand "Applied Cryptography", front to back, maths included, then you can think about writing cryptographic software.

Or win a fist fight with Schneier.

Re: Show HN: Terminal-based group chat with end-to-end encryption

#38

Post by RyanZAG »

jeztek wrote: post #36
laumars wrote: post #7

Earlier quoted context omitted.

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…

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 s…

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.

Re: Show HN: Terminal-based group chat with end-to-end encryption

#39

Post by StavrosK »

davidroetzel wrote: post #27
StavrosK wrote: post #9

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.

SILC has it own set of problems though: https://we.riseup.net/riseup+tech/problems-with-silc

That is extremely helpful, thank you very much.

Re: Show HN: Terminal-based group chat with end-to-end encryption

#40

Post by jeztek »

RyanZAG wrote: post #38
jeztek wrote: post #36

Earlier quoted context omitted.

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 s…

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...

Post reply on HN