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