Re: On Crypto API Safety in the Hands of Unskilled Developers

Thank you for your description of a high-level API.

At this time, the WG is pursuing a low-level API.
On Mar 28, 2013 8:21 AM, "Richard Barnes" <rbarnes@bbn.com> wrote:

> The SubtleCrypto thread reminded me that I'd been meaning to send out some
> notes I wrote down about unskilled developers.
>
> Brief essay follows.  Comments welcome.
>
> --Richard
>
>
>
> On Crypto API Safety in the Hands of Unskilled Developers
> =========================================================
>
> I. What is the problem (general)?
> ---------------------------------
>
> The current API's approach of exposing unmitigated complexity to the
> developer -- no defaults, no help from the browser -- is only plausible if
> we assume that the only people who will use the API are experienced
> cryptographers.  This assumption is clearly not true.  Any API that is
> supplied in the DOM will be exposed to, and get used by, a much wider
> variety of developers than we ever intend.
>
> That's true of any DOM API, whether it's crypto, geolocation, canvas, etc.
>  But crypto is special.
>
> -- Bad crypto design leads to worse consequences
> -- Bad crypto design is hard to detect
>
> The whole point of having a crypto API is to protect sensitive things.  So
> by definition, if you screw up your usage of the crypto API, you are
> exposing sensitive things.  Moreover, if this happens, you are likely not
> to notice it.  If you screw up your WebGL rendering code, things will look
> bad.  If you re-use the same nonce twice in GCM, nothing is obviously
> different.
>
> So in its current state, the API makes it likely for bad things to happen.
>  It would be irresponsible of this group to release an API in this state.
>  We need to think seriously about how to make the default mode of the API
> less likely to lead to pain, while still allowing for full generality.
>
> Think of this like consumer protection.  You can't ship a lawn mower that
> doesn't have a guard around the blade.  Someone can buy a lawn mower, take
> off the guard, and use the motor and blade in new and creative ways, at the
> risk of injuring himself.  Even if someone isn't doing something advanced,
> they can still stick their hand under the guard and get cut.  But by
> default, in most use cases, the lawn mower is safe to use.
>
>
>
> II. What is the problem (specific)?
> -----------------------------------
>
> Conceptually, there are two classes of CryptoOperation: "Plain to
> ciphertext" operations that convert plaintext to data with cryptographic
> structure, and "Cipher to plaintext" operations that do the reverse.
>
> P2C       C2P
> -----------------
> sign      verify
> encrypt   decrypt
> digest
>
> The difference is this: P2C operations can meaningfully be done with many
> different choices of parameters.  C2P operations can only be done with a
> specific set of parameters.
>
> Both of these create problems for developers.
>
> For P2C operations, the developer must choose how to set multiple
> parameters, choices that are likely not obvious to someone not skilled in
> the art.
> For C2P operations, the developer needs to make sure that they keep all
> the relevant parameters together with protected information.
>
> So we have two problems:
> P2C: How to help developers make good choices
> C2P: How to help developers keep ciphertext associated to parameters
>
>
>
> III. What would a solution look like?
> -------------------------------------
>
> On the face of it, the P2C problem -- choosing parameters -- seems easy to
> solve.  If there are multiple valid sets of parameters, just have the
> browser / API implementation make the choice on behalf of the developer.
>
> However, this exacerbates the C2P problem, because there are now many ways
> for the ciphertext to be separated from its parameters.  If a web app does
> not store the parameters with which the ciphertext was computed (relying on
> the browser's defaults), then if the browser changes defaults, then the app
> will be unable to decrypt the ciphertext (or validate the signature).  Even
> if the app stores the parameters, then it needs to make sure that the
> ciphertext is always associated with the correct parameters; the app
> cannot, for example, send the ciphertext for storage on a server, but not
> the parameters.
>
> So in order to solve the P2C problem, we also need to solve the C2P
> problem.  Namely, we need to make it easy by default for apps to keep
> parameters and ciphertext together.  In API terms, that would seem to
> indicate that the results of a crypto operation should be provided as an
> object that contains all the relevant parameters (as indeed,
> CryptoOperation already does).  In addition, it would be helpful if this
> object had a default serialization, to address the issue of parameters
> getting lost when the object is stored or sent someplace else.
>
> This gives us two solutions to match the two problems:
> P2C: Provide browser-chosen defaults
> C2P: Provide results in an object with parameters and a serialization
>
> These don't prevent developers from running into problems -- choosing bad
> IVs, or deleting default parameters from the object -- but it encourages a
> default life-cycle that should be problem free:
> * Process plaintext, get ciphertext+parameters
> * Store ciphertext+parameters
> * Process ciphertext+parameters, get plaintext
>
> These solutions also don’t get in the way of more advanced developers.
>  You can still specify all the parameters, and still use whatever parts of
> the object you want.
>
>
>
>
>
>
>
>