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

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.

> 
> [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.

> 
> -----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:13:16 UTC