Re: Separate method for key agreement?

Richard,

Your proposal does not seem to address multi-party key agreement scenarios,
where the original does.

How would you propose to address them?


On Tue, Apr 2, 2013 at 9:26 AM, Acar, Tolga <tolga.acar@intel.com> wrote:

> I'd side with Richard in separating key agreement and key derivation into
> separate APIs, similar to CNG's approach. There are protocols, such as TLS,
> more than one symmetric key is derived from an agreed-upon (or transported)
> secret Z. Combining KDFs with agreement would minge these together; that
> doesn't seem like a primitive/low-level API, but gets close to being
> coupled with a protocol. Recalling the other high/low level API discussion,
> I am suggesting the low-level approach here, and a higher level API, if one
> is compelled to do so, can be built on it.
>
> - Tolga
>
> > -----Original Message-----
> > From: Richard Barnes [mailto:rbarnes@bbn.com]
> > Sent: Tuesday, April 02, 2013 9:11 AM
> > To: Vijay Bharadwaj
> > Cc: Wan-Teh Chang; Ryan Sleevi; public-webcrypto@w3.org Group
> > Subject: Re: Separate method for key agreement?
> >
> > I don't think I had worked out the details that far :)
> >
> > The "derivedKeyType" is perhaps misleading (copy/paste error).  I didn't
> > mean to imply that derivation would be included in this method.  You
> would
> > actually need another field to specify the KDF, since "derivedKeyType"
> > indicates the algorithm that the new key is to be used with, not the KDF.
> >
> > I actually think it would be simpler to have this just be the secret
> agreement,
> > then do key derivation with deriveKey().  Using a secret handle isn't an
> issue
> > here; you get back a Key object, which is essentially a secret handle
> anyway.
> >
> > Yet another case where a Promises-style API would be nice to have...
> >
> > let derive = function(key) {
> >   window.crypto.deriveKey(..., key, ...); }
> > window.crypto.agreeKey(...)
> >   .then(derive)
> >   .then(doStuff);
> >
> > --Richard
> >
> >
> > On Apr 2, 2013, at 4:57 AM, Vijay Bharadwaj
> > <Vijay.Bharadwaj@microsoft.com> wrote:
> >
> > > Windows CAPI is unique in its handling of DH. It is not a great
> example to
> > emulate.
> > >
> > > CNG is a better example. As I understand it, the proposal below
> combines
> > the secret agreement and key derivation steps (which are distinct in CNG)
> > into a single step. This seems like a good idea - CNG has to use a secret
> > handle to allow the caller to link these two steps without exposing the
> raw
> > secret, but this would be harder to do neatly in JS. Am I understanding
> the
> > proposal correctly?
> > >
> > > -----Original Message-----
> > > From: Wan-Teh Chang [mailto:wtc@google.com]
> > > Sent: Monday, April 1, 2013 5:45 PM
> > > To: Ryan Sleevi
> > > Cc: Richard Barnes; public-webcrypto@w3.org Group
> > > Subject: Re: Separate method for key agreement?
> > >
> > > On Mon, Apr 1, 2013 at 12:25 PM, Ryan Sleevi <sleevi@google.com>
> wrote:
> > >>
> > >> I'm not sure I'd agree here. Do you also see separate functions for
> > >> ECDH agreement?
> > >
> > > No.  The function that Richard proposed can handle both DH and ECDH:
> > >
> > > """
> > > KeyOperation agreeKey(Key privateKey,
> > >                      Key publicKey,
> > >                      AlgorithmIdentifier? derivedKeyType,
> > >                      bool extractable = false,
> > >                      KeyUsage[] keyUsages = []); """
> > >
> > > Richard's proposal is consistent with Windows CNG:
> > > http://msdn.microsoft.com/en-
> > us/library/windows/desktop/aa833130(v=vs.
> > > 85).aspx
> > >
> > > Note: Windows CAPI does Diffie-Hellman in a non-obvious manner (using
> > CryptImportKey), so Widows CAPI is not worth being consistent with:
> > > http://msdn.microsoft.com/en-
> > us/library/windows/desktop/aa381969(v=vs.
> > > 85).aspx
> > >
> > > Wan-Teh
> > >
> > >
> >
>
>