upperechelon

11 lat temudiscuss

Yeah but no user is ever going to be able to remember either of those passwords, even the website encourages people to write it down. So when the FBI raids Johnny's house and they find his post-it note next to his computer he's gonna be in a lot of trouble. And before you mention password management applications... that would also be a solution for the 'users pick bad passwords' problem

upperechelon

11 lat temudiscuss

Sooo what happens when whiteout gets an NSL and suddenly the "we don't store the keycode on our server.... trust us" mantra gets thrown out the window? Why invent your own authentication protocol with AES-256-GCM when this seems like a clear-cut case for TLS? Why use PBKDF2 over Scrypt?

upperechelon

11 lat temudiscuss

The main crux of this whole post is that PGP is still good it's just that it's hard to use and there's no mobile support. Unfortunately for whiteout, there are many different mobile PGP implementations that do everything these guys are planning to (like automatic key lookup) that already exist today. Notably among them K9 + OpenKeychain, which already support keybase.io and HKPS.

People who say that security is meant to be hard are missing the point, OTR has been around for a long time and is not only much more secure than PGP but more useable. If you want truly secure asynchronous messaging you should checkout Pond by Adam Langley, which is arguably the only traffic analysis and metadata resistant messaging protocol on the planet. Unfortunately PGP has been designed in a way that careful key management is pretty much a requirement if you want. PGP key verification is extremely painful on every implementation I've ever seen, and unless you do it you are vulnerable to extremely potent attacks which are the result of plaintext key sharing algorithms like HKP and LDAP.

I'm with moxie on this one, I get sad that people are still trying to build modern 'secure' architecture based on a ~20 year old cryptosystem. It sets everyone who cares about useable security back because you are continually encouraging people to cling on to the old paradigm. Unfortunately there is no clear, universal successor to the PGP kingdom... yet.

upperechelon

12 lat temudiscuss

I find it hilarious you're still fixated on the idea of the trust chain and haven't addressed any of my actual points about the crypto, besides making a lot of hand-waving and saying "well it's not secure, BUT NOTHING'S SECURE SO THAT MEANS IT'S GOOD ENOUGH". This is not end-to-end, the OTR is broken and doesn't verify keys, end of discussion. The JS can be MiTMed, end of discussion.

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

upperechelon

12 lat temudiscuss

Actually that's not what I'm saying at all. I'm critiquing the implementation of this for several reasons:

-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

upperechelon

12 lat temudiscuss

4) So they can redirect all users to a non-HTTPS site. That's interesting.

What youre saying is ridiculous, it's nothing to do with "completely" trustless, you're not trustworthy at all. The "we promise we wont serve malicious code" is the same securi

Basically your users have to trust: -You -Your staff -Cloudflare -Google -Any computer used to design, build or login to your web app -Anyone with access to any of these computers -Every single CA in existence (including the US and Chinese government) -Anyone with resources to spoof a CA SHA-1 signature (anyone with ~$700,000 [0]) -The authors of the JS OTR library and any other code you use

Do you see the problem here? There are literally millions of people in your trust chain.

Libpurple sucks, but browsers are the #1 target for exploit writers, not to mention the HUGE attack surface they pose. There are just so many angles of attack for your service. Anything hosted on a shared server is not secure. The word cloud and security should not be in the same sentence. No offense, but you guys really do not seem like cryptography experts and there are so many pitfalls here that I would not recommend trying to promote this until you completely re-design everything.

As far as WebCrypto.. I'm just going to leave this here: http://tonyarcieri.com/whats-wrong-with-webcrypto http://matasano.com/articles/javascript-cryptography/

[0] https://www.schneier.com/blog/archives/2012/10/when_will_we_...

upperechelon

12 lat temudiscuss

1. This is not about being perfect, this is about being trustworthy or secure. Right now this is very dangerous to be promoting as even remotely private, as you claim on both your website and twitter. This is no more secure than chatting over facebook. There is no 'clever solution' to get around crypto in the browser, it's always bad.

2. There is absolutely no point to using end-to-end crypto in this setup because it can all be intercepted. Not to mention there is no key verification, so even if you're JS wasn't interceptable it's still trivial to intercept messages. It's a red herring at best and at worst deceptive .

3. I stand corrected, although JS (regardless of whether it's in the browser or not) is usually considered terrible for crypto implementations because of it's math bugs.

4. You might want to check yourself, https://www.ssllabs.com/ssltest/analyze.html?d=www.cyph.com&... you're pointed to cloudflare's SNI server.

I think what you fail to understand is you're relying entirely on TLS for all of your security, which means a LOT of different people are able to read these messages. It's not just your CA that could be compromised to hack you, its ANY CA. So for example the chinese government decides they want to read everyone's messages, all they need to do is publish a cert with your domain. Or any of your staff. Or anyone at cloudflare. Or anyone with access to your server. Or access to your home computers which have login credentials.

upperechelon

12 lat temudiscuss

Yeah... this is a really dangerous and fundamentally flawed idea. Anyone with a basic grasp of cryptography will realize how obviously broken this is:

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.

comments