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

RE: Separate method for key agreement?

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Tue, 2 Apr 2013 08:57:53 +0000
To: Wan-Teh Chang <wtc@google.com>, Ryan Sleevi <sleevi@google.com>
CC: Richard Barnes <rbarnes@bbn.com>, "public-webcrypto@w3.org Group" <public-webcrypto@w3.org>
Message-ID: <7d115610960144ad9ea02956f212bc39@DFM-DB3MBX15-07.exchange.corp.microsoft.com>
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 08:58:58 UTC

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