On Sat, March 9, 2013 5:25 pm, Tony Arcieri wrote: > On Sat, Mar 9, 2013 at 4:16 PM, Jeffrey Walton <noloa...@gmail.com> wrote: > > > The Web Cryptography Working Group looks well organized, provides a > > very good roadmap, and offers good documentation. > > http://www.w3.org/2012/webcrypto/. > > > 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 API. 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 > problems. 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 today*. > > Finally, it'd be great to see someone like NIST or ECRYPT provide browser > vendors with normative advice on algorithms to standardize on. The > existing > WebCrypto spec leaves browser vendors to their own devices, and in that > eventuality, the browser venders will probably wind up implementing the > W3C > 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: > > http://blog.cryptographyengineering.com/2012/12/the-anatomy-of-bad-idea.html 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 class. 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 really. 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. Cheers, Ryan P.S. As with most W3C drafts, the latest Editor's Draft provides much more meaningful status than the WD - https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html You can see the list of changes post-WD2 at https://dvcs.w3.org/hg/webcrypto-api/ _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
