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

Re: Separate method for key agreement?

From: Richard Barnes <rbarnes@bbn.com>
Date: Tue, 2 Apr 2013 12:11:29 -0400
Cc: Wan-Teh Chang <wtc@google.com>, Ryan Sleevi <sleevi@google.com>, "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
Message-Id: <8E270004-AAB0-488B-B8B7-9E689880F601@bbn.com>
To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
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, ...);


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:11:58 UTC

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