I totally agree with you. My code was just an example. I also think it should be idiot proof.
However, I think the whole API should be loosly coupled. Requiring the client to initialize a cryptographic function on the server seems to tightly linked. I think it should be possible to decrypt any chunk of data with the DOMCrypt API as long as I know the algorithm and the key. But maybe this is out of scope and I am thinking in too universal concepts? Kind regards, Simon Heckmann Am 27.07.2011 um 10:57 schrieb Adam Barth <[email protected]>: > The downside of that sort of API is that you end up storing key > material in the JavaScript heap. There's some question about whether > we should avoid doing that, which is part of the motivation to do the > public key API before the symmetric API. > > Your example also raise the question of how to do key derivation and > key agreement. Taking the MD5 hash of a password isn't really the > best key derivation function! There's a design question of whether we > should design the API to be usable (relatively) safely by non-experts. > Given that this is an API for the web, you can understand the desire > to make things as "idiot-proof" as possible. > > I'd certainly like to see DOMCrypt be able to handle these sorts of > use cases in the future. It's mostly a question of which use cases to > address first. > > Adam > > > On Wed, Jul 27, 2011 at 1:18 AM, Simon Heckmann <[email protected]> > wrote: >> Thank you for your reply, but to me this seems overly complicated. Why do I >> need a KeyId? >> >> What about the following proposal: >> >> Phase one: The server knows the user's password and encrypts the file. >> Phase two: The encrypted file is stored on the local hard drive using the >> File API. >> Pase three: User enters the password, which is hashed and used for >> decryption: >> >> var password = document.getElementById('passwordfield').value; >> var hash = window.crypto.hash('md5', password); >> var data = window.crypto.decrypt('aes-256', hash, encfiledata); >> >> This code is just a sample, but it looks way more convenient to me. >> Additionally there is no need to store the keyid somewhere?!? >> >> Kind regards, >> Simon Heckmann >> >> >> Am 27.07.2011 um 04:14 schrieb Adam Barth <[email protected]>: >> >>> Hi Simon, >>> >>> That would look something like the following: >>> >>> == Phase 1: Key Generation (Client-Side) == >>> >>> crypto.pk.generateKeypair("rsa-1024-aes-128", function(keyID, pubKey) { >>> ... send pubKey to the server ... >>> ... store keyID somewhere??? ... >>> }); >>> >>> == Phase 2: Encryption (Server-Side) == >>> >>> The server encrypts file F under public key pubKey. >>> The server sends the encrypted file EF to the client and stores it >>> locally using the File API. >>> >>> == Phase 3: Decryption (Client-Side) == >>> >>> ... retrieve keyID from somewhere??? ... >>> >>> crypto.pk.decrypt(EF, keyID, function(plainText) { >>> ... rejoice ... >>> }); >>> >>> To fill in the ??? we need to store the keyID somewhere. (To be >>> clear, the keyID is just a capability to use the private key, which >>> never leaves the user agent's secure key store.) To complete your >>> example, we'd need to provide a facility to protect the keyID with the >>> user's password. >>> >>> Adam >>> >>> >>> On Tue, Jul 26, 2011 at 3:55 PM, Simon Heckmann <[email protected]> >>> wrote: >>>> Okay, I am a little confused now: What about the following use case: >>>> >>>> On the server: Encrypt a file using AES-256 with a MD5 hash of the user's >>>> password. >>>> >>>> On the client: Download the file and save it on the hard drive using the >>>> File API. Some time later when offline the user can then enter their >>>> password. DOMCrypt calculates the MD5 hash of the password and decrypts >>>> the locally stored file so it can be viewed by the user. >>>> >>>> As far as I understand your specification this scenario should be >>>> supported, right? How would this look like in source code? Could you give >>>> an example of the JavaScript DOMCrypt calls required for this? >>>> >>>> Additionally, are there plans or a roapmap to bring the DOMCrypt >>>> specification to a W3C technical report? >>>> >>>> Thank you very much! >>>> >>>> Kind regards, >>>> Simon Heckmann >>>> >>>> >>>> Am 27.07.2011 um 00:41 schrieb Silvia Pfeiffer <[email protected]>: >>>> >>>>> OK, so it would apply to a private video conference, but not to >>>>> protect a server-client-delivery. That's good to know, thanks. >>>>> Silvia. >>>>> On Wed, Jul 27, 2011 at 8:26 AM, David Dahl <[email protected]> wrote: >>>>>> Silvia: >>>>>> >>>>>> The design - at this time - allows the client to encrypt data locally, >>>>>> with the publicKey of the recipient - not allowing anyone else to read >>>>>> the data. The callback that the web page provides which captures the >>>>>> decrypted data has full access to the decoded data. >>>>>> >>>>>> I imagine the DRM scenario would be possible if the API was implemented >>>>>> server side, but I think it would be a rather weak system. >>>>>> >>>>>> Generally, this API is designed for private messaging between 2 users, >>>>>> with an untrusted server (as well as all of the hashing, HMAC, sign and >>>>>> verify methods). >>>>>> >>>>>> The use-cases are listed here: >>>>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPI/UseCases >>>>>> >>>>>> Cheers, >>>>>> >>>>>> David >>>>>> >>>>>> ----- Original Message ----- >>>>>> From: "Silvia Pfeiffer" <[email protected]> >>>>>> To: "David Dahl" <[email protected]> >>>>>> Cc: "WHATWG Proposals" <[email protected]> >>>>>> Sent: Tuesday, July 26, 2011 4:58:30 PM >>>>>> Subject: Re: [whatwg] DOMCrypt update: July 14 Meeting Report >>>>>> >>>>>> If I understand this correctly, then this is introducing a mechanism >>>>>> for Web publishers to provide a secure service to users where the data >>>>>> exchanged between the server and the UA is encrypted and not decodable >>>>>> by anyone else listening in on that communication or getting access to >>>>>> the data stored in the browser for that communication. >>>>>> >>>>>> If so, could this be a means to provide a one-session-only decoding >>>>>> key to a UA to decode a specially encoded piece of content (e.g. a >>>>>> video) from a publisher? I am quite directly thinking that this could >>>>>> be a first step towards providing DRM methodology in the browser, but >>>>>> also for example for about having secure private video conversations >>>>>> without needing to install browser plugins. >>>>>> >>>>>> Apologies for taking this thread a bit off topic - I am just curious. >>>>>> >>>>>> Cheers, >>>>>> Silvia. >>>>>> >>>>>> >>>>>> On Wed, Jul 27, 2011 at 5:59 AM, David Dahl <[email protected]> wrote: >>>>>>> Hello All: >>>>>>> >>>>>>> Just a quick report on a DOMCrypt meeting that took place Thursday, >>>>>>> 2011-07-14 at Mozilla in Mountain View. >>>>>>> >>>>>>> Summary: >>>>>>> >>>>>>> DOMCrypt is a high-level API that should be usable by web developers >>>>>>> after a short period of study >>>>>>> DOMCrypt will be designed and implemented so that it is difficult to >>>>>>> "do the wrong thing" >>>>>>> HASH and HMAC methods may be implemented first >>>>>>> The Public Key API is the most useful, so it should be implemented >>>>>>> before the symmetric encryption API >>>>>>> Keypairs must be generated on a per-origin basis >>>>>>> The Keypair for a specific origin cannot be used in another >>>>>>> origin >>>>>>> No private or wrapped key material will be accessible to content >>>>>>> scripts >>>>>>> Each implementation will provide a mechanism to clear keys >>>>>>> A "Key ID" will be used to tell the decrypt method which (content >>>>>>> inaccessible) private key to use to decrypt data >>>>>>> The returned encrypted object format will be a raw ArrayBuffer >>>>>>> The public key format will be a raw ArrayBuffer >>>>>>> **We agreed to "have all the inputs and outputs be raw, >>>>>>> unformatted ArrayBuffers, letting higher-level pure JS wrappers deal >>>>>>> with conversion to application data formats until we understand better >>>>>>> what higher-level formats would be useful" >>>>>>> HASH and HMAC methods should be synchronous to make them simpler >>>>>>> HASH and HMAC methods should be constructors >>>>>>> We may implement the HASH and HMAC APIs first then the PublicKey API >>>>>>> >>>>>>> A wiki page with more detail is here: >>>>>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Meeting-2011-07-14 >>>>>>> >>>>>>> The DOMCrypt Spec is here: >>>>>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest >>>>>>> >>>>>>> Any comments and discussion will be most welcome. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> David Dahl >>>>>>> >>>>>> >>>> >>
