[cryptography] Web Cryptography API (W3C Working Draft 8 January 2013)
iang at iang.org
Sun Mar 10 08:05:58 EDT 2013
Everyone's got some negatives to say, drawing from their huge experience
of how they do things, and things they've read from books, and things
that powerful communities have proselytised over the short ages of
public domain crypto.
Unfortunately, we're not at the point, as a community, of saying much
that is positive, in the sense that "the right way" allows a newcomer to
the field to pick up the right tools and get to the end of the road with
the cryptoplumbing locked in and reasonably secure, in efficient time &
As we can show why most advice is nonsense fairly easily, I tend to say
that the best thing to do is to plough on regardless -- do what you can,
and do the best you can. And in the process we -- both you and the
wider community -- will learn.
This works because, while the insider generally underestimates the
complexity of the security field by orders of magnitude, the wider
security community generally underestimates the complexity of the
business by similar orders of magnitude. An insider can deploy tricks
and intuition that outsiders cannot, and can know more quickly when some
ivory tower edifice is tilting or falling, in ways that outsiders will
not see, because latter don't walk around the building, they only stand
in front of its best face.
To get off the pot and say what I think: I personally do not thing an
API will help a lot. (Especially if there is a committee involved.)
But, I think if you had a reference implementation for that API, then it
would have a chance. The developer view here is that only code serves
as code, before any API. Sure, an API provides an easy way to
understand the code. Sometimes it allows substitution (but that's more
a hope than a reality). It can provide choice and it can frame the way
to do good crypto.
But in reality, it's still dominated by the need for code.
On 10/03/13 04:57 AM, Ryan Sleevi wrote:
> On Sat, March 9, 2013 5:25 pm, Tony Arcieri wrote:
>> On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>>> The Web Cryptography Working Group looks well organized, provides a
>>> very good roadmap, and offers good documentation.
>> I have a blog post about it forthcoming, but I'd like to share the tl;dr
>> version here:
>> The normative parts of the specification seem mostly fine.
>> The specification provides no normative advice about what algorithms to
>> use, and worse, provides a non-normative listing of algorithms which are
>> not authenticated encryption modes (for symmetric ciphers, the only mode
>> listed in the spec is AES-GCM)
> That is correct. This is not a "How to use cryptography" spec. This is an
> This is not an evangelical API. I realize the crypto clergymen may not
> like this, but APIs that proselytize do not somehow educate more. They
> merely get in the way of people who know what they're doing, and the
> people who don't know what they're doing will find plenty of other ways to
> screw up (eg: XSS, XSRF, insecure cookies, clickjacking, framing, etc).
> Plus, it only takes one Stack Overflow question & answer, or one bad
> W3CSchools post (redundant much?), to undermine whatever message was
> intended for those crypto black sheep.
>> At the very least, I'd like to see the non-normative examples section
>> expanded to include a lot more authenticated encryption modes (EAX mode
>> comes to mind, and seeing support for NaCl algorithms like crypto_box and
>> crypto_secretbox would be super). Right now they give some rather poor
>> recommendations, for example they recommend CBC mode which is fraught with
> What use case makes the "NaCl" algorithms (whose specification is merely
> 'use NaCl', which boils down to "Use Salsa+Curve25519") worthwhile? If you
> don't trust developers to be able to use the API correctly, what makes you
> think that they can sufficiently understand the security guarantees that
> NaCl does - and *doesn't* - provide. And how can we be sure that the
> problems that NaCl sets out to solve are the same problems developers want
> or need to solve, especially when all the evidence suggests otherwise?
> Arguably, the answer for whatever use case you imagine NaCl meeting can
> almost certainly be met through JOSE, if and when it ever gets its act
> together. If you want something high level, use something designed to be
> interoperable (and hopefully, JOSE will actually use JSON by then). As
> much respect as I have for DJB, Sodium's existence is proof positive of
> what NaCl does and doesn't set out to do.
> Finally, the recommendations are for what implementations should support.
> There is not any mandatory to implement suite at this point. Instead, it's
> looking at what are the algorithms in vast, sweeping use today in a number
> of protocols and applications, and that developers will expect or need
> supported to implement a variety of applications *that already exist
>> Finally, it'd be great to see someone like NIST or ECRYPT provide browser
>> vendors with normative advice on algorithms to standardize on. The
>> WebCrypto spec leaves browser vendors to their own devices, and in that
>> eventuality, the browser venders will probably wind up implementing the
>> spec's (poorly chosen) non-normative recommendations.
> NIST or ECRYPT? Why not KISA or GOST? After all, everyone loves SEED and
> GOST 28147-89...
> The answer is that the choice of algorithms were motivated by two factors:
> 1) As stated in the charter, exposing (some of) the cryptographic services
> already inherent in browser applications today. [In order to provide
> constant time, correct, validated implementations of the algorithms -
> things impossible in JS today]
> 2) The choice of algorithms that are meaningful to web application
> developers - which includes the W3C SysApps WG - which has an *entirely*
> different security model than the drive by web. Support for "legacy"
> algorithms in order to support those "esoteric" protocols like SSH, PGP,
> or S/MIME (or would you rather your browser bake them in? *shudder*), as
> well as the choice of algorithms that are suitable for future work (and,
> notably, being explored in JOSE)
>> For an in-depth look at the problems, I'd recommend checking out Matt
>> Green's blog post:
> Matt's post, besides being entertaining and certainly with some
> meritorious points, basically sums up as "No backwards compatibility, and
> only give people what the priesthood accept." Respectfully, that doesn't
> lead to more secure code, nor does it lead to what smart people - people
> who know what they're doing - *actually* want or need (as done through
> repeated surveys from participants and non-participants of the WG).
> While I can understand that, on a list such as this, people are well
> trained to turn their noses upwards at "bad" cryptography, this is not
> going to usher in some Apocalypse that will doom us all. Cross-site
> scripting, SQL injection, hell, even the lack of SSL/TLS for the vast
> majority of sites is a far, far more serious threat. And the notion that
> there's a single, high-level, "nothing but the securest of cryptographic
> compositions, aged 5 years in a lead vault" sort of API that can actually
> meet the needs of developers - both those that have no security background
> and those that do - is unfortunately naive.
> The goal of the API is to look at the problems faced by otherwise solid
> implementations - things like SJCL (which *is* a high level API) and
> Persona - and say, "What are the fundamental problems with these, and how
> can the browser vendors address them?" And it's to look at web apps,
> SysApps, and the wide variety of "HTML5+JS
> using-but-not-on-the-drive-by-web-apps", and say, "What are the tools that
> developers need to be able to solve the problems they care about". And one
> size does not fit all.
> It's usually in the same breath that people dismiss HTML+JS as being an
> app development platform that they present low-level JS crypto as being
> inherently bad, which only continues to doom HTML+JS to being second
> Do I want to see a JCE-style API? No, I really, really do not. At the same
> time, do I want to see a two-or-four-method one size fits all API? Not
> I'm more than happy to take criticism on the API - Lord knows it needs
> more eyes on it, and it's certainly missing big gaps (which I'm quite
> literally filling in right now) - but I want to make sure that it's well
> understood exactly what problems are and are not trying to be solved.
> These are real problems, faced by real developers, who do accurately and
> honestly understand the real risks of bad crypto. We're not going to burn
> down the 30 years of applications we have, and somehow re-invent them all
> (and perfectly) with this spec.
> P.S. As with most W3C drafts, the latest Editor's Draft provides much more
> meaningful status than the WD -
> You can see the list of changes post-WD2 at
> cryptography mailing list
> cryptography at randombit.net
More information about the cryptography