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

Show HN: Free, instant, secure, disposable chat rooms built in Go

niltalk.com

Post reply on HN
Print view View original

61–70 of 99 posts

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#61

Post by hurin »

8rian wrote: post #58
hurin wrote: post #54

Earlier quoted context omitted.

The problem with end-to-end encryption is not the encryption but the key-exchange (and especially so for multi-user setups). If you are trusting the server to create or associate identities with keys, the end-to-end encryption is easily subvertible.

New keypairs would be generated on the client every time you join a chatroom. Another member of the chatroom sends you the shared_key encrypted by your public key. Server knows nothing, stores no keys. Keys exchanged between users. Javascript crypto is still a problem though: http://matasano.com/articles/javascript-cryptography/ When you re-download the codebase on every use, there is no way to ensure integrity of th…

> New keypairs would be generated on the client every time you join a chatroom. Another member of the chatroom sends you the shared_key encrypted by your public key. Server knows nothing, stores no keys. Keys exchanged between users.

The question is - how does the first public key exchange happen? It has be done outside of the site for it to be secure and your private key must exist locally on your device - which is contradictory to the premise of these websites.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#62

Post by [deleted] »

hurin wrote: post #54
8rian wrote: post #52

I only feel safe using end-to-end encrypted chatrooms. Currently, niltalk can read every message. At the very least, AES encrypting messages by the chatroom's password will reduce reliance on SSL. But it really should use public key crypto for a key exchange between users. This is what's done by other disposable chatrooms: https://crypto.cat/ https://ephemeral.pw/chat/ (Also written in Go)

The problem with end-to-end encryption is not the encryption but the key-exchange (and especially so for multi-user setups). If you are trusting the server to create or associate identities with keys, the end-to-end encryption is easily subvertible.

[deleted]

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#63

Post by jrussbowman »

jrussbowman wrote: post #50

I've been killed kicking around the idea of doing something similar, in go, with the domain I own ChatFor.Us JavaScript encryption, as others have mentioned is the thing I see I was planning that's missing from yours. I'm planning on going a different direction with the domain, this functionality for private messaging for a platform set up for chat rooms as well. Right now though I'm investigating a node.js and rethi…

Not sure how the word killed got in there. Typing on phone

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#64

Post by knadh »

jrussbowman wrote: post #50

I've been killed kicking around the idea of doing something similar, in go, with the domain I own ChatFor.Us JavaScript encryption, as others have mentioned is the thing I see I was planning that's missing from yours. I'm planning on going a different direction with the domain, this functionality for private messaging for a platform set up for chat rooms as well. Right now though I'm investigating a node.js and rethi…

Nice. From my crude and unscientific benchmarks, I've found that Go is able to handle a lot more concurrent WebSocket connections than Node.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#65

Post by Fastidious »

icebraining wrote: post #60
Fastidious wrote: post #51

How one runs this? I installed go, and redis. The ran "go get github.com/goniltalk/niltalk", which installed. The previous command created three directories under my $GOPATH, one on which has a 'nilktalk' executable. For someone who has never dabbled with go, how do I run nilktalk after all of the above was done?

The README has the full instructions. Edit the file config.json and then do "./run" on the terminal.

Thank you. More on the installation steps on an, now closed, issue[0].

[0] https://github.com/goniltalk/niltalk/issues/3

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#66

Post by rakoo »

attilak wrote: post #44
lclarkmichalek wrote: post #36

Earlier quoted context omitted.

Still would only be as secure as https if the client is downloading your JS crypto lib every visit.

Would it be safe to keep the crypto lib on the client somehow? Browser addon? local storage? How would we do that?

https://webpg.org/

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#67

Post by pjc50 »

new299 wrote: post #56
hiddentao wrote: post #43

Good work. Though I have to say I've seen so many of these web-based "secure, private, anonymous" chat services now, I've lost track. What we need is end-to-end encryption and with an open source client that just has to be downloaded and built/installed once (and in such a way that it's verifiably secure, think reproducible builds).

why does the client need to be built locally? Are you inherently suspicious of anything delivered over HTTPS? I'm genuinely interested in why people feel local clients are more secure than something running in a browser. It's something I came across when writing an ssh client in browser (www.minaterm.com). I guess it's the potential for a HTML page to updated overtime so it no longer reflects an audited version. Howe…

Users fall into two categories:

1) Don't really care about privacy. Might not want their chat on the front page of the papers, but aren't going to go to great lengths to achieve that.

2) Actually care about privacy and are informed. There's not many of these people, but they're trained to be wary of every outside dependency and opportunity for hostile code injection. Crypto running in the browser can be replaced any time you load it if the host is compromised - either in the technical sense or the legal sense. Yes, it could be hashed, but it isn't and there's no mechanism for this nor plans to build one.

Not to mention that the browser itself presents a pretty large attack surface.

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#68

Post by soft_dev_person »

hurin wrote: post #61
8rian wrote: post #58

Earlier quoted context omitted.

New keypairs would be generated on the client every time you join a chatroom. Another member of the chatroom sends you the shared_key encrypted by your public key. Server knows nothing, stores no keys. Keys exchanged between users. Javascript crypto is still a problem though: http://matasano.com/articles/javascript-cryptography/ When you re-download the codebase on every use, there is no way to ensure integrity of th…

> New keypairs would be generated on the client every time you join a chatroom. Another member of the chatroom sends you the shared_key encrypted by your public key. Server knows nothing, stores no keys. Keys exchanged between users. The question is - how does the first public key exchange happen? It has be done outside of the site for it to be secure and your private key must exist locally on your device - which is…

It's asymmetric encryption. Even if the server got a hold of the public key, it would not be able to decrypt the contents.

How to ensure the server doesn't get a hold of the private key is the issue (can you really trust the code you're running?).

Re: Show HN: Free, instant, secure, disposable chat rooms built in Go

#69

Post by akerl_ »

knadh wrote: post #41
icebraining wrote: post #22

Earlier quoted context omitted.

Guess we can check the code and see for ourselves, of course. Alas, you can't really know if the code on Github is actually the same running on their servers.

Author here. I concur, just like any other open source software running as a hosted service. It has to be trust based.

http://www.daemonology.net/blog/2012-01-19-playing-chicken-w...

It doesn't need to be trust-based, and in fact shouldn't be trust-based, because even if I trust you, I also have to trust the people who could coerce or bypass you, or people who could maliciously access/modify your systems.

This is why end-to-end encryption is really the only way to make promises as a server about not reading / storing logs.

Post reply on HN