W3C home > Mailing lists > Public > public-webcrypto@w3.org > October 2012

Draft Blog Post on Cryptography API

From: Harry Halpin <hhalpin@w3.org>
Date: Mon, 08 Oct 2012 19:22:20 +0200
Message-ID: <50730BCC.9060705@w3.org>
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
As promised, here's a draft blog post to respond to some of the 
comments, and I'd like the WG to look at it before publishing on the W3C 
blog. Please feel free to make additions/subtractions/corrections. Note 
the provocative title :)

   -harry

----
Title: Re-igniting the Javscript Cryptography Flame War

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. As 
has been discussed in a number of blog-posts [2], cryptography in 
Javascript on the Web is unsafe at best today, 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 have to download 
possibly untrusted Javascript cryptographic code in order to obtain 
basic cryptographic functionality not provided natively by Javascript.

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 of which the Web Cryptography 
API is only a single component.  For example,  one open issue is whether 
or not applications using the Web Cryptography API also should be 
required to use CSP 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? Without a doubt these security 
considerations 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, such as 
checking digital signatures to out-of-band key provisioning, that our 
API hopes to enables by allowing key-based encryption and trust to be 
used in Web applications.

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 that makes using 
cryptography easy for Web developers is still on our agenda. However, 
the Working Group decided to iron out the low-level details, in 
particular as regards keys and key storage, before moving to thinking 
about a higher-level and more simple API.

A second issue is that the current Web Cryptography API exposes legacy 
cryptographic algorithms with known weaknesses such as those in  RSA 
PKCS#1 v1.5, 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. These algorithms are not 
required to implement, but if implemented, we felt they should be 
uniformly specified across browsers. In our next iteration of the Web 
Cryptography API, we will label any algorithms with known weaknesses at 
our time of publication with sufficient warnings that the algorithm is 
not suitable to encrypt data and provide preferable alternatives.

Is releasing this cryptography in Javascript to developers responsible?  
Of course, cryptography can be used for both great good and great harm. 
Yet given the current dangerously insecure state of Javascript 
cryptography and the fact that developers are already re-implementing 
cryptographic functions in Javascript, myself and others at the W3C 
thought that action should be taken. Yet who we're really interested is 
not what we think, but what you think.

The entire point of releasing a Working Draft is to get the wider input 
of the community before we set the API in stone by implementing it. 
Indeed, we purposefully released the API at an early stage, when many of 
the basic issues are still unresolved, in order to get community input. 
Indeed, most of the work of the Working Group has been on identifying 
the space of unresolved issues, ranging from how to determine where a 
key is stored and key naming. Many of these open issues are given in the 
fourteen open issues in the specification itself, with more in the 
issue-tracker [6]. What we really want is detailed comments about the 
space of design issues, in particular those currently listed as open 
issues. Also additional use-cases and development of current use-cases 
would be appreciated, which are currently being stored on our wiki [7].

  So please take the time to carefully review the First Public Working 
Draft and send comments to the public-webcrypto@w3.org mailing list, 
where we will respond to you!

[1]http://www.w3.org/TR/2012/WD-WebCryptoAPI-20120913/
[2]http://www.matasano.com/articles/javascript-cryptography/
[3]http://crypto.stanford.edu/sjcl/
[4]http://www.w3.org/TR/CSP/
[5]http://www.w3.org/2012/webcrypto/wiki/SurveyAnalysis
[6]http://www.w3.org/2012/webcrypto/track
[7]http://www.w3.org/2012/webcrypto/wiki/Use_Cases
Received on Monday, 8 October 2012 17:22:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 8 October 2012 17:22:27 GMT