Non-crypto algorithms or more general data processing API

First a specific comment on the current API doc: I don't see any easy way
to query available algorithms without actually creating a CryptoOperation
for each algorithm that might be supported.

General observation:

I don't want to derail this excellent work, but it strikes me that the API
could be a bit more generic and a lot more powerful. Essentially
window.crypto is a library for doing transformations on ArrayBufferView
data with additional support for managing and storing metadata (i.e. keys)
used as part of those transformations. Essentially this is an issue of
speed and correctness.

Crypto can certainly be done with existing Javascript, Typed arrays and
localStorage without "native" window.crypto support but performance would
certainly be less than optimal and each implementation would likely have
bugs (or not be fixed when algorithmic weaknesses are discovered). However,
crypto is not the only intensive operation that is or could be given the
"native" treatment. Others that come to mind: zip/inflate/deflate, matrix
transformations (e.g. WebGL textures), gamma correction (superfast
Instagram web app anyone?), FFT, bit/pattern counting, CRC, sha256sum,
running XOR/AND/OR/NAND, image mask, etc, etc. A lot of these algorithms
could probably just re-use code that already exists in most browser
implementations.

It doesn't necessarily need to be that big of a change to the current API,
perhaps just a new createTransform and with one or two recommended
transforms that would be easy for implementers (e.g. inflate/deflate,
running XOR). Transform names could also be vendor prefixed for implementer
experimentation that hasn't been adopted yet by the working group. A more
ambitious approach would be something akin to the Web Audio node graph but
for multiple data transformations but that probably grows the scope too
large to be considered.

I have some hope that the WebCL work may address some of the fast data
transformation space for Javascript, but that effort seems to have stalled
out somewhat and is somewhat complementary anyways.

Obviously, the API should be structured so that the most important short
term goal (encryption/signing) is fool proof and without fuss for web
developers. But without sacrificing that goal it does seem like the API
could be made more generic and much more powerful.

Keep up the good work.

Joel Martin
https://github.com/kanaka