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

81–90 of 99 posts

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

#81

Post by Someone1234 »

jfindley wrote: post #53
gnoupi wrote: post #17

Earlier quoted context omitted.

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

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

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.

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

#82

Post by ParadoxOryx »

thwarted wrote: post #80
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.

Is there a chat system that leverages keybase.io?

IIRC, PGP is not good for instant messaging.

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

#83

Post by bhayden »

knadh wrote: post #49
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).

Author here. This is meant to be something super simple and instantly accessible. Start and finish a conversation in mere seconds if need be with no traces. I am sure downloaded clients with end to end encryptions exist, but it's definitely outside the scope of something as simple as Niltalk.

>no traces

Is a secure platform really worth anything if it's unverifiable as secure? We have no way of knowing there are no traces left.

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

#84

Post by knadh »

paulspringett wrote: post #70

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

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.

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

#85

Post by pinjiz »

pinjiz wrote: post #77

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

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

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

#86

Post by jfindley »

Someone1234 wrote: post #81
jfindley wrote: post #53

Earlier quoted context omitted.

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

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.

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.

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

#88

Post by Someone1234 »

jfindley wrote: post #86
Someone1234 wrote: post #81

Earlier quoted context omitted.

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.

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 36…

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.

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

#89

Post by hurin »

StavrosK wrote: post #71
soft_dev_person wrote: post #68

Earlier quoted context omitted.

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

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

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

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

#90

Post by c22 »

cmdrfred wrote: post #73
new299 wrote: post #56

Earlier quoted context omitted.

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…

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.

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.
Post reply on HN