Re: SubtleCrypto

On Thu, Nov 7, 2013 at 1:32 PM, Oliver Hunt <oliver@apple.com> wrote:
> Hi all, I’ve been following the spec and various discussions regarding subtle crypto (and the WebCrypto spec in general) and i do have a few concerns.
>
> My opinion is that WebCrypto should make the simplest and most obvious thing to do be correct.  That is the API should be a small as possible, and have only those primitives that are absolutely necessary for encryption, decryption, authenticity, and message verification.  It should not require extra work, or separate steps for any of these — I would argue that any encryption perform should default to providing an content blob that is encrypted and includes at minimum verification, and should make it _hard_ to override that default.

Greetings Oliver,

I'm glad you're getting up to speed on this. This particular point has
been a point that's been discussed since the very beginning of the WG,
so there's certainly a lot of discussion here.

In order to avoid rehashing much of the conversation, I'd like to pose
two hopefully simple questions:

1) What use cases do you see this supporting?
  Context: The choice of use cases directly influences the choice of
crypto combinations. Do you choose pre-built compositions like NaCl or
KeyCzar, do you allow caller-specified combinations like JOSE, do you
handle agreement schemes like OTR/mpOTR, do you handle deniability
like Pond, or do you invent something new entirely?

2) How will you address the other use cases that have been identified
with great enthusiasm by a number of members in this WG, ranging from
certificate-based authentication schemes to supporting Javascript
Applications (whether via Extensions/SysApps/Win8-Metro apps or simple
hosted-in-a-page apps) with such a scheme?

>
> I’m also weary of providing byte array representation of any of the core primitives as history has shown that doing so leads to developers creating timing attacks.

I would hope you could elaborate on this, since the very design is to
reduce such timing attacks, by providing a sufficiently high level
abstraction that timing sensitive operations (such as checking the
padding bytes of a PKCS#1 message) are done within the implementation.

>
> I am strongly opposed to the current SubtleCrypto _name_.  I recognise the need for these low level primitives for interacting with arbitrary encrypted mediums, but the naming is weak.
>
> “Subtle" does not convey the risk involved as it is vaguely ambiguous to native english speakers, and much worse for non-native english speakers.  I think the spec should replace “subtle” with the much stronger and less ambiguous term “unsafe”, this makes it very clear that using the API is risky, and would hopefully discourage developers from using it directly.

Is it correct to say you would disagree with the position that
"unsafe" is a misnomer, given that nothing about these operations is
*inherently* unsafe, but MAY be use unsafely?

Consider, for example, AES-CBC or AES-CTR. It's possible to use them
incorrectly (eg: without a MAC, without a fresh IV), but it's equally
possible to build semantically secure and strong encryption schemes
with desirable benefits (compared to, say, AES-GCM).

>
> I’m still getting up to speed with the API, and I just found the spec version i was reading was actually an old draft so i’m going to hold back on more specific critiques until i’ve read the newest drafts.
>
> —Oliver
>

Received on Thursday, 7 November 2013 21:56:37 UTC