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

> -----Original Message-----
> From: Vijay Bharadwaj []
> Sent: Sunday, May 19, 2013 11:44 PM
> To:
> 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 18:19:55 UTC