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 22:45:13 UTC