Re: CryptoOperations, parameters, and defaults

Sorry it's taken a few days to reply, I've been pondering this off and on while coding...

Could you elaborate a little on how this lock in works?  I'm not getting the "???" parts in this story:
1. Browser provides default algorithms / parameters
2. Web app developer builds application that does / doesn't do ???
3. Browser changes default algorithms / parameters
4. Web app breaks because ???

What I was trying to argue originally is that:
-- Breakage only happens if the app has cached encrypted/signed data and hasn't cached the algorithms / params
-- However, for cached data to be useful at all, in most cases, the app needs to cache something anyway (e.g., an IV/nonce)
-- So if we wrap the algorithms together with those things, then they'll get cached, and there's no breakage

If I'm not convincing you on algorithms, how about at least on ephemeral parameters?  Things like:
-- AesCbcParams.iv
-- AesCtrParams.counter
-- Pbkdf2Params.salt
All of these things need to be cached by the application anyway, and they're can all safely be set to random values.  So couldn't we just have the API generate them instead of forcing the developer to call getRandomValues themselves?


--Richard





On Dec 11, 2012, at 12:03 PM, Ryan Sleevi <sleevi@google.com> wrote:

> 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 Wednesday, 19 December 2012 18:52:26 UTC