Re: An initial editor's draft: high-level API

----- Original Message -----
> From: "Emily Stark" <estark@MIT.EDU>
> To: "Aymeric Vitte" <vitteaymeric@gmail.com>
> Cc: "Ryan Sleevi" <sleevi@google.com>, "David Dahl" <ddahl@mozilla.com>, public-webcrypto-comments@w3.org
> Sent: Tuesday, February 19, 2013 7:34:22 AM
> Subject: Re: An initial editor's draft: high-level API
> 
> I was wondering if we could revisit sign/verify. I'm curious to hear
> why Adam Langley thought these should be dropped; I understand that
> messages can be signed with encryptAndSign, but it seems wasteful and
> confusing to always require encryption along with signatures. NaCl,
> KeyCzar, and SJCL all have sign()/verify() (as well as MACs) that
> don't also require the user to encrypt/decrypt.
> 

I was deferring to the smallest footprint possible. I would not be opposed to re-introducing them.

> Also, a couple things about seal/open:
> 1.) Could seal() explicitly be defined as authenticated encryption
> instead of just symmetric encryption?
It certainly could. The intention here is (mainly) encrypting locally-stored data, so I left it out thinking the interface would become complex. I imagine we could hide the details of the authentication with an implied signing key pair created for each host and used behind the scene.

> 2.) This is pedantic, but once I saw seal() I started looking for
> unseal() and took me a minute to realize that open() was what I
> should
> be looking for. Is there any reason not to use seal/unseal instead of
> seal/open?
Naming *is* hard.:) I think Adam Langley suggest seal/open based on other APIs.

> 3.) Why does seal generate a fresh key each time instead of having a
> createKey function? This seems like it could cause extra complication
> for developers; NaCl/SJCL allow you to specify a key to use for
> symmetric encryption.
> 
Again, this is for utter simplicity, the key is generated and used and the dev does not need to know the details. We could add an optional symKey argument, a JSON Web Key.

Regards,

David

> On Tue, Jan 29, 2013 at 5:21 AM, Aymeric Vitte
> <vitteaymeric@gmail.com> wrote:
> >
> > Le 28/01/2013 22:56, Ryan Sleevi a écrit :
> >
> >>>> 7) You make use of DOMString in the following methods:
> >>>> >>   a) encryptAndSign (aPlainText)
> >>>> >>   b) protect (aPlaintext)
> >>>> >>   c) unprotect (aPlaintext - see 5)
> >>>> >>   d) sign (aClearData)
> >>>> >>   e) verify (aDataToVerify)
> >>>> >>How is this data supposed to be canonicalized? How is
> >>>> >>arbitrary
> >>>> >>binary
> >>>> >>data supposed to be encoded? What about decoded?
> >>>
> >>> >
> >>> >While I would like to make the interface as simple as possible
> >>> >(using
> >>> > strings), this is an issue that may require the use of
> >>> > ArrayBufferViews
> >>> > after all. I am unsure how to make DOMStrings viable here.
> >>
> >> http://encoding.spec.whatwg.org/  ?
> >>
> > If this can help, simple example here
> > (https://github.com/Ayms/node-typedarray) how to use ArrayBuffers,
> > TextEncoder/Decoder, and make all this more "high-level".
> >
> > --
> > jCore
> > Email :  avitte@jcore.fr
> > iAnonym : http://www.ianonym.com
> > node-Tor : https://www.github.com/Ayms/node-Tor
> > GitHub : https://www.github.com/Ayms
> > Web :    www.jcore.fr
> > Webble : www.webble.it
> > Extract Widget Mobile : www.extractwidget.com
> > BlimpMe! : www.blimpme.com
> >
> >
> 
> 
> On Tue, Jan 29, 2013 at 5:21 AM, Aymeric Vitte
> <vitteaymeric@gmail.com> wrote:
> >
> > Le 28/01/2013 22:56, Ryan Sleevi a écrit :
> >
> >>>> 7) You make use of DOMString in the following methods:
> >>>> >>   a) encryptAndSign (aPlainText)
> >>>> >>   b) protect (aPlaintext)
> >>>> >>   c) unprotect (aPlaintext - see 5)
> >>>> >>   d) sign (aClearData)
> >>>> >>   e) verify (aDataToVerify)
> >>>> >>How is this data supposed to be canonicalized? How is
> >>>> >>arbitrary
> >>>> >>binary
> >>>> >>data supposed to be encoded? What about decoded?
> >>>
> >>> >
> >>> >While I would like to make the interface as simple as possible
> >>> >(using
> >>> > strings), this is an issue that may require the use of
> >>> > ArrayBufferViews
> >>> > after all. I am unsure how to make DOMStrings viable here.
> >>
> >> http://encoding.spec.whatwg.org/  ?
> >>
> > If this can help, simple example here
> > (https://github.com/Ayms/node-typedarray) how to use ArrayBuffers,
> > TextEncoder/Decoder, and make all this more "high-level".
> >
> > --
> > jCore
> > Email :  avitte@jcore.fr
> > iAnonym : http://www.ianonym.com
> > node-Tor : https://www.github.com/Ayms/node-Tor
> > GitHub : https://www.github.com/Ayms
> > Web :    www.jcore.fr
> > Webble : www.webble.it
> > Extract Widget Mobile : www.extractwidget.com
> > BlimpMe! : www.blimpme.com
> >
> >
> 
> 
>

Received on Tuesday, 19 February 2013 14:35:40 UTC