Or would you prefer to parrot the same tired old arguments that pop up on the HN comments every time the concepts "web browser" and "cryptography" are used together?
Unless people are downloading from source, verifying signed checksums, and building their crypto applications from source they are just as susceptible to any of the issues that browser crypto is.
Prebuilt executable? Can't be trusted. A modified version could have been substituted at download time for a particular user.
Web site where signed checksums are published? Can't be trusted. It could have been hacked or altered.
Checksum embedded in executable which checks itself at run time? Can't be done.
Trust is the issue. Trust NEVER goes away. The only way to know for sure is if you compile all your own code. But wait, remember Ken Thompson on Trusting Trust? You had better be building your own compilers as well...
So basically you're saying that no one but computer experts who build their entire toolchain from scratch should be using any sort of application that uses cryptography.
(Along with Mike Perry from the Tor Project, I gave a talk about some of these issues at Mozilla recently, which was pretty well-received. Tor has been very interested in making sure that compromises of their infrastructure won't compromise the software their users get, and that the developers can't be coerced into giving users backdoored versions; see Perry's "Deterministic Builds Part One: Cyberwar and Global Compromise", for example.)
To look at this from another angle, all of these issues are terrible gaps in software security, and terribly exciting opportunities for people to add backdoors (maybe more likely bugdoors), but now we have some tools and ideas that can start to address them!
Can we now stop pretending that browser crypto is the only thing is susceptible to these issues?
-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
Your arguments are just as hyperbolic, BTW. Meeting up in person with USB sticks for software updates? And questioning the security of TLS?
And is JS checksumming more or less laughably terrible than publishing a checksum of an executable on a web site?
And does your JS MiTMed scenario depend on broken TLS?
You're going to need to do more than just call something "laughably terrible".
I'd prefer if you took the conversation about JS checksumming to the specific thread so as to not complicate things.
Software will always have updates and they happen automatically with increasing frequency on consumer computing environments like iOS, Mac and Windows.
BTW, just who are you anyways and why are you so intent on making me look like a fool for attempting to discuss viable web-based cryptography? I see that your user account is brand new.
Why would anyone be pursuing the Web Crypto API? Have you broached these issues with the W3C working groups? Don't you think they'd like to know that their work is futile? Shouldn't some manager on the Chrome team have stopped them from implementing such a pointless protocol?
And no, I don't think "trust as slippery slope" is a stupid argument because we have to deal with that issue every day with every aspect of consumer computing. 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. 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.
Wanna talk about trust? I don't trust you and I don't trust your approach to these arguments. I don't trust your faux-elite sounding hacker nickname. Maybe you or who you work for is threatened by the average person having end-to-end encryption in web applications? Maybe you're a marketer who needs that data. 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... "trust as slippery slope" indeed...
>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'm not and have never defended this specific app. All I'm doing is pointing out that your wholesale dismissal of browser crypto is unwarranted.
You're clearly just trolling me now because you've refused to answer any of my questions specific to the valid use cases of browser crypto and how ANY software that is updated or updates itself is susceptible to issues you've levied at browser crypto.
I've been reading infosec arguments on the net since the 90s. I've heard everything there is about the dangers of creating your own crypto systems and every one of your snide remarks. tptacek has made a career off of the same 15 things you've said over and over and over again. I get it.
I also completely disagree with tptacek and every other dude who outright dismisses browser crypto. I also thing that there are a lot of important benefits from attempting the very difficult task of creating secure browser crypto environments.
Your general approach to the issue is to turn in to a raging asshole and attempt to make anyone who is exploring these issues look like a fool. You engage in an incredible amount of personal attacks and you attempt to justify the means by harping on about the importance of the ends.
I fundamentally disagree that the means can and ever will justify the ends for anything. When you do that what we're left with is assholes like you who make the world of crpyto and security an environment that is incredibly toxic to creativity.
While I have your attention, could you take a look at this: http://substack.net/offline_decentralized_single_sign_on_in_...
BTW, there's enough of us idiots out there that we're not going to stop until we've figured this out! Being able to ship a decentralized version of say Facebook or Twitter that runs in the browser and allows people to manage their own private keys (aka, manage their own digital identity) is incredibly motivating. I don't trust platforms like iOS or Android to not shut down certain kinds of apps and I don't think my mother will ever be running an open-source OS on her tablet.
I have to say that I definitely lost my shit in this thread... and I'm sorry. I have a tendency to get emotional about this kind of stuff because the politics are a big part of what motivates me to build these kinds of things. I take these hard-lined stances against browser javascript as an assault on my principles for digital identity but also as a creative individual who strives for a positive and constructive environment.
That doesn't justify me calling people names. Especially if I'm going to be talking about the means not justifying the ends... ugh...
However, I do think that articles like this are very close to being out of date: http://matasano.com/articles/javascript-cryptography/
The Web Crypto API alleviates a number of these issues and novel uses of application caching manifests seem to solve the issue for good.
Check out this article, especially Gotcha #4. http://alistapart.com/article/application-cache-is-a-doucheb...
So in this case we've got an authoritative article that says "never ever far-future cache the manifest". And we've got an authoritative article that says "never ever do crypto in the browser".
Both articles take a pretty heavy handed approach and don't really set out to explore the deeper possibilities. They both kind of set out to create an environment where readers will also not question these principles for fear of being made look like a fool in front of their peers.
But the fundamental hacker ethos is to read articles like this and say "the intent of the APIs and authors be damned, I have other considerations!".
Anyways, I'd really appreciate your thoughts on this stuff... all of, including what I and a number of other people perceive as a toxic environment for creativity related to cryptography and infosec.
One place I have put my own time in is in teaching people how to do this. This site:
... was preceded by more than a year of individual person-to-person email-based tech support in which thousands of people got several sets through these challenges, and almost a hundred finished.
I have zero sympathy for the people who are unwilling to put that time in, have their feelings hurt when they stumble trying to get their own systems working, and then complain of a "toxic culture" in cryptography. That "toxic culture" takes its place alongside the toxic cultures of nuclear controls system engineering, gastroenterological surgery, and appellate court law.
I have no idea whether this describes you or not, because your comment started out by asking me to look at a technical problem, then attempting to rebut a statement I didn't make, then invoking the fiasco that is the Web Crypto API, before finally complaining about toxic cultures. I don't know where to start, and so I'm hitting the eject button.
What do you think about that appcache solution to controlled updates?
You're convinced that the means justify the ends.
It is my opinion that even in nuclear controls system engineering, gastroenterological surgery, and appellate court law that being positive and supportive of your peers is probably a better approach than however you want to justify having zero sympathy for people.
Also, in my case I happen to be interested in creating something as life-threatening as a product for posting photos of cats to your friends all while having control over your digital identity/keys. I'm interested in the ecosystem of software applications that are based on open platforms and protocols like the web and driven my individual ownership of identities and data. It seems like a fun, liberating, creative and social way to make software!
I'll also hit the eject button because it is clear that you're only interested in conflict.
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.
But I am just a lowely infrastructure guy that builds VPNs, lots of smart folks out there :)