Thursday, July 31, 2014

JS crypto goto fail?

tldr; A long, passionate discussion about JS crypto. Use slides for an overview.

Javascript cryptography is on the rise. What used to be a rich source of vulnerabilities and regarded as "not a serious research area", suddenly becomes used by many. Over the last few years, there was a serious effort to develop libraries implementing cryptographic primitives and protocols in JS. So now we have at least:
On top of that, there's a lot of fresh, new user-facing applications (, miniLock to name just the fancy ones on .io domains).  JS crypto is used in websites, browser extensions, and server side-applications - whether we like it or not. It is time to look again at the challenges and limits of crunching secret numbers in Javascript.


Let me give you a quick summary of JS crypto debate:

In 2009 Thomas Ptacek of Matasano announced that JS crypto is considered harmful, Nate Lawson stated a similar thing. In short, they mentioned the following problems:
  • Web is based on a client-server model. The server supplies the Javascript code, so it can backdoor it as well. You need to trust the server any time you visit a website. Plus, you need TLS to protect the code to from tampering by third parties. And, since you already have a secure channel, JS crypto is pointless.
  • XSSOMFG (and DOM is a mess). Code injections are common. JS crypto is as insecure as JS itself.
  • There's no CSPRNG, no bytes, no mlock(), no BigNums and no good libraries to use. JS crypto is hard, because the language does not help you.
For years, these two articles dominated the views on the subject. Meanwhile, the world evolved - we've seen browser extensions written in JS, nodejs came along, WebCrypto was born and CSP arrived. Some of the arguments got simply outdated. Someone was wrong on the internet.

Last year the discussion started again. Tony Arcieri noted that in-browser crypto is dangerous mostly because the code can be backdoored by the server/attacker at anytime. Web is an ephemeral environment. He noted that browser extensions can solve this problem, as these behave more like a installable, auditable desktop applications. Brendan McMillion made a great post, noticing that Thomas simplified his arguments and did not specify the threat model (in short - security is not a bit value. You're not secure period, you're secure against an attacker with certain capabilities). 
Thai Duong admitted that JS crypto is hard, but doable. He provided some tips on how to overcome JS quirks, and noted examples when JS crypto is better than server-side approaches. He also dropped a super-cool vuln, but that went unnoticed.

Here's where I jump in.

Looking at the code

I have the unique opportunity to both participate in the (sometimes theoretical) discussions and deal with code of crypto applications written in JS. I took part in audits of several of them, and now I even develop one too. So I asked myself a few questions:
  • What are the real challenges of JS crypto applications? 
  • What vulnerabilities are actually discovered, what are their root causes? 
  • Should we really worry about the issues raised a few years ago?
  • What level of security can be achieved? Who can we be secure against?
  • Can the JS crypto be somehow compared to "native" crypto?
The answers to all these are in these slides, but let me expand a bit about some key points.

It's all the same

Vulnerabilities in cryptographic code written in Javascript occur because of two reasons:
  1. Javascript as a language is weird sometimes
  2. Web platform is really inconvenient for cryptographic operations
To give you an example of language quirks, you can still trigger weird behaviour in a lot of JS libraries by using Unicode characters, because JS developers use String.fromCharCode() assuming it returns 0-255. Weak typing often causes vulnerable code too. 

XSS is an example of a web platform issue that breaks cryptographic code completely. Lack of good CSPRNG (and relying on Math.random() ) is a web platform issue as well.

Surprisingly, similar problems are present in native crypto applications, and these also result in spectacular vulnerabilities. For example, sometimes the language gives you poor support for reporting error conditions and you end up having a certificate validation bypass. Or out-of-bound read is possible and Heartbleed happens. You might also kill your entropy like Debian did years ago. Skilful attacker might upgrade a buffer overflow in your beloved crypto library into RCE vulnerability, which is an equivalent of XSS in web security.  

On both sides of the fence we face all the same issues, we're just not used to look at them this way.

Use extensions only

In-website cryptography is doomed.  Let me repeat - don't implement cryptography on any document which location starts with http.  It's a trust problem, well understood and it's a dead end.

The only sane model for JS crypto is a server-side application or a browser extension. As a bonus, for these environments XSS is much easier to tackle as you can control your inputs more easily and sometimes the platform helps you as well (e.g. obligatory CSP for Chrome Extensions). In practice, XSS in your crypto application can be a marginal, manageable problem, and not a fundamental issue.

It's all fun and games...

Once we established a ground rule of only supplying code in an installable browser extension, it's time to dig deeper.  Are browser extensions secure

We can only be secure in a given threat model, so let's look at our potential adversariesWe solved XSS (which any kid could exploit) and we solved server trust issues. Unlike websites, extensions need to be installed, so you only need to trust the server once, not every time you run the code. By doing this we're secure against man-in-the-middle attackers backdooring the code (or the service owner being pressured to "enhance" the code later on). At a glance, it looks like we achieved the level of security of native crypto applications. Yay!

Until someone gets hurt.


Not so fast. For once,  browser extensions autoupdate. Silently. So the only way to trust the extension is to review it and install it manually (i.e. outside extension marketplace).

But - is this a problem unique to web? Most desktop systems autoupdate software packages nowadays, and the updates are being pushed aggressively (and for a good reason!). That includes your precious OpenSSL too. 


Timing is another open problem. It's most likely impossible to guarantee constant-time execution in a modern JS compiler. Even when your code is a perfect port of a constant-time C routine,  you'll have timing sidechannels in places you wouldn't ever expect, because your JS engine decided at some point it would be a good idea to optimize the loop. The timing difference will be probably non-exploitable, but I've heard that statement falsified so many times, I'd rather not rely on it.

Again, this is something native crypto applications struggle with as well. Timing issues were discovered in GnuTLS,  Java SSE, and OpenSSL to name the few.  When fixing timing leaks, you sometimes even need to worry about CPU microcode

Memory safety

Memory safety issues can bite you as well. Whaaat? We don't have buffer overflows in JS, right? Well, your Javascript code cannot introduce a buffer overflow, but the underlying JS engine implementation, and the browser with its HTML parser do have vulnerabilities too. Browsers get pwnd, you know, and your precious crypto extension can be pwned with them. All you need is to do is visit a website that triggers the exploit code. Luckily, here we assume a much more skilful (or rich) attacker, so you might just get away with claiming it's outside your threat model

Host security

Arguing that implementing crypto in a browser extension is insecure because a browser might get pwned, is similar to pointing out the insecurity of OpenSSL because kernel exploits exist. Host security is still essential. Any binary you run can just read your precious ~./ssh/id_rsa and it's working-as-intended. What changed with JS is that now the attack surface is much greater, because:
  • The browser is now your OS, and origins are just different users in this OS.
  • Everyone in the world can execute a program on your OS. To put it boldly, web platform is just a gigantic drive-by-download marketplace. Visiting a page is equivalent to
    wget http://kittenz; tar; ./configure; make; ./dist/kittenz
Assuming the adversaries are powerful enough, some of those kittenz might bite your code badly.

But then again, are browser exploits that much easier to buy/develop than any other popular software and/or kernel exploits? Because these would have no problems with circumventing native crypto applications. After all, GnuPG was thwarted by a simple keylogger.

JS crypto is not doomed. We made some real progress in the last few years, and will continue to do so. It's just that when facing some classes of attackers you're defenceless and we all need to understand that. 


  1. If you're going to make it a separately installable tool, why even write in JavaScript? The reasons are a lot less compelling to even use JS in that case. Basically, as JavaScript migrates away from the HTTP protocol, the security issues that made it notorious disappear, which should be no surprise to anyone, since it was never the language itself that was really the problem.

  2. Because currently, at least for desktops, the browser engine is the most popular code and execution platform. You're no longer running code in a JVM (via Java applets), you don't install applications. You just click and just have a browser extension.

    Also, e.g. when crypto primitive libraries are written in JS, you get portability pretty cheaply. You can easily launch an application for mobile platforms, browsers, smart TVs and whatnot. JS becomes the new C.

  3. Hello!

    It's great to see how these last months people seem to evolve and leave behind the idea that JS crypto is a waste of time. I think that JS crypto is key for the future.

    I don't buy the idea that server-side crypto is to be equally trusted that JS crypto in websites. I mean, of course JS crypto can be tampered, being that because of a XSS or because the server is modifying the code. But, eventually, with JS crypto you will have access to that code, tampered or not!!
    I can't believe that people put that situation in the same level as not having a fucking clue about what crypto code is doing in server-side (or if it even exists...). ¿Hello...?

    On the other hand, what about creating a browser extension that tracks JS crypto modifications for each website you visit. In which you can set what code is trusted and what code is not. We can argue that only a few people would be able to check if modifications are malicious, but at least web programmers will have to justify their changes in cryto libraries and you'll be notified if some kind of tampering/modification is done.

    It's been years since I see that JS crypto is a key concept, but during all this time people more knowledgeable than me have stated that it is (and will be) completely broken. I've never fully understood it. Yes if there's a XSS in the website you are screwed, but man... you are supposing that the website has already been hacked! Do we stop trusting server-side crypto because the server might be hacked?

    Hope you can share your thoughts.

    BTW, great post! It's awesome to see people working on this.

  4. Kindly,

  5. thanks >>>>>>> good post

  6. tnq so much kotowicz , information that is very valuable to me ! good luck and verygood website دانلود فیلتر شکن

  7. thank you for good information


  9. Its very nice post .... thanks

  10. دربهای اتوماتیک دیجی در درب اتوماتیک پارکینگ | خبرهای اقتصادي جهان ، جدید ترین خبر اقتصاد روز، ، اخباراقتصاد ، خرین اخبار اقتصادی سایت ها و روزنامه های ایران و جهان،اخبار دنیای اقتصاد امروز رتبه جهاني ايران را در شاخص اﻗﺘﺼﺎد پيچيدگي اقتصادي سایتی برای خواندن عناوین اخبار روزنامه جهان اقتصاد در روز دورنمای اقتصادی جهانی اخبار اقتصادی جهان خبرهای اقتصادي جهان ، جدید ترین خبر اقتصاد روز، ، اخباراقتصاد ، خرین اخبار اقتصادی سایت ها و روزنامه های ایران و جهان،اخبار دنیای اقتصاد امروز | لیست قیمت و تخفیفات حجمی سفارش ترجمه زبان انگلیسی به فارسی: .... در صورتی که سفارش ترجمه متن مورد نظر شما جزء متون تخصصی رشته ادبیات و زبان شناسی مترجم فوری ترجمه تخصصی لیست قیمت و تخفیفات حجمی سفارش ترجمه زبان انگلیسی به فارسی: .... در صورتی که سفارش ترجمه متن مورد نظر شما جزء متون تخصصی رشته ادبیات و زبان شناسی |


  11. شركة تسليك مجارى بالمدينة المنورة

    شركة كشف تسربات بالمدينة المنورة

    شركة مكافحة حشرات بالمدينة المنورة

    شركة تسليك مجارى بالدمام

    رش مبيدات بالدمام

    شركة مكافحة حشرات بالمدينة المنورة

    شركة كشف تسربات بالدمام

    شركة كشف تسربات بجدة

    شركة دهانات بالرياض

    كشف تسربات بالرياض

    شركة كشف تسربات بالقصيم

    شركة تسليك مجارى بابها وخميس مشيط

    رش مبيدات بابها

    شركة كشف تسربات بالدمام

    شركة نقل اثاث بالمدينة المنورة

    شركة كشف تسربات فارس

    رش مبيدات فارس

    اكبر شركة مقاولات بمنطقة عسير

    تنظيف منازل بالطائف

    شركة تسليك مجارى بالمدينة المنورة

    شركة نقل اثاث بالمدينة المنورة

    شركة كشف تسربات بالمدينة المنورة

    شركة تسليك مجارى بجدة

    شركة نظافة عامة بجدة

    شركة نقل اثاث بجدة

    شركة كشف تسربات بجدة

    شركة تسليك مجارى بالدمام

    شركة تنظيف مسابح بالدمام

    شركة تنظيف موكيت بالدمام

    شركة مكافحة حشرات بالدمام

    شركة كشف تسربات بالدمام

    شركة نظافة عامة بالدمام

    شركة نقل اثاث بالدمام

    شركة تسليك مجارى بالرياض

    تخزين اثاث بالرياض

    كشف تسربات بالرياض

    مكافحة حشرات بالرياض

    نقل اثاث بالرياض

    تنظيف بخميس مشيط

    تنظيف بالطائف

    رش مبيدات بجازان

    تسليك مجارى بجازان

    شركة مكافحة حشرات بجدة

    نظافة بالجوف

  12. cleaning is something important in the life of every human being, it is something essential in our lives and we can not live without them even live safely
    without the disease nor any pandemic interest in them something necessary and important, the clean types in terms of roads and style and how to implement the outcome
    and the reasons that lead to it and other .....
    شركة تنظيف بالطائف
    شركة تنظيف منازل بالطائف
    شركة تنظيف خزانات بالطائف
    To learn about some of the tasks in which we perform the task to get rid of any distress and any pollutant that can harm us in general. We talk first about hygiene cleaning anything roads is
    important and necessary, we always go out on the streets and wander so that we can spend a purpose and also the exi
    Cleanliness of the houses is the most important things for us Each of us can not live in a house with distress or pollution, because this causes damage to us you will be always puzzled in
    selecting a company
    Cleaning company in Khamis Mushayt, we are located in the city of Khamis and get to you upon request has good reputation in this place, as well as our people carried out many acts of
    home maintenance and the result was good and the work to be thankful for. We put all our efforts for the benefit of our company and maintain its work and make plans in various fields,
    and when we talk Ali equipment ubiquitous in the company, we always we update any renewal of our equipment at different intervals to keep on our work and give a good result and also always
    look forward to modern methods of doing our work to connect us, you will just have to click on the link below to get the most information about us:
    شركة تنظيف بالقطيف
    شركة تنظيف منازل بالقطيف