- From: Acar, Tolga <tolga.acar@intel.com>
- Date: Mon, 20 May 2013 23:06:56 +0000
- To: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Ryan Sleevi <sleevi@google.com>
- CC: "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Jim Schaad <ietf@augustcellars.com>, Richard Barnes <rlb@ipv.sx>
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