W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

RE: Separate method for key agreement?

From: Acar, Tolga <tolga.acar@intel.com>
Date: Tue, 2 Apr 2013 16:26:58 +0000
To: Richard Barnes <rbarnes@bbn.com>, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
CC: Wan-Teh Chang <wtc@google.com>, Ryan Sleevi <sleevi@google.com>, "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
Message-ID: <52337C44538F2F4D87D63A3E46538A8701657259@FMSMSX106.amr.corp.intel.com>
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
> >
> >
> 
Received on Tuesday, 2 April 2013 16:27:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC