- From: Ryan Sleevi <sleevi@google.com>
- Date: Thu, 23 May 2013 09:57:28 -0700
- To: Nikos Mavrogiannopoulos <nikos.mavrogiannopoulos@esat.kuleuven.be>
- Cc: "public-webcrypto-comments@w3.org" <public-webcrypto-comments@w3.org>, danny de cock <Danny.DeCock@esat.kuleuven.be>, Filipe Beato <filipe.beato@esat.kuleuven.be>
Thanks for your feedback. I've attempted to respond inline. On Thu, May 23, 2013 at 1:45 AM, Nikos Mavrogiannopoulos <nikos.mavrogiannopoulos@esat.kuleuven.be> 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 model. > > * 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? https://dvcs.w3.org/hg/webcrypto-api/raw-file/45c433f19151/spec/Overview.html#aes-gcm 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 "setNonce". 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