A few more thoughts on why WebCrypto isn’t such a bad idea:

I enjoyed Thai Duong’s defense of JavaScript crypto in the context of building E2E here:  http://vnhacker.blogspot.com.ar/2014/06/why-javascript-crypto-is-useful.html , but wanted to add one more quick thought.  WebCrypto is just a continuation of the same general ideas that we’ve followed for years to make lower-level platform crypto safer and better; in particular two megatrends:

1. Abstract the crypto implementation away from the program.

Yes, JavaScript is bad at things like guaranteeing constant-time program semantics, strong typing, etc.  Many lower-level languages that use crypto have similar issues, even C code can, and often does.  By depending on an abstract, platform-provided interface instead of an application library, these operations can be transparently routed to the best-available implementation.  That might be a C library in the browser, one that ships with the OS, or it might be an HSM or specialized CPU instructions.  Without these kinds of API abstractions, there’s no way a browser-hosted JS app can possibly access these safer lower-level services.  This pattern also means the end-user of the application can make their own choices about the implementations that meet their requirements without requiring changes in the application.

2. Trust the platform.  You have no choice.  Really.

Sometimes you will find a situation where platform crypto is broken yet an app with its own implementation can be safe. But this is very rare.  Applications are pretty dependent on their platform for security, even if not in ways directly related to the functionality of the app.  A modern platform (whether it is a browser or a traditional OS) uses crypto primitives for things like establishing secure channels, verifying software and updates, authenticating administrative users over the network, etc.  If your adversary is able to exploit weaknesses in your platform crypto, you probably can’t build an application on it that will resist those adversaries just by including your own crypto libraries.  

Also, with a very few notable exceptions (hi, Chrome!), the vast majority applications just don’t have the same incentive and ability to keep crypto dependencies up-to-date that platforms do. In practice, apps that ship with their own crypto dependencies ship with out-of-date libraries that are full of vulnerabilities.* It’s much better to accept as a simplifying assumption that you can’t do better than the platform you run on, and rely on it to keep crypto safe, and the dependencies up to date for you.  

* I worked auditing application security for over five years and it was a given that you’d get some “freebie” critical findings in the first hour of any engagement if an app wasn’t using platform crypto because that meant there was a version of OpenSSL or a Java XMLDSIG library somewhere in the build path that was usually no less than 4 years old. Even apps that themselves were brand-new somehow managed to find the crustiest possible crypto code to include, I don't know where from.
Shared publiclyView activity