

Show HN: Terminal-based group chat with end-to-end encryption - jeztek
https://github.com/jeztek/deadchat

======
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](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?

~~~
lawl
Learning is fine, just add a disclaimer that it's actually probably not so
secure. Oh please don't get me started on FiSH, and __PLEASE __don 't model
anything after fish. I had the same problem as you, there's no useable crypto
for irc.

\- The FiSH plugin for Xchat has a (possibly remote) buffer overflow in the
Diffie-Hellman key exchange.

\- FiSH uses ECB mode. Seriously. ECB.... ECB... might as well use no crypto.

\- IIRC FiSH wastes two bytes per 8 byte block the way it does Base64, not
sure about this anymore, it's been a while.

So I tried to find a better plugin and mod it a bit which I did
([https://gitorious.org/fishslim/dumfish](https://gitorious.org/fishslim/dumfish)).
But I didn't realize back then that FiSH uses ECB mode.

Since the DH key exchange is not authenticated it's useless. So I dropped it
and hacked my own (for Xchat,
[https://github.com/lawl/dumfish](https://github.com/lawl/dumfish)), which
doesn't offer DH key exchange but CBC mode instead of ECB, we exchanged keys
manually via OTR. (And just makes me realize I also don't have a disclaimer,
so I'll add this now.)

Disclaimer: Also not a cryptographer, so it's probably not secure. Do not use
for anything serious.

If you want to look at a secure protocol, please look at OTR:
[http://www.cypherpunks.ca/otr/](http://www.cypherpunks.ca/otr/)

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

Key exchanging is _the hardest_ problem your app would have to overcome to
actually be secure, telling your users to just do it again _over an
unauthenticated connection_ is just ... stupid, sorry.

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.

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.

~~~
laumars
This is one of the reasons why I think HTTPS isn't as secure as many perceive.
Users have become so acclimatised to ignoring SSL warnings due to mixed
content, expired or self signed certs and browsers have made it so
inconsequential to skip said warnings that many users wouldn't think twice
about ignoring those errors if there was a genuine MITM attack.

------
StavrosK
kba, your comment is dead, though insightful.

~~~
dfc
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._

~~~
jeztek
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...](http://www.macobserver.com/tmo/article/apples-imessage-encryption-
too-tough-for-fbi)

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

~~~
gojomo
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 libraries in the proper ways") will almost always start
out as a bad programmer of crypto software... who got started, and learned by
failing.

To borrow an aphorism from other project/product wisdom: if your first
version's crypto isn't obviously and embarassingly broken, you waited too long
to release.

~~~
superuser2
Broken social networking websites and YouTube clones are relatively harmless,
so that philosophy makes sense.

Broken cryptography can cause loss of money, infrastructure, and life. Imagine
if a group of dissidents where to start using this program, the crypto
implementation was subtly wrong somewhere, and they were disappeared by their
government early one morning. Imagine if some transmitted a password through
what they thought was a secure chat, and that password led to an industrial
control system for, say, a subway, water treatment plant, foundry furnace, or
explosive chemical storage tank. Software doesn't just move Tweets. There are
massive, hot, high-voltage, fast-moving objects controlled by software also.
Letting people believe information is safe when it isn't can have very real
consequences.

Unless it is obviously written all over your software that "THIS IS A TOY AND
YOU SHOULD NOT EXPECT IT TO ACTUALLY KEEP ANYTHING SECRET," your obviously and
embarrassingly broken crypto (to a crypto expert) might look just fine to a
nontechnical user with dollars and/or lives riding on your product.

~~~
gojomo
Yes, so the message should be: "add disclaimers, avoid promoting where
rigorous security is required, educate yourself on best practices".

Not, "stop releasing hobby projects".

The reckless non-technical user who grabs any project that mentions a slight
sheen of crypto-sparkles, and then trusts that software with their life or
savings, is doomed anyway. The existence of one more hobby project with
amateurish crypto isn't going to kill or bankrupt him twice over.

~~~
jdiez17
I'm okay with hobby projects that use cryptography if every time the user
tries to do anything in which security can be expected they flash a message
that makes the user type "I understand my data may be read by an adversary."

------
Shish2k
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 :/

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

(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 _or_ 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)

~~~
ams6110
I think if you are a "programmer in a hurry" you should stay away from crypto.

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

~~~
gizmo686
I haven't looked at the code itself, but based on the usage section it seems
like everyone in the room shares a secret key. I think the concept is that in
order to get the secret key, you have to explicitly be given it by someone in
the room.

~~~
idupree
By the way, there's an already-existing secure group chat software, SILC, that
does something similar:
[https://en.wikipedia.org/wiki/SILC_%28protocol%29](https://en.wikipedia.org/wiki/SILC_%28protocol%29)
(see "security" section, and technical details in
[http://www.silcnet.org/support/faq/crypto/](http://www.silcnet.org/support/faq/crypto/)
)

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

~~~
davidroetzel
SILC has it own set of problems though:
[https://we.riseup.net/riseup+tech/problems-with-
silc](https://we.riseup.net/riseup+tech/problems-with-silc)

~~~
StavrosK
That is extremely helpful, thank you very much.

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

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

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

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

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

~~~
jeztek
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...](http://www.macobserver.com/tmo/article/apples-imessage-encryption-
too-tough-for-fbi)

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

------
ancarda
>TODO: Disallow unicode usernames

Can anyone explain why this is necessary?

~~~
laumars
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."

------
glockular
hn is not your mother's refrigerator door.

~~~
nitrogen
On the contrary - [http://showinghn.com/](http://showinghn.com/)

