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
