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