Re: CryptoOperations, parameters, and defaults

On Dec 11, 2012, at 10:41 AM, Nat Sakimura <sakimura@gmail.com> wrote:

> You mean, a default encrypt and decrypt functions with sensible algs at the time? 

Yes.  Sensible algorithms, randomly-generated IVs/nonces, etc.


> Roll over is kind of tricky, but I think it is worthwhile. Educating developers on what is a sensible algs is kind of hard. 

From one perspective, roll-over is trivial -- a browser update can change the algorithms.  It will still have to process the old ones (for existing objects generated under the old defaults), but newly created objects will use the new algorithms.


> Provided that there is a trusted committee that decides on what is sensible defaults, it probably is worthwhile. 

It's not clear to me that this is something where a committee needs to be involved.  I would be comfortable leaving the choice to UA developers / browser vendors, especially since a developer can look at the defaults and specify stronger algorithms if he's worried that the defaults aren't strong enough.

--Richard



> 
> Nat
> 
> On Wed, Dec 12, 2012 at 12: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.
> 
> 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.
> 
> 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
> 
> 
> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>

Received on Tuesday, 11 December 2012 15:47:36 UTC