CryptoOperations, parameters, and defaults

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

Received on Tuesday, 11 December 2012 15:28:29 UTC