- From: Simon Heckmann <simon@simonheckmann.de>
- Date: Wed, 27 Jul 2011 00:55:30 +0200
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 <silviapfeiffer1 at gmail.com>: > 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 <ddahl at mozilla.com> 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" <silviapfeiffer1 at gmail.com> >> To: "David Dahl" <ddahl at mozilla.com> >> Cc: "WHATWG Proposals" <whatwg at lists.whatwg.org> >> 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 <ddahl at mozilla.com> 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 >>> >>
Received on Tuesday, 26 July 2011 15:55:30 UTC