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] 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). 

-----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 19:12:18 UTC