- From: Emily Stark <estark@MIT.EDU>
- Date: Tue, 19 Feb 2013 09:47:25 -0500
- To: David Dahl <ddahl@mozilla.com>
- Cc: Ryan Sleevi <sleevi@google.com>, public-webcrypto-comments@w3.org, Aymeric Vitte <vitteaymeric@gmail.com>
> 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. Ah, I was actually hoping for an AE mode like GCM, which wouldn't require changes to the interface, but just a note in the spec. On Tue, Feb 19, 2013 at 9:35 AM, David Dahl <ddahl@mozilla.com> wrote: > ----- 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:47:55 UTC