RE: ACTION-84: Finishing support for key derivation/key agreement

Ah, that clarifies it for me - agreed.
I think it would be helpful to give sample code for DH-basic (unauthenticated DH), MQV, and HMQV - in ECC or in FFC fields.

- Tolga

> -----Original Message-----
> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
> Sent: Monday, May 20, 2013 3:43 PM
> To: Acar, Tolga; Ryan Sleevi
> Cc: public-webcrypto@w3.org; Jim Schaad; Richard Barnes
> Subject: RE: ACTION-84: Finishing support for key derivation/key agreement
> 
> OK, I see where the confusion comes from now.
> 
> I'm basing my terminology on the use cases earlier in my email. In other
> words, when I say "ephemeral key" I mean the secondary key that one
> would use in DH or MQV. I realize that the "primary key" which I refer to as
> "static key" can sometimes be an ephemeral key (just as sometimes the
> secondary key can be a static key) but I was hoping not to get into that
> distinction here.
> 
> So, stated in less ambiguous language:
> 
> - DH case 1: myPrivateKey = my primary key, peerPublicKey = peer's primary
> key
> - DH case 2: myPrivateKey = my primary key, peerPublicKey = peer's primary
> key, alg parameters contain my secondary private key and peer's secondary
> public key
> - MQV: myPrivateKey = my primary key, peerPublicKey = peer's primary key,
> alg parameters contain my secondary key pair and peer's secondary public
> key
> 
> -----Original Message-----
> From: Acar, Tolga [mailto:tolga.acar@intel.com]
> Sent: Monday, May 20, 2013 3:33 PM
> To: Ryan Sleevi
> Cc: Vijay Bharadwaj; public-webcrypto@w3.org; Jim Schaad; Richard Barnes
> Subject: RE: ACTION-84: Finishing support for key derivation/key agreement
> 
> 
> 
> > -----Original Message-----
> > From: Ryan Sleevi [mailto:sleevi@google.com]
> > Sent: Monday, May 20, 2013 2:52 PM
> > To: Acar, Tolga
> > Cc: Vijay Bharadwaj; public-webcrypto@w3.org; Jim Schaad; Richard
> > Barnes
> > Subject: Re: ACTION-84: Finishing support for key derivation/key
> > agreement
> >
> > On Mon, May 20, 2013 at 2:12 PM, Acar, Tolga <tolga.acar@intel.com>
> wrote:
> > > Thanks, Vijay - inline.
> > >
> > >> -----Original Message-----
> > >> From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
> > >> Sent: Monday, May 20, 2013 12:11 PM
> > >> To: Acar, Tolga; public-webcrypto@w3.org
> > >> Cc: Jim Schaad; Richard Barnes
> > >> Subject: RE: ACTION-84: Finishing support for key derivation/key
> > >> agreement
> > >>
> > >> [Acar, Tolga] What is the advantage of putting ephemeral keys in
> > >> algorithm parameters instead of using importKey to create a key
> > >> object from an ephemeral key (or keys in plural), and passing the
> > >> key
> > >> object(s) as the first and/or second parameter to this call? The
> > >> importKey approach seems to create a simpler interface and
> > >> implementation, since an implementation would have only one place
> > >> to
> > look for keys.
> > >>
> > >> Sorry, I realize now that the text was ambiguous. The idea is to
> > >> have these ephemeral keys passed as Key objects, not as byte
> > >> arrays. So the discussion boils down to whether they are passed as
> > >> top-level parameters to the function, or as algorithm-specific
> > >> parameters in a dictionary. If we agree that this is the issue, I'm
> > >> happy to have the
> > discussion on where this should go.
> > > [Acar, Tolga] Yeah, I'd prefer as top-level arguments for keys
> > > instead of
> > passing them in the algorithm parameters.
> >
> > I'm not really sure this is good/idiomatic JS. So far, the API has
> > attempted that everything that is consistent for all
> > operations/algorithms gets passed as a 'top-level' argument, whereas
> > context-dependent parameters are passed in the dictionaries.
> >
> > I'm inclined to agree with the text as written - keeping them
> > separate, rather than putting them as optional parameters.
> >
> > Could you explain more you're thinking on this?
> [Acar, Tolga] From where I sit, you and I seem to agree. Let me clarify first,
> and let me know if you think we are not on the same page after my
> explanation below.
> 
> This is one of the API suggestions from Vijay's e-mail.
> > >> > KeyOperation secretAgreement(Key myPrivateKey, Key
> peerPublicKey,
> > >> > AlgorithmIdentifier agreementAlgorithm, AlgorithmIdentifier
> > >> > derivationAlgorithm);
> 
> I am suggesting that the private key object is always supplied as the first
> argument named "myPrivateKey", the public key is always supplied in the
> second argument named "peerPublicKey" to the secretAgreement()
> function. The text as written told me otherwise (I passed the partial text
> below for convenience). In particular, the text says that ephemeral keys
> (which I interpret as public and private keys) are supplied in the parameters
> of the "agreementAlgorithm" parameter. The last sentence is where I
> disagree: I'm suggesting that the public and private keys are always supplied
> in the first function argument (myPrivateKey) and the second argument
> (peerPublicKey) to the secretAgrement() function. Vijay's answer seems to
> agree with my suggestion, and so does your argument above on 'top-level'
> arguments.
> 
> > >> > for derivationAlgorithm. Ephemeral keys and key pairs are
> > >> > supplied as parameters to the agreementAlgorithm (subject to
> ACTION-83).
> 
> Thus, I am suggesting that the last sentence in the text above is replaced
> with the following: "Private and public keys, regardless of their ephemeral or
> static status, are always supplied in the first and the second arguments to the
> secretAgreement() function, respectively."
> 
> >
> > >
> > >>
> > >> [Acar, Tolga] I'd ask what I think the obvious question is. Why not
> > >> call deriveKey + exportKey with the output key length as an
> > >> algorithm parameter?
> > >>
> > >> Because the maximum number of bytes supported by that approach is
> > >> limited by the biggest key size supported in the implementation.
> > >> Also once you do a deriveKey with a particular algorithm, you may
> > >> have modified the output of the KDF to fit the structure of that
> > >> algorithm's keys (e.g. DES and parity bits).
> > > [Acar, Tolga] Got it, sounds good.
> > > Another supportive statement: It seems to me that deriveBytes()
> > combined with importKey() would also allow daisy-chained KDF calls. I
> > think that is also helpful.
> >
> > Agreed.
> >
> > >
> > >>
> > >> -----Original Message-----
> > >> From: Acar, Tolga [mailto:tolga.acar@intel.com]
> > >> Sent: Monday, May 20, 2013 11:19 AM
> > >> To: Vijay Bharadwaj; public-webcrypto@w3.org
> > >> Cc: Jim Schaad; Richard Barnes
> > >> Subject: RE: ACTION-84: Finishing support for key derivation/key
> > >> agreement
> > >>
> > >>
> > >>
> > >> > -----Original Message-----
> > >> > From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com]
> > >> > Sent: Sunday, May 19, 2013 11:44 PM
> > >> > To: public-webcrypto@w3.org
> > >> > Cc: Jim Schaad; Richard Barnes
> > >> > Subject: ACTION-84: Finishing support for key derivation/key
> > >> > agreement
> > >> >
> > >> > We had a call on this last Monday, and it looks like we have an
> > >> > initial proposal that would benefit from wider WG discussion. A
> > >> > summary of this proposal follows. Feedback is welcome.
> > >> >
> > >> > Goals and non-goals:
> > >> > - We want to support at least DH and MQV primitives over finite
> > >> > fields and elliptic curves. This is likely > 90% of the usage for
> > >> > the foreseeable
> > >> future.
> > >> > - Supporting multi-party protocols, while nice in theory, adds
> > >> > complexity for not-big-enough gain. There are a large number of
> > >> > multiparty contributory key agreement schemes, none of which are
> > >> > widely
> > >> used in practice.
> > >> [Acar, Tolga] +1
> > >>
> > >> > - It is not necessary to support key confirmation schemes
> > >> > directly in the
> > >> API.
> > >> > We will simply provide enough access to the shared secret to
> > >> > allow key confirmations schemes to be added on top of the API.
> > >> > - There are likely going to be applications of KDF where you want
> > >> > to generate more bytes than the biggest key size supported by an
> > >> implementation.
> > >> > However, we don't have to support streaming derivation - i.e.
> > >> > something where the caller does not know how many bytes they
> want
> > >> > up
> > >> front.
> > >> > - Method names are cheap, but vendors hate to add lots of new ones.
> > >> >
> > >> > In particular, our low-level API should be able to support at
> > >> > least the following key agreement schemes. For each scheme, I
> > >> > have listed the parameters that each party needs:
> > >> > - Basic DH: Own private key, peer's public key.
> > >> > - Full DH: Own static private key, own ephemeral private key,
> > >> > peer's static public key, peer's ephemeral public key.
> > >> > - Full MQV: Own static private key, peer's static public key, own
> > >> > ephemeral key pair, peer's ephemeral public key.
> > >> >
> > >> > So with those considerations in mind, we would like to propose
> > >> > the following
> > >> > changes:
> > >> >
> > >> > 1. New method added to Crypto interface to support secret
> agreement:
> > >> >
> > >> > KeyOperation secretAgreement(Key myPrivateKey, Key
> peerPublicKey,
> > >> > AlgorithmIdentifier agreementAlgorithm, AlgorithmIdentifier
> > >> > derivationAlgorithm);
> > >> >
> > >> > The result from the KeyOperation is a non-extractable Key object
> > >> > for derivationAlgorithm. Ephemeral keys and key pairs are
> > >> > supplied as parameters to the agreementAlgorithm (subject to
> ACTION-83).
> > >> [Acar, Tolga] What is the advantage of putting ephemeral keys in
> > >> algorithm parameters instead of using importKey to create a key
> > >> object from an ephemeral key (or keys in plural), and passing the
> > >> key
> > >> object(s) as the first and/or second parameter to this call? The
> > >> importKey approach seems to create a simpler interface and
> > >> implementation, since an implementation would have only one place
> > >> to
> > look for keys.
> > >>
> > >> >
> > >> > Note that as a result of this, DH and ECDH algorithms will no
> > >> > longer support deriveKey. This support will be provided instead
> > >> > by the key derivation algorithms. This should simplify Section 19
> > >> > (algorithm support) a
> > >> little bit.
> > >> >
> > >> >
> > >> > 2. New method added to Crypto interface to output bytes from a
> > >> > KDF instead of a key object (since people derive IVs, nonces,
> > >> > etc. also using
> > >> > KDFs):
> > >> >
> > >> > KeyOperation deriveBytes(AlgorithmIdentifier kdfAlgorithm, Key
> > >> > baseKey, int bytes)
> > >> >
> > >> > This operation is supported by all keys that support deriveKey.
> > >> > The result of the KeyOperation is an ArrayBufferView with the
> > >> > given number of bytes derived from the baseKey. This is exactly
> > >> > the same as deriveKey except for the parameters dealing with
> > >> > specifying the target
> > >> key.
> > >> [Acar, Tolga] I'd ask what I think the obvious question is. Why not
> > >> call deriveKey + exportKey with the output key length as an
> > >> algorithm parameter?
> > >>
> > >> >
> > >> >
> > >> > 3. (from Richard) Possibly extend deriveKey and the above
> > >> > definition of deriveBytes so they can slice the output.
> > >> >
> > >> > Richard's use case for this is as follows: say a protocol wants
> > >> > to derive two AES keys and two IVs from a secret using a KDF.
> > >> > Then, the application could use the slice parameters to get the
> > >> > IVs from the KDF while ensuring that it was never directly
> > >> > exposed to the key material of the
> > >> AES keys.
> > >> >
> > >> > We did not reach consensus on this item during the call, but
> > >> > Richard said he would send out a more fleshed-out proposal on
> > >> > this
> > aspect.
> > >> >
> > >> >
> > >> > Please let us know if you have any comments, positive or negative.
> > Thanks!
> > >> >
> > >> > -Richard, Jim and Vijay
> > >
> > >

Received on Monday, 20 May 2013 23:07:30 UTC