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

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

From: Ryan Sleevi <sleevi@google.com>
Date: Mon, 20 May 2013 14:51:46 -0700
Message-ID: <CACvaWva03Ps2eF01ZXEcGjmru-4AzJYLNP_72idpmjs6kcRf_g@mail.gmail.com>
To: "Acar, Tolga" <tolga.acar@intel.com>
Cc: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>, Jim Schaad <ietf@augustcellars.com>, Richard Barnes <rlb@ipv.sx>
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] 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 21:52:17 UTC

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