WebCrypto: Implement crypto.subtle.deriveKey (chromium-side).

content/child/webcrypto/algorithm_dispatch.h

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_CHILD_WEBCRYPTO_ALGORITHM_DISPATCH_H_
 #define CONTENT_CHILD_WEBCRYPTO_ALGORITHM_DISPATCH_H_
 
 #include <stdint.h>
 #include <vector>
 
@@ skipping 74 matching lines @@
           const blink::WebCryptoAlgorithm& algorithm,
           bool extractable,
           blink::WebCryptoKeyUsageMask usages,
           blink::WebCryptoKey* key);
 
 CONTENT_EXPORT Status DeriveBits(const blink::WebCryptoAlgorithm& algorithm,
                                  const blink::WebCryptoKey& base_key,
                                  unsigned int length_bits,
                                  std::vector<uint8_t>* derived_bytes);
 
+CONTENT_EXPORT Status
+DeriveKey(const blink::WebCryptoAlgorithm& algorithm,
+          const blink::WebCryptoKey& base_key,
+          const blink::WebCryptoAlgorithm& import_algorithm,
+          const blink::WebCryptoAlgorithm& key_length_algorithm,

[Ryan Sleevi, 2014/12/10 03:21:26]

Wait, why is |key_length_algorithm| different than |import_algorithm| here?

Your naming here doesn't match the spec naming, and so I'm confused as to what
your parameters are here.

[eroman, 2014/12/10 17:58:55]

I'll add a comment.

In the spec there is a single "derivedKeyType".
This dictionary is interpreted both as an import algorithm, and also as an input
to get key length.

The Blink side parses and normalizes the two algorithm flavors into separate
objects -- import_algorithm and key_length_algorithm.

It is true that "key_length_algorithm" ends up being a superset of the
information contained by import_algorithm in the case of Aes and Hmac (whose
"get key length" params are AesDerivedKeyParams and HmacImportParams
respectively). However because of the rigid types it is convenient to pass an
import parameters which can be used directly by ImportKey(), rather than having
to make code aware that ImportKey() may also receive an AesDerivedKeyParams.

[Ryan Sleevi, 2014/12/11 23:23:48]

Thanks. A comment for this sounds perfect.

[eroman, 2014/12/12 01:21:17]

Done. I added this comment:

// Derives a key by calling the underlying deriveBits/getKeyLength/importKey
// operations.
//
// Note that whereas the WebCrypto spec uses a single "derivedKeyType"
// AlgorithmIdentifier in its specification of deriveKey(), here two separate
// AlgorithmIdentifiers are used:
//
//   * |import_algorithm|  -- The parameters required by the derived key's
//                            "importKey" operation.
//
//   * |key_length_algorithm| -- The parameters required by the derived key's
//                               "get key length" operation.
//
// WebCryptoAlgorithm is not a flexible type like AlgorithmIdentifier (it cannot
// be easily re-interpreted as a different parameter type).
//
// Therefore being provided with separate parameter types for the import
// parameters and the key length parameters simplifies passing the right
// parameters onto ImportKey() and GetKeyLength() respectively.

+          bool extractable,
+          blink::WebCryptoKeyUsageMask usages,
+          blink::WebCryptoKey* derived_key);
+
 CONTENT_EXPORT scoped_ptr<blink::WebCryptoDigestor> CreateDigestor(
     blink::WebCryptoAlgorithmId algorithm);
 
 CONTENT_EXPORT bool SerializeKeyForClone(const blink::WebCryptoKey& key,
                                          blink::WebVector<uint8_t>* key_data);
 
 CONTENT_EXPORT bool DeserializeKeyForClone(
     const blink::WebCryptoKeyAlgorithm& algorithm,
     blink::WebCryptoKeyType type,
     bool extractable,
     blink::WebCryptoKeyUsageMask usages,
     const CryptoData& key_data,
     blink::WebCryptoKey* key);
 
 }  // namespace webcrypto
 
 }  // namespace content
 
 #endif  // CONTENT_CHILD_WEBCRYPTO_ALGORITHM_DISPATCH_H_