Re-igniting the Crypto Wars on the Web

Recently, the W3C has released as a First Public Working Draft the Web Cryptography API [1], which defines a number of cryptographic primitives to be deployed across browsers and native Javascript environments. This proposal is moving fast, and will likely be finalized by the end of 2013 and in all major browsers shortly thereafter, as browser vendors Google, Microsoft, Mozilla, and Opera are all on board. As has been discussed in a number of blog-posts [2], cryptography in Javascript on the Web is an unsafe bet at best today (Javascript Crypto O RLY?), although technically the Web Crypto API is a WebIDL that could be bound to programming languages beyond Javascript. Even with excellent implementations such as the Stanford Javascript Crypto Library [3], browsers still do not have basic cryptographic functionality not provided natively by Javascript, such as key storage.

Yet is Javascript cryptography doomed on the Web? Much of the critique of Javascript cryptography boils down to a critique of current Web browsers, and as has been shown by the W3C and browser vendors - the Web Platform can evolve. Due to TLS, almost every web browser and operating system already contains well-verified and reviewed cryptographic algorithms. At its core, the Web Cryptography API will simply expose this functionality to WebApp developers, with a focus on essential features such as cryptographically strong random number generation, constant-time cryptographic primitives, and a secure keystore. Without these functions, Javascript web cryptography would be impossible.

Yet we realize the Web Cryptography API is only a single component in building the emerging Web Security model that is necessary to make the Web part of a trusted environment. For example, one open issue is whether or not applications using the Web Cryptography API also should be required to use Content Security Policy (and attendant work such as HSTS) to prevent XSS attacks [4]. Indeed, should and can browser vendors and the W3C as a whole tackle the malleability of the browser Javascript run-time environment? Furthermore, can we use the Cryptography API to manipulate and check certificates, as is needed by proposals such as the new IETF Certificate Transparency proposal? Without a doubt these security considerations are of utmost importance, and getting them right to enable cryptography on the Web will require holistic thinking about attack surfaces and threat models. There are a number of use-cases, ranging from decentralized identity systems to secure cloud services for activists, will be detailed - including some

One issue with the Web Cryptography API is that the Working Group decided to expose the low-level functionality first rather than aiming only for a high-level API aimed at the developer on the street who may not have a grasp of the finer details of cryptography. The Working Group did this on purpose after taking a survey of users [5], in order to allow experienced developers to build the functionality needed across the largest number of use-cases, but a "high-level" API similar to KeyCzar that makes using cryptography easy for Web developers will also be presented. A second issue is that the current Web Cryptography API exposes legacy cryptographic algorithms that can be used insecurely, which was done in the draft to allow Web Application developers to create applications with interoperability with widely used applications such as GPG, SSH, and the like. A number of thorny issues will be presented, and feedback from the audience will be encouraged.

The questions facing this API are not only technical but political: Is releasing this cryptography in Javascript to developers responsible? Assuming it can even work, Javascript cryptography can be used for both great good and great harm. For example, given the recent proposal for Encrypted Media in HTML5, there is no doubt that there is a desire for enforcing copyright may be on the agenda. After all, the World Web Web Consortium is an industrial standards body! Yet given the current dangerously insecure state of Javascript cryptography and the fact that developers are already re-implementing cryptographic functions in Javascript in programs such as crypto.cat, myself and others at the W3C thought that action should be taken. For also the W3C is led by Tim Berners-Lee, who has publicly expressed support for protests against ACTA and an end to dangerous packet-sniffing bills put forward by governments like the UK. To avoid copyright enforcement via cryptography, should we prevent cryptography from reaching Web applications needed by activists? What does the current attempts to put together a Web Security Model mean in the larger social landscape: Are we seeing a new round of cryptography wars on the Web, and will cryptography be used to protect individuals against the now panoptic data-mining on the Web - and will it help or hinder the move towards a more transparent society?

The entire point of this talk is to get wider input from the hacker community before we set the API in stone by implementing it, as by the next CCC it will be too late, as well as ask the harder questions that technical working groups usually avoid. The talk will be presented by Harry Halpin, W3C staff contact for the Working Group and author of the group charter.