Re: comments on web crypto API: General comments on the document [6/6]

Thanks for your feedback. I've attempted to respond inline.

On Thu, May 23, 2013 at 1:45 AM, Nikos Mavrogiannopoulos
<> wrote:
> * In the security considerations there is no mentioning of attacks like user
> impersonation due to malicious javascript applications, which in our opinion
> is a big threat against such scheme.

I'm not sure I follow, but what I do understand seems to be out of scope.

We're not trying to design a scheme that "secures Javascript" -
rather, we're building on trusted and secured Javascript security

> * Section 6: "If user agents permit keys to be re-used between origins,
> without performing any secondary operations such as key derivation that
> includes the origin," comes out of the blue. Where is key derivation or
> unique keys per origin are discussed before that?

Consider Section 2.1 - "or pre-provisioned out-of-band by the web application".

I'm not sure I follow your objection, or how you would suggest to
improve. It's absolutely vital that the privacy risks of certain
applications or enhancements of this API be spelled out, and this API
clearly does not provide an exhaustive/complete/restrictive
enumeration of the sources of keys (as evidenced by the "Key
Discovery" draft).

> * Interface CryptoOperation. How a specific nonce or an IV to an algorithm
> is used? For example how could a MAC algorithm that requires a nonce with
> each message (i.e., UMAC) can be implemented? Or CBC or GCM encryption? Are
> the IV and nonces automatically generated? How do protocols that require
> specific nonces are handled?

Can you explain what you find unclear/ambiguous about this?

> The AES-CTR/CBC algorithm solves it by specifying the nonce as part of the
> algorithm parameters, that as we understand is the optional array passed to
> SubtleCrypto::encrypt. That way in order to change the nonce/counter, the
> cipher has to be re-initialized (a new CryptoOperation has to be obtained)
> with the same key. That seems like a waste of resources.
> It looks like a method setNonce could help.

Thank you for your suggestion, but I'm afraid it will not work as you think.

The answer is that yes, everything is associated with the
CryptoOperation. There are no "per-call" parameters, such as

This matches the existing APIs and cryptographic libraries in use by
browsers - which was a key use case in the chartering of this group
and design of this API - in that all parameters must be specified up
front so that an implementation can accurately represent whether an
operation is supported.

Implementations built on PKCS#11, for example (which include both
Firefox and Chromium) are not able to change IV midstream.

There should be no presumption that it's a "waste of resources" - the
spec intentionally gives implementations great flexibility in how they
manage resources under the hood, and there is no requirement that a
single Javascript "CryptoOperation" represent a single underlying
native cryptographic operation. Implementations can pool, cache, or
optimize in any number of ways. We've already seen such approaches be
successful with other APIs, such as WebGL.

Received on Thursday, 23 May 2013 16:58:00 UTC