Re: Non-crypto algorithms or more general data processing API

Hi Joel,

Thanks for your comments. I've replied inline to the points you've raised.

On Tue, Sep 18, 2012 at 9:47 AM, Joel Martin <github@martintribe.org> wrote:
> 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.

Correct. This is because there are two definitions of "supported", one
of which must be dealt with asynchronously.

It is expected that user agents will not be directly including
cryptographic implementations themselves, but instead making use of
libraries or functionality provided by existing systems. For example,
the use of the operating systems' cryptographic primitives, or the use
of configurable cryptographic modules via means such as PKCS#11. There
are a variety of reasons for this - both technical and political - but
that's at least the framing for the discussion.

Thus, the user agent serves to bridge the executing application
(presumably written in Javascript) and the OS APIs (presumably exposed
in appropriate bindings such as C, C++, Objective-C, etc).

So the two types of "supported" that emerge are:
1) The user agent knows how to translate the Javascript parameters
(the AlgorithmIdentifier) into the appropriate crypto-library specific
arguments. This is something that the user agent presumably knows
itself, without necessarily needing to call out to other APIs, or at
least without needing to perform some form of expensive or blocking
call.
2) Whether the underlying cryptographic library supports the algorithm.

The problem with 2) is that such operations are generally expensive
operations (in terms of time), so we do not want them to be blocking.
They may also be context dependent - for example, they may depend on
the key being used, or the operation being performed (encrypt or
decrypt), or the parameters of the algorithm itself (eg: the inner
hash function for an HMAC, for example). To accurately determine
whether the algorithm is supported, it more or less requires all of
the parameters you would pass to a CryptoOperation.

Early on, the WG discussed this fairly in depth, and the alternatives
for this (such as trying to exhausively enumerate every supported
algorithm/parameter, either in the overall API, or on a per-key
basis), was not seen to have desirable performance or usability
characteristics, which is what lead to the current approach.

For most of the use cases described and discussed so far, the sort of
complete enumeration hasn't been needed. It only really comes into
play when you're having two user agents negotiate with eachother, and
attempting to do so comprehensively (eg: the TLS-in-JS model). Do you
have a use case where this functionality would be needed?

>
> 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.

While it's true that this API can provide correctness (in the sense of
re-using existing implementations, presumably vetted by user agent
vendors), it doesn't necessarily provide speed. Further, the most
compelling feature about this - that cannot be implemented in JS - is
related to the secure key store functionality being afforded.

The broader comments about supporting arbitrary forms of
transformations is well-met, and for the sense of a generic API, is
probably better suited for the overall Web Apps WG as a point of
discussion. We've identified ISSUE-18 (
http://www.w3.org/2012/webcrypto/track/issues/18 ), which I think is
related to the underlying comments about a generic API. To that end,
Microsoft has previously proposed a generic Streams API, which can use
a StreamBuilder (
http://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm ) to
perform a generic transformation of data. I believe solutions in that
nature may better meet the generic Transform API you describe, and
perhaps with better performance characteristics.

At this time, and based on our charter, I believe we will continue to
focus on the task at hand, which is to ensure we can support the
cryptographic primitives. I think there is still ongoing discussion
related to the CryptoOperation and whether it is the right
abstraction, so this may significantly change in the future.

Thanks again for your feedback,
Ryan

>
> 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

Received on Wednesday, 19 September 2012 18:04:28 UTC