Show HN: Cyph – Encrypted chat in 30 seconds

-The JS crypto can be trivially MiTMed. Your approach of checksumming the JS you outlined in another comment using external servers is laughably terrible

-The OTR is pointless. The keys aren't being verified so, again anyone could MiTM the key exchange and trivially intercept messages, even if there was no JS. This is the main point of the app, and it's completely broken.

-The entire application is relying on the security of the TLS PKI, which is horribly, horribly broken. This opens it up to attack by a huge number of people.

-It's being run on a shared server, with access to the keys by the real owners. Not to mention VM memory-leaking attacks by other residents, etc. Having your entire application logic hosted online and delivered to your users every time they access the service has security ramifications, whether you'd like to believe it or not.

So basically what YOU'RE saying is trusting 1 developer and trusting millions of people is the same because at some point you cannot verify every bit in the executable. Using browser crypto is worse than executables for the same reason PFS is better than non-PFS, you can't retro-actively hack or MiTM something. If both parties already have the executables stored locally (or delivered securely by an offline medium like USB stick and verified) the only way to intercept the data is compromise both end-points.

TL;DR your hyperbolic "trust as slippery slope" argument is dumb

I like the "test from a variety of hosts" approach better, and I wonder what kinds of tools exist or will exist that will facilitate this -- and whether some web app developers are willing to commit that their architectures will support it (that the front-end code doesn't do an eval, that the front-end actually architecturally treats the back-end as untrusted, and that users can expect to get consistent page contents every time they visit the service, even with a different user-agent or from a different netblock). I'm not trying to make fun; I want to see this happen. It seems like a big change from existing practice!

>And questioning the security of TLS?

No, I'm questioning the TLS PKI which is what this is dependant on, please learn the difference. Currently any CA or anyone who hacks a CA will be able to make a fake cert, which has happened many many times. Everyone from Bruche Schneier and Moxie Marlinspike condemn the CA PKI, in fact according to Schneier it will cost only ~$700,000 by 2015 to make a SHA-1 collision and produce a fake certificate without any hacking at all. This is why real security solutions use pinned certificates.

Blindly putting your faith in SSL/TLS to accomplish all your goals is really, really dumb. There have been several MAJOR (CRIME, BREACH, POODLE, Heartbleed, CCS) attacks against it in the last 3 years alone.

>You're going to need to do more than just call something "laughably terrible"

There's a reason no one else does this, because it's insecure and unsustainable. Someone could just detect your monitoring servers requests and serve it a 'good' version. Or better yet, only serve a 'bad' version to the people it wants to target. Or just DDoS your monitoring server. If they have the capabilities to intercept the TLS requests to Cyph then what's stopping them from intercepting the requests to your extrnal server? I think what you fail to understand is the interception would probably be client-side, not server-side. Not to mention every time your code actually changes you have to go manually verify that it's correct and not an attack. You're essentially hand-rolling your own signature scheme based on extremely shaky ground. You're going to need to do more than just conjuring up your own amateur solutions and dismissing all security concerns out of hand because "doesn't have to be perfect".

>There is a spectrum between "totally secure" and "usable by normal people". Your refusal to acknowledge this spectrum is asinine and attacking me for mentioning it is uncalled for.

Where did I do that exactly? You're also implying something can either be secure or useable. I acknowledged there is a spectrum of security, like I said earlier this is marginally better than talking over Facebook. In fact Facebook might be a little more secure because it has a dedicated security team that monitors intrusions. Ignoring the JS problems and the hosting problems, the end-to-end crypto doesn't verify keys, which makes it useless. It's like using a self-signed cert for your message encryption. If that's your line in the sand for "secure enough" than go right ahead and use this, but marketing it as private is irresponsible and deceptive.

>With all of the security holes in Windows, TLS, OpenSSL, SSH and in practically every other day-to-day usage of crypto... yet somehow people can still safely and securely do all sorts of things

Yes, because they were lucky or oblivious to the fact they got owned. This is like saying "I leave my car doors unlocked all the time and it hasn't been stolen yet"

>Maybe you're the NSA. Maybe you want to come across as an all-knowing crypto guru and charge obscene hourly rates to companies who you've scared shitless. Maybe you're just a troll armed with the same tired old arguments I've been hearing for years. Who knows. Again, you're using a brand new account. No one knows who you are or what your agenda is.

Ad hominem mixed with a little tinfoil, I like it. Maybe you and Cyph are the NSA and are in collaboration to promote broken crypto to the masses? Or does the fact that you self-aggrandize by using your real name on HN make you legitimate? Maybe you're a design-centric know-nothing who thinks that WebCrypto means "insta presto! the cloud is secure now! web 4.0 everything because 'it just works'" ?

I just deployed a fix that I think is actually pretty clever (haven't seen anything similar done anywhere else, anyway). Rather than intruding on the existing UX, I'm just automatically generating a shared secret on the first client and putting it in a fragment at the end of the generated URL, which is then used by both clients for SMP. So now, to successfully mitm a Cyph chat server-side an attacker would have to have compromised both our server and the users' SMS/email/etc., and even then they'd still have a pretty small window of time in which to execute their malicious code on the Cyph backend.

It's not strictly foolproof, but it's still a hell of a lot better than leaving unauthenticated as the default. Combined with the two-factor auth feature we're rolling out in a few weeks, this should put us in a pretty good state. The only (mildly) inconvenient thing about this solution is that it precludes us from adding buttons to automatically text/email the link to your friend for you (since that would involve passing the secret to our server).

re: checksumming, the plan is to do it client-side, not server-side (I could have misread/misskimmed but it sounded like you were mistaken on this), and have the user manually agree before applying any updates to local appcache. The idea is essentially to cram a traditional release cycle into the Web, with a stable channel with biweekly formally audited known good payloads. Still need to prototype this and see if it's feasible, but on paper it sounds good to me.