end-to-end encryption?

[knadh]

end-to-end encryption?

[knadh]

how is this any more secure than google +hangouts or gmail or jabber with TLS?

I don't think Niltalk as a little pet project can be compared to the bigger chat clients. Communication is as secure as SSL (as described on the homepage itself) with no identities or profiles tied to anything with zero persistence along the path. A user create's a channel, exchanges a few words, and there are no logs. That's about it. Maybe I should remove the word "secure" from the description so as to avoid confusion but I don't see what's wrong with "disposable".

End to end encryption is definitely I or someone else should look into, as time permits.

Thank you for the feedback!

[jbenet]

thanks for answering! :)

and the messages do pass through the server

how is this any more secure than google +hangouts or gmail or jabber with TLS?

Your users may not be aware, but the security model you provide is equivalent to those (without accounting for the fact that places like google employ large numbers of security engineers and cryptographers to correctly implement and attack their systems, which may be trusted more than one person without a well-known background in security). iMessage goes a step beyond and theoretically (i say theoretically because it is closed source so we cant verify) implements end-to-end encryption. Things like TextSecure, Signal, etc. go beyond by being open source and user-verifiable.

You are free to propose changes though :)

Great! I propose you either:

• (easy) implement a symmetric encryption channel. use some random input from the user (like the passphrase) to derive a secret key (scrypt, pbkdf2). then use that secret key to setup a cipher (say AES on CTR). can then use the random input from the user to re-derive the key. I would hand out links to the user like niltalk.com/<long-encoded-key> which would be enough to access the chat. if you want to keep the extra step, then do niltalk.com/<hash-of-key> (where hash is something like sha256, maybe even in multiple rounds, and salted), and users have to enter the passphrase to re-derive the actual key.
• (harder) if your trust model changes and you start generating / using identities, you may want to implement a public-key-established symmetric encryption channel (similar to what SSH and TLS do) per peer-pair. Depending on your trust model, you likely don't need CAs at all, and can generate ECC or RSA keys clientside. these could even be ephemeral. (ideally they would be derived from the username the users pick in a verifiable way, but this is harder). Use these keys to exchange (DHE) a shared secret, and then proceed to a symmetric channel as above.

Anyway, don't take any of this as dissuading, i think it's very much a good idea to provide this kind of service, but if you're going to claim security, you have to do it right. Currently, you're putting yourself and users who cant tell the difference at risk. (also may want to not claim "secure" and "disposable" when those things have special meaning in cryptography/security)

(disclaimer: this are rough sketches of what you'd go for, do your own research + run impls by other security engineers before deploying)

[countlurk]

Without end-to-end encryption this system is worthless

[goniltalk]

There is no end to end encryption right now and the messages do pass through the server. You are free to propose changes though :)

[jrmiller82]

It should definitely be asym don't you think?

What about each 'room' having a single Pub key that changes either (a) On a time or number of messages interval or (b) if an invite only room, change the key each time user connects or disconnects. The server then encrypts outgoing according to the recipient's pub key.

Although the server can still read it temporarily. Or permanently if server retains keys or a log.

So, maybe on each transmission the first part is a query to the room for all pub keys of current recipients of room, client then encodes message xyz number of times, passes it via json, and then server just acts like a SMTP daemon and delivers to the recipient clients but doesn't actually decrypt anything?

Could be nuts on bandwidth and cpu if massive room.

[jbenet]

@jrmiller82 it is imperative that the server not be able to read it, at all. this is not hard to achieve, we already know how to do it. it's just complicated and error prone to implement.

[ericselk]

I understand what people are saying here, if they are thinking about this as a usable (as-is) project. For me, just wanted to say thank you VERY MUCH because I'm learning Golang and this is an awesome example of most of the basic principals I need for my future project (not a chat server).

Although, even without end-to-end encryption, I'm sure this is usable by lots of people. There are plenty of use-cases where encryption isn't needed, or even wanted (plenty of chat servers NEED to be able to monitor what is said -- i.e.-every MMORPG chat in existence).

[ericselk]

Oh, I just noticed this: https://niltalk.com/ -- ok, yes, in that case, I think that website should at least disclose the fact that anyone with server access could see the messages. Although honestly, with any chat service where you don't actually compile the code (and review it all) yourself, I think you should assume it isn't 100% private.

[knadh]

@ericselk Thanks. It's explained here https://niltalk.com/pages/privacy

[elimisteve]

Very cool project, but I agree that end-to-end encryption is a must. If I were to add this feature, will you accept the PR? Thanks.

[knadh]

@elimisteve Sure. How do you plan on doing it though?

[elimisteve]

Either by using miniLock or NaCl in the browser to encrypt the messages, using a key derived from the password, and maybe the unique part of the room URL (though the server can see that so I'm not sure about that part).

[elimisteve]

In looking at this further, I very much like your UI, but I'm looking to hide more from the server, such as usernames, and I'm looking to not use Redis (just goroutines and in-memory data structures), and more. Thanks for creating this though! We need more services like it.

[clementauger]

so..... what... given a room with Alice Bob and Peter, if Alice wants to send a message it has to send N version, where N is the number of peers in the room. Each message is accompanied with the target peer id, and is encrypted using the recipient public key, so when the server receives the couple Msg+RecipientId it can transfer it to the correct peer. On message receive the peer can decode the message using its private key, and voilà... ? It means the peer.list event thing has to broadcast public keys.... as long as a javascript implementation exists to handle crypto things it does not appear terribly difficult; though, it adds workload everywhere.
Also for binary data transfer, I guess, it is going to bump by a big factor the size of data (pictures or whatever).