-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
end-to-end encryption? #1
Comments
There is no end to end encryption right now and the messages do pass through the server. You are free to propose changes though :) |
thanks for answering! :)
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.
Great! I propose you either:
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) |
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! |
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. |
@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. |
Without end-to-end encryption this system is worthless |
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). |
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. |
@ericselk Thanks. It's explained here https://niltalk.com/pages/privacy |
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. |
@elimisteve Sure. How do you plan on doing it though? |
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. |
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. |
Are you encrypting messages end-to-end? AFAICT, you're only encrypting the HTTP + WS connections to the server with traditional SSL. Am I right in saying that the server can spy on all the traffic?
The text was updated successfully, but these errors were encountered: