Show HN: Cyph – Encrypted chat in 30 seconds

Show HN: Cyph – Encrypted chat in 30 seconds
cyph.com

As far as the crypto, right now it's just straight OTR (https://arlolra.github.io/otr/), but we have some cooler stuff in the works for non-intrusive non-ephemeral encryption.

I think the way we handle the URL mitigates a lot of potential issues (the design goal there was to make it as resistant to someone brute forcing the address space as possible, within reason):

* It expires after 10 minutes, at which point it's immediately recycled

* It's also immediately recycled the second the other guy connects to the cyph (meaning that, hypothetically, two unrelated pairs of people could be cyphing each other at the same URL)

That isn't perfect on its own, but it's good enough for almost any use case.

That said, in a few weeks we're also rolling out a two-factor auth feature to verify your friend via her phone number or email address, for when you really need to be sure. (We'll flesh this out a bit more later on, e.g. possibly integrating with Google Authenticator.)

(And practically speaking, before building Cyph, Josh and I pretty much avoided having to use encryption except in cases where there was no alternative.)

But I definitely agree that we'll have to come up with a clever solution to this problem. Off the top of my head (haven't thought this through — could be totally stupid), we may be able to do something clever with html5 appcache and notifying users when the hash of the code changes (and giving them the option to stay on their known good version).

Of course, once we have our native app out this issue will be trivial to avoid for people who really need to.

Edit: To clarify, I should correct you on that we are definitely performing the end-to-end encryption from the client — anything else would kinda defeat the purpose of Cyph...

1. It uses JS encryption, which is essentially useless as you could modify it any time to intercept the messages.

2. You claim to be using 'OTR' but there is no key verification, which means it is trivial to intercept. Therefore there is no point at all to using OTR. In addition the point of OTR is to prevent server operators from intercepting communications, which you are still able to do.

3. You've rolled your own crypto library, which hasn't been audited and isn't even known to work correctly or interoperate (i.e: with XMPP OTR clients) with verified implementations.

4. You're using cloudflare which means cloudflare also holds a copy of your TLS key, which means they could also intercept the messages.

If you get hacked, if your TLS key gets broken or if one of your employees wakes up on the wrong side of the bed, it's game over. In a nutshell, this is marginally more secure than logging into facebook or gmail over HTTPS and sending each other. In fact in some aspects it's probably less secure because Facebook or Google have strong security teams to monitor intrusions into their servers.

1 and 2) See https://news.ycombinator.com/item?id=8660233 — acknowledged that it's not perfect or 100% trustless yet, but we have some ideas to address that in the future, and for now it's still better than nothing (which is important in cases where you'd have otherwise used nothing).

3) We haven't rolled our own crypto. We're using the JS OTR implementation recommended by cypherpunks.ca (which hasn't been formally audited as far as I know, but is understood to be pretty good).

4) Not using CloudFlare for SSL or CDN, only for DNS management. Our CA is DigiCert (same CA as Facebook and GitHub) and we're running on Google App Engine; it'd be a pretty big deal if either one of those were hacked.