[whatwg] DOMCrypt update: July 14 Meeting Report

[Adam Barth]

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 <simon at simonheckmann.de> 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 <w3c at adambarth.com>:
>
>> 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 <simon at simonheckmann.de> 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 <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
>>>>>>
>>>>>
>>>
>