I have written some thoughts I had regarding Cryptocat. Apparently, they were wrong. I leave this post here (to my shame) because some places link here and some people have commented here, but It’s no longer relevant.
Cryptocat started as a minimum-moving-parts solution for end-to-end encrypted chat. AFAIK, it’s as far as anyone ever got in the field of client-side Javascript crypto. Turns out this isn’t far enough. According to their announcement, they’ll soon become a browser extention, and will essentially be an XMPP client.
Do we need yet another XMPP client? Is there an advantage of it being a browser plugin and not a standalone app like Jitsi, Pidgin, etc.? Maybe (if it’s something I can remotely teach my mum how to install, it already beats existing clients 🙂 ). The important issue is how this decision should affect developers of other end-user apps that require crypto.
The illusion of browser side crypto
One mistake many people do (and I’ve been there too) is to try to write crypto code as browser-side JavaScript. This was always wrong for various reasons, but now it’s “official” (from the cat’s mouth):
- You can’t do serious crypto in pure client-site Javascript (nobody went down this road as far as Cryptocat, and they gave up).
- Browser extensions may provide a way to overcome this problem.
IMHO, Cryptocat 2, as an an app-specific browser extension (secure xmpp chat), is proof of concept for something much bigger.
Browser extention as a de-facto standard
Does this mean that every app that needs crypto should now be developed as yet-another browser extension? Hell no. We don’t want our browser to carry dozens of different implementations of the same crypto code, each with its own bugs and vulnerabilities (multiply that by the number of browsers to support, and then consider all browsers that stay unsupported). What we need is general-purpose crypto support developed once (per browser).
IMHO, instead of waiting for browser vendors to define html/js crypto primitives (so that MSIE can implement them wrong ;)), we can already start experimenting with a browser extension that:
- Exposes a Javascript API with primitives like encrypt, sign etc.
- Does the actual work as a standalone system, no shared memory/resources with the browser, and a GUI that is distinctively “non-browser”. For example: when there’s a “sign” API call, the user should to see what he/she signs, in a separate non-browser interface (no way to let you sign a bill with an extra zero – cropped with “overflow:hidden” trickery).
- Uses a standard (i.e. constantly peer-reviewed) crypto library (openssl, bouncycastle, m2crypto, etc.).
I’m not saying that creating such a component (or even defining its functionality) is an easy task. I know that the strongest crypto library can still be embedded in a way that introduces vulnerabilities. Still, the fact that we can do this as an extension for one or two browsers (without trying to get consensus from browser vendors) makes the goal very hard to achieve instead of virtually impossible, and that’s infinitely better.
Such a project should come from (or at least be monitored by) the crypto community. The only thing an “outsider” like me can do about it is write this post.
So there 🙂
“Hey Rocky, watch me pull a cryptographic API with a broadly accepted trust model out of my hat!”
“Bullwinkle, that trick never works”
“This time, fer sure!”
By comparison: the Solaris Cryptographic Framework (disclosure: I used to work for Sun and an ex-colleague/friend was lead engineer on it) – see:
http://docs.oracle.com/cd/E19963-01/html/821-1456/scf-10.html
– a generic mechanism for any application ported to Solaris to make near-optimal use of crypto hardware available on-chip; applications in Java really benefit since they are used to calling in Factory constructors and those get to use the Crypto Framework on Solaris.
And what happens? The tinfoil-hat brigade avoid it because (a) it’s Solaris and (b) it might be backdoored by evil green lizards who run the universe.
So yeah, get all the browser manufacturers to expose a common cryptoacceleration API; it might make an 80% solution if you’re lucky and there will still be some idiot wanting it for IE6.
/rant
ps: I presume you’re already aware of http://en.wikipedia.org/wiki/Network_Security_Services and SPNEGO and all that guff?
interFace.sf.net is a cool encrypted messenger, use this instead.
Nobody should use a crypto tool just because someone said “use it” in a comment.
If you said “take a look at it” instead, and people from the crypto cummunity (apparently, not me) decided to check it out (maybe it takes 5 minutes to see it’s no good), it would take a few years until they’d figure out how secure it actually was. By then, I’d probably hear about it 🙂
Hi, I’m the lead developer for Cryptocat.
This is a very misinformed blog post that’s been going around concerning Cryptocat’s development roadmap that I need to address, simply because not only is the post so fundamentally incorrect on its technical assumptions, but it goes around being written in a surprisingly authoritative tone:
The blog post suggests that becoming a local browser app means that Cryptocat no longer uses JavaScript cryptography. This is nonsense: JavaScript is a *language*, and since browser apps/plugins are written in an HTML5 framework, we will still be using JavaScript to implement cryptographic functions. The only thing that has changed is *the method of code delivery.* Cryptocat research, even with this change in code delivery, remains within the purview of JavaScript cryptography research, not abandoning it but improving it by suggesting a different method of code delivery. The articles that the blog post links to attack JS crypto code delivery methods, and we are answering those concerns:
* We have NOT “Abandoned JS crypto” and “officially declared” that JavaScript crypto is “wrong.”
* We have NOT “declared that you cannot do serious crypto in pure JavaScript”
* We HAVE simply changed the method of JS code delivery into a local browser plugin, in order to further advance the security of JS cryptography.
I have absolutely no idea where the author pulled his conclusions from and I’m really surprised as to how certainly he posits them in his blog post.
The author goes on to posit that a browser extension be used in order to provide a standard cryptographic API for browsers. This is redundant for two reasons:
* The W3C is already working on a standard cryptographic API for browsers: http://www.w3.org/2012/webcrypto/ (Cryptocat is part of this working group.)
* There exists a variety of vetted, very well-designed standard libraries for client-side browser crypto, such as http://crypto.stanford.edu/sjcl/ and http://code.google.com/p/crypto-js/.
When writing a blog posts that takes ideas as granted facts, please make sure you know what you’re talking about.
Pingback: Correcting Misinformative Cryptocat Blog Post | Nadim Kobeissi
In reply to Nadim:
1. This is merely a confusion of terms. By “[abandon] JS crypto”, Dod actually means ‘abandon pure JS crypto without browser extensions’. This is implied by the context of the article. It’s clear that he understands that only the method of code delivery has changed. The only thing that he is commenting on is the fact that Cryptocat 2 must be “installed”, just like any other XMPP client, which – and here’s where the matter of emphasis comes in – makes it perhaps more like the existing XMPP clients than a web app. Though, as Dod points out, the browser extension installation processes is significantly more obvious and faster than the process of downloading and installing a new app (and enabling OTR) such that his grandmother may be able to do it.
“According to their announcement, they’ll soon become a browser extention, and will essentially be an XMPP client. Do we need yet another XMPP client? […] Maybe (if it’s something I can remotely teach my mum how to install, it already beats existing clients).”
It is a natural conclusion that if Cryptocat was unable to implement pure client side JS crypto without the need to explicitly install software, then it should be considered impossible until JS crypto is implemented in browsers, either via a plugin or natively.
2. Dod explicitly justifies why JS crypto implemented in a browser extension might be a good idea despite the fact that the W3C is working on a standard: “instead of waiting for browser vendors to define html/js crypto primitives […] we can already start experimenting with a browser extension.” Whether this is actually possible or not, I do not know – I imagine that sandboxing would prevent it – but in principle it’s not a bad idea to implement browser crypto in a plugin in advance of browsers implementing a cryptographic standard.
It seems to me that there is a difference in emphasis with regard to how the user experience has changed. Nadim stresses that ‘merely the method of code delivery has changed’ while Dod stresses that ‘because there is now an installation step, CryptoCat is now just another XMPP client’. My opinion is that the truth lies between these two views. Installing a browser plugin is indeed much easier than downloading an app, so, while it is a shame that this must be done, it is not a terrible compromise.
Dod, I suggest you amend your post to make it more clear what you mean and to prevent people from interpreting it in the way that Nadim did.
Correction: Nadim’s reply that the existing JavaScript crypto libraries are equivalent to what Dod’s theoretical browser crypto extension would provide are entirely accurate. What would be useful is a plugin that magically solves the problem of code delivery, but browsers have already solved that in distributing browser plugins with hashes.
“It is a natural conclusion that if Cryptocat was unable to implement pure client side JS crypto without the need to explicitly install software, then it should be considered impossible until JS crypto is implemented in browsers, either via a plugin or natively.”
Need also to correct this. This is assuming that Dod is claiming that crypto primitives implemented in a plugin or natively solves the code delivery issues. Indeed there is a bit more apparatus than crypto primitives needed to solve this problem and app stores are currently an adequate solution.
Thanks for clearing up the issue of the term “JS crypto”. Indeed, I wasn’t talking about the language, but about the JS framework in browsers (i.e. the stuff inside script tags) that not only has the problem of code delivery but also suffers from a volatile runtime environment.
The problem with my proposed solution (as I’ve learned from various replies) is that it would also need to include user interface (because we don’t want plaintext and such inside the DOM), and it’s hard to anticipate what various apps would require in that area. It’s not enough to show the input field we’re about to encrypt. We need to show the keys we’re encrypting to, and all the related trust calculus (which may be very app specific). If we allow clients of this “crypto provider” to freely define its user interface (e.g. with arbitrary html+js), we open the door to various attacks. If we try to define “anything any app would ever need”, we’ll probably never get there.
Pingback: How Much Security is Enough? | Small World News
Pingback: Technology: How Much Security is Enough? » The Web Basement - On Books, Movies, Politics, and Other Stuff