Re: CryptoOperations, parameters, and defaults

On Tue, Dec 11, 2012 at 7:27 AM, Richard Barnes <rbarnes@bbn.com> wrote:
> A modest proposal for simplifying the API for developers:
>
> Choosing algorithms and parameters is hard.  How should a developer decide whether to use AES-CBC or AES-CTR?  How often should the developer generate a new IV?  There are definitely pitfalls here if the API forces developers to make all these choices, as the current API does.  It would be really nice if a developer could just say "new Encryptor(key)" and have the browser choose everything else.

This was discussed during the Lyon F2F and was what I suggested was
the "High-Level API" that I was thinking about. As you can see, it's
even higher than JOSE.

>
> The trade-off is that the browser would need to say what it had chosen, and applications might need to cache some things.  The first of these is easy enough to do, say by having a field "algorithm" on the CryptoOperation interface, from which an application could fetch the algorithm structure used for this operation.  Then we would just need to recommend that that data structure be stored alongside any encrypted objects. There is some risk of non-decryptable objects (if the parameters get lost), but this seems like a better failure mode than, say, re-using nonces.

As I have repeatedly noted, I strongly object to defaults in the low-level API.

Security is about correctly choosing the parameters. Further, in an
optional-all spec such as this, defaults carry with them imperative
suggestions about what "should" be implemented, and carry for
developers suggestions about what "should" be secure.

Once implemented, a user agent cannot change what defaults are, for
fear of breaking existing deployed applications. You can argue whether
or not it's "fair game" for an application to be poorly written like
that, but it happens, and user agents are, in effect, bound.

Finally, there is nothing preventing library authors from providing
such a high level API around the low-level API, such as NaCl and
KeyCzar have done for native code. SJCL, in providing these functions,
is operating exactly like the aforementioned libraries, and I would
continue to suggest that it's exactly the sort of things that
libraries SHOULD do and that user agents MUST NOT do.

If you look at the value add proposition of what this API provides for
SJCL, you will see that SJCL implements a number of low-level
algorithms in order to be able to provide that high-level API. These
algorithms can be used by SJCL in WebCrypto-enabled browsers to
provide (hopefully) more efficient and (decidedly) correct
implementations. Which is not to say that Emily, Mike, or Dr. Boneh
have made mistakes, just that the JavaScript VMs actively conspire
against them.

So we've had the conversation about defaults a lot, and
unsurprisingly, I still oppose them.

>
> This seems to me like it would be a worthwhile simplification.  It is essentially the same thing that the SJCL encrypt() and decrypt() convenience functions do.  Comments welcome.
>
> --Richard
>
>
>

Received on Tuesday, 11 December 2012 17:03:49 UTC