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

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

From: Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>
Date: Mon, 20 May 2013 06:44:10 +0000
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
CC: Jim Schaad <ietf@augustcellars.com>, Richard Barnes <rlb@ipv.sx>
Message-ID: <a412242628964beea36dbac24d7a13c5@DFM-CO1MBX15-08.exchange.corp.microsoft.com>
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.
- 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). 

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.


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 06:45:01 UTC

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