Re: SubtleCrypto

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.

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 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.

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:42:04 UTC