Fwd: some input on API

As of now, Ben Adida hasn't yet been approved to send messages to public-webcrypto, so forwarding for now :)


Begin forwarded message:

> From: Ben Adida <ben@adida.net>
> Subject: Fwd: some input on API
> Date: April 12, 2013 7:16:57 PM EDT
> To: arun@mozilla.com
> 
> 
> Could you forward this for me? Apparently, I'm not a member.
> 
> -Ben
> 
> ---------- Forwarded message ----------
> From: Ben Adida <ben@adida.net>
> Date: Fri, Apr 12, 2013 at 4:11 PM
> Subject: some input on API
> To: public-webcrypto@w3.org
> 
> 
> 
> Hi folks,
> 
> I would like to help a little bit by providing an additional perspective from the point of view of someone who's implemented crypto code in JavaScript in a few settings. One of them is Mozilla Persona, which uses fairly standard cryptography. The other, the Helios Voting System, is much smaller, but may be interesting in that it uses much less standard crypto (exponential el-gamal for its homomorphic properties, zero-knowledge proofs, ..)
> 
> I'll add that I have one more bit of perspective: Mozilla Persona includes a DOM API, so I understand a little bit the pain of defining a web API that others will use in unanticipated ways.
> 
> With that said, a few thoughts:
> 
> - use cases: implementing compatibility with existing protocols is a fairly convincing use case, in my opinion. This means that a low-level API seems like the right approach to begin with, even if we would prefer web developers to use higher-level APIs for new applications.
> 
> - minimalism: ideally a new web API includes only the minimal set of features that could not be just as easily implemented in pure JavaScript. In the webcrypto case, the need for constant-time is particularly salient, especially in light of evolving JavaScript optimizations. So that justifies the implementation of the low-level API which cannot be fulfilled purely by sjcl. 
> 
> - high-level API: I don't yet see the need for a *native* high-level API. What API would we want that we cannot implement today on top of a low-level API? I can see the argument for this low-level API to include a BigNum library. But beyond that, a nice public library, a-la jQuery, that sits on top of the native low-level API when available, may well be the right approach to a high-level API.
> 
> - legacy algorithms: we have to assume that any algorithm we build in today will be legacy at some point. In other words, we should plan for a situation where a user-agent is asked to perform an operation with a known-weak algorithm that wasn't weak last year. That leads me to believe we should have three levels of algorithm support: fully supported, deprecated, and insecure. The API will (a) work for fully supported algorithms, (b) console-warn for deprecated algorithm, (c) not work for insecure algorithms. An API call, e.g. window.crypto.enableInsecureAlgorithms() could be used to override (c), though console warnings should remain.
> 
> - defaults: given the point above about legacy algorithms, I don't think we should have defaults, as the right default might change over time, causing working code to break in very curious ways. If an algorithm becomes insecure, the user-agent should throw an exception as per the previous point: log to console and say "insecure algorithm." Sensible defaults can be enforced by high-level JS libraries that, for a given library version, are predictable across user-agents.
> 
> - developers will do it wrong: of course they will. The best possible defense against this is to build a precise, low-level, no-defaults API that is labeled as "for experts only," then to encourage the development of simpler JS libraries with higher-level APIs, sensible defaults, and protection from sharp features. This is not foolproof. But it is likely better than to try to make an API that fulfills the necessary use cases (existing protocols) *and* tries to appeal to less-knowledgeable developers.
> 
> - BigNum: I'd love a fast BigNum library for things like the Helios Voting System. I'd like to think we don't have to wait for the next version of JavaScript to make that happen, but that may be the wrong instinct. There is a real difference between jsbn.js and native BigNum that makes entire categories of problems suddenly tractable. But, to be clear, that's for my pet project. Mozilla Persona does not require this, as we use standard crypto algorithms and have no immediate plans to stray.
> 
> I hope this helps!
> 
> -Ben
>