
Show HN: Free, instant, secure, disposable chat rooms built in Go - SatyajitSarangi
https://niltalk.com/
======
8rian
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://crypto.cat/)

[https://ephemeral.pw/chat/](https://ephemeral.pw/chat/) (Also written in Go)

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

~~~
8rian
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/](http://matasano.com/articles/javascript-cryptography/)

When you re-download the codebase on every use, there is no way to ensure
integrity of the code. This is the reason cryptocat ships as a chrome
extension, because it is downloaded once. Even with these issues, I'd take
javascript crypto + open source over nothing (or just SSL).

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

~~~
soft_dev_person
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?).

~~~
StavrosK
The bigger problem is "how do you ensure that the public key the server sent
is actually the other user's, and not a MITM?".

~~~
hurin
Exactly, you have to exchange public-keys via another method - which is also
potentially vulnerable.

~~~
c22
But all forms of exchange are potentially vulnerable, the point of using
multiple channels for authentication is to increase the challenge-space for
potential attackers. Indeed the chief benefit of public key encryption is that
the key can be exchanged over a multitude of channels and a compromise of just
some of them does not jeopardize the entire operation. Perhaps we need more
authentication systems where this is made implicit, with trust based on the
number of different mediums the key is transferred over (or the number of
different third party signers).

------
DanBC
Have two buttons: "vote to keep open" and "vote to close". Colour them orange
and blue. Release it to Reddit. Potential viral hit.

~~~
addandsubtract
Have one button. Release to Reddit. Potential viral hit.

~~~
zatkin
For anyone who doesn't understand this reference, there is a massive social
experiment going on at Reddit:
[https://www.reddit.com/r/thebutton](https://www.reddit.com/r/thebutton)

------
SatyajitSarangi
You can checkout the public repo here:
[https://github.com/goniltalk/niltalk](https://github.com/goniltalk/niltalk)

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

~~~
new299
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. However it seems that it's really a failing in
our browsers that this is the case. Perhaps an external service that verifies
the hash of a page would help? But this would need browser support of course.

The only thing I could think of that could be implemented in current browsers
was a small stub page which calculates and displays a hash of the
HTML/Javascript to be launched. The stub would need to be small enough that a
user could manually check that nothing malicious has been added here.

~~~
cmdrfred
I was looking for something like minaterm the other day, trouble is i'd be
scared to put my credentials into it. A when I think about it logically that
isn't rational (putty can grab my credentials just as easily), but still.

~~~
c22
It's not entirely irrational. If putty wants to grab your credentials they
have to ship a broken binary that once downloaded exists forever and can be
examined and reverse engineered in the wild. Someone running a web service (or
someone who has compromised said service) can target a particular user for a
single session and the evidence that an attack occurred will only exist until
a few caches get cleared.

------
BorisMelnik
Have you been measuring the server load of this at all since this thread has
been open? Very curious as to what that looks like.

------
fmstephe
Is this open-source?

If it is could you post a link to a public repo. Thanks :)

~~~
knadh
Author here. Yes of course -
[https://github.com/goniltalk/niltalk](https://github.com/goniltalk/niltalk)

PS: The "source" link is in the footer of the website as well.

~~~
pierrec
Wait, you're the author but someone else submitted it as "Show HN"? That's...
not how it's supposed to work, but hey, at least you're in the thread.

Here's another room (pass is dontclickdispose):

[https://niltalk.com/r/8L5MD](https://niltalk.com/r/8L5MD)

~~~
jobigoud
And it's gone.

Last messages were about how the Dispose button is conspicuous and easy to
press by mistake.

------
jrussbowman
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 rethinkdb infrastructure, but
that's also because I will need to persist data somehow.

Thanks for building this, at least validates that someone else has similar
ideas.

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

~~~
jrussbowman
I assumed it would. But I'm thinking socket.io would provide better client
support and have been looking at meteor as a way to get something built fast.
Going Roth a prototype first as I have a lot less time to do this stuff these
days. I'm about equally proficient in both go and node which is to say I can
stumble my way to a solution with both.

------
hurin
And this is secured how exactly?

~~~
gnoupi
Password-protected and no public listing, I assume. Nothing on secure data
transfer, though.

~~~
jfindley
The number of bcrypt rounds is extremely low, too[1]. While the Go bcrypt lib
will actually accept a cost of 5, that seems an unreasonably low value to me.

Coupled with absolutely no encryption of the messages in memory, I think
"anonymous" would be a better term than "secure" for this.

1:[https://github.com/goniltalk/niltalk/blob/master/api.go#L75](https://github.com/goniltalk/niltalk/blob/master/api.go#L75)

~~~
Someone1234
Your bcrypt complaint is pretty petty. They aren't storing the hash on disk at
all, and the chat rooms are only temporary.

I do have privacy concerns about this and agree they can eavesdrop if they
wish. Increasing the bcrypt rounds from 5 to 15 would in no way help with any
of that.

~~~
jfindley
It's in a redis database, so it's not all that hard to get at, either, should
someone compromise the system. "Not on disk" stops being such a good defence
when it's stored in a semi-persistent DB.

My main complaint, though, is that there's simply no reason to choose such a
low number of rounds. Using the exact same code as in this app, 5 rounds takes
3551534 ns/op, 10 rounds takes 3583632 ns/op and 15 rounds takes 3623005
ns/op. In other words, it's only 2% slower to use 15 rounds than it is 5, and
the default (10) is less than 1% slower.

~~~
Someone1234
If someone has an active compromise on a running machine, they can intercept
network traffic and bypass bcrypt completely.

> In other words, it's only 2% slower to use 15 rounds than it is 5, and the
> default (10) is less than 1% slower.

So are you arguing that your complaint is petty or isn't? Because this isn't
helping your case.

Overall your attack scenario is where an attacker has just enough access to
the machine to read memory in the redis database, but not enough access to
read memory in the web-server, or at the point before bcrypt has been run in
the process.

If redis was stored to disk you may have a valid point. As it stands your
argument actually doesn't make sense. If they can access Redis they can access
pre-bcrypt passwords and therefore making bcrypt's rounds completely
unimportant.

~~~
jfindley
> If they can access Redis they can access pre-bcrypt passwords and therefore
> making bcrypt's rounds completely unimportant.

No. The unhashed passwords are not stored in redis. What I think you're
missing is that there's a significant difficulty gap between connecting to,
and reading data from, redis compared to gaining root access and reading
arbitrary memory on the server.

> So are you arguing that your complaint is petty or isn't? Because this isn't
> helping your case.

You make a good point - even if it's not the one you were trying to make - and
that it's that my benchmark was not particularly helpful as it measured per
operation, not per hash.

You missed the point I was really trying to make, though, which is that
difference between 5 rounds and 15 (your choice, not mine - I probably
wouldn't choose 15) isn't that significant when you're doing legitimate stuff,
like hashing chatroom passwords. It is significant if you're brute-forcing.

~~~
Someone1234
> The unhashed passwords are not stored in redis.

Never claimed otherwise. They are stored in memory though. They're in the web-
server process, and the process which actually conducts the bcrypt hashing.

> What I think you're missing is that there's a significant difficulty gap
> between connecting to, and reading data from, redis compared to gaining root
> access and reading arbitrary memory on the server.

You don't need to read arbitrary memory on the server, you only need to be in
the same scope as the web app runs in.

> It is significant if you're brute-forcing.

If you're in a position to steal the bcrypt-ed passwords in this case, you're
in a position to steal the plain text passwords (both in memory, both in the
same scope, why waste time breaking bcrypt?).

If the author altered the code so it DID store on the file system medium to
long term, sure, it might be worth while increasing bcrypt's rounds. In the
mean time bcrypt is almost pointless in this case as plain text exists in the
same execution scope and is accessible to processes with access to Redis.

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

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

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

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

------
attilak
Nice idea, sadly only as secure as https.

~~~
eliaskg
As all clients need a password to enter a room, the messages could be
encrypted with that password. There are a lot of JS libraries that could do
this, e.g. Triplesec

~~~
knadh
Author here. Right now, it's only as secure as https, but I'll look into JS
encryption. It's just a fun project that came out of some Go experiments.

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

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

~~~
rakoo
[https://webpg.org/](https://webpg.org/)

------
untilHellbanned
This is an awesome service. Thanks for making it available to everyone. Can I
ask what the use case is for this? I talk to my friends using FB messenger or
Google chat and my customers using a chat widget on our site, so I'm curious
when I would use this.

~~~
knadh
Thanks! Use cases could be, quick private convo. at a workplace, taking a
discussion on a public forum private (like HN or Reddit), talking to strangers
(eg: Craigslist) without adding them to your FB or Google Talk, exchanging
secrets with your friends without leaving logs on your Google talk etc. :)

~~~
gnoupi
The problem with taking a discussion from a public forum private, is that in
the current state, everyone can choose to dispose of the room.

As proven in this very thread, it doesn't really work. The idea that everyone
can dispose of the room is interesting, but there probably should be an option
so that only the creator (or the first to join) can dispose of the room, for
such public place cases.

~~~
knadh
It's actually meant for small group of people to have private conversations
and is not really ideal for take a huge public discussion private. The idea of
marking a peer the creator or making the first peer an owner complicates the
whole privacy and security aspect.

~~~
gillianseed
Perhaps an option where a majority of users (if more than two) need to opt for
deleting the room ?

------
sgt
To make it even more instant (in terms of UX), I would display the message
immediately so you don't get the little delay. From where I'm at, it's about
250 milliseconds from the point I hit ENTER to when I see the text displayed.

~~~
knadh
Author here. This is how it was meant to be but I somehow overlooked it.
Thanks, will implement.

------
kichuku
I have opened a room.
[https://niltalk.com/r/8CKyw](https://niltalk.com/r/8CKyw) I am not going to
tell the password though. Let's see how long it lasts!

------
panamafrank
first off... this is great! I wonder if you could make it so when you create a
room, you can attach a message.

So for instance i could generate a password then sign it with my partners
public key then paste that in the message box so theoretically only they could
get access to the channel.

and and, create rooms that are meant for someone, so their public key is the
index and their private key decrypts the message to get the password into the
channel.

~~~
knadh
Thanks :)

Public key encryption is definitely a good idea and could be an optional
feature for an upcoming version.

------
janoelze
hn chat time!

[https://niltalk.com/r/bfT9W](https://niltalk.com/r/bfT9W), hn-923732

~~~
gnoupi
Disposing of the room does remove it and kick everyone out, indeed. And then
the link is invalid. Neat. According for the privacy page, it's all living in
RAM only, so in theory there is no logging
([https://niltalk.com/pages/privacy](https://niltalk.com/pages/privacy)).
Guess we can check the code and see for ourselves, of course.

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

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

~~~
akerl_
[http://www.daemonology.net/blog/2012-01-19-playing-
chicken-w...](http://www.daemonology.net/blog/2012-01-19-playing-chicken-with-
cat-jpg.html)

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.

------
paulspringett
Really interesting to read through the source code and get an idea of how
you're using Go to write APIs, thanks for sharing!

~~~
knadh
Deciding on a pattern on writing http APIs in Go was a bit of chore. Ended up
using the `pat` library for chaining middleware. Quite extensible and light
weight. Also, using context to pass objects through the requests chain is a
neat trick.

------
pinjiz
This site uses insecure 1024 bit Diffie-Hellman parameters for Diffie-Hellman
key exchange! Please fix!

~~~
pinjiz
Why was this comment downvoted? The NSA has built custom hardware to crack
1024 bit DH in a few days[1], so the site owner really should regenerate the
DH parameters and use 2048 bits.

It would also be nice to disable 3DES ciphers and only allow ciphers with
forward secrecy.

[1] [http://blog.erratasec.com/2013/09/tor-is-still-
dhe-1024-nsa-...](http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-
crackable.html#.UipD1z9Bx8E)

------
arfliw
[https://niltalk.com/r/h8XLk](https://niltalk.com/r/h8XLk) pw hnchat

don't delete the room! lol

edit: this doesn't work on a public forum. some asshole always deletes it.

~~~
neals
Aaaaand it's gone

~~~
sgt
Let's keep this one open:
[https://niltalk.com/r/PEiMn](https://niltalk.com/r/PEiMn) hnhnhn

The honor and glory of Hacker News users will keep this from being closed.

~~~
fiatjaf
gone.

------
harel
I'm curious to see if this takes off, how long before the powers-that-be start
to say something.

~~~
icebraining
If the powers-that-be are annoyed, they'll just require the Niltalk operators
to log the messages. It's not like they're encrypted end-to-end.

