Support for deriveKey Method in Key Derivation Algorithms

[ruidazeng]

Enable support for the deriveKey method for key derivation algorithms, including ECDH, HKDF, and PBKDF2, over derivedBits. This approach allows for direct derivation of cryptographic keys from a base key and specified algorithm parameters, returning a CryptoKey object ready for immediate use. This implementation would more closely align with the Web Cryptography API specification.

[jonasfj]

There some notes on the design decisions here: doc/webcrypto-parity.md.

It something we could reconsider before declaring the API stable with a 1.0.0 release.

Personally, I'm not sure we need it, we could perhaps get away with documenting how to implement deriveKey using deriveBytes and importRaw. Perhaps we can even have tests to ensure that such an implementation is compatible with the behavior the browser has.

[jonasfj]

Filed #188 to explore if this is necessary or not.

I'm leaning towards the idea that we need a tutorial for how to do deriveKey using deriveBits and importRawKey. Ideally, with tests showing that this works.

Because adding direct support for deriveKey means that:

• Types get more complicated, as we'd either need to do:
  • (A) derive<targetKey>Key for each potential <targetKey> (such as AES-CBC, AES-CTR, etc), or,
  • (B) deriveKey<T>(KeyOptions<T> targetKey) with another static helper function AesCtrSecretKey.options() -> KeyOptions<AesCtrSecretKey> for each key that can be derived.
• It'd probably only make sense if we also do unwrapKey/wrapKey.
• We'd probably also need to support capabilities (CryptoKey.usages), which we today ignore when importing JWKs.

[jonasfj]

See also discussion in #53

[ruidazeng]

Filed #188 to explore if this is necessary or not.

I'm leaning towards the idea that we need a tutorial for how to do deriveKey using deriveBits and importRawKey. Ideally, with tests showing that this works.

Because adding direct support for deriveKey means that:

• Types get more complicated, as we'd either need to do:

  • (A) derive<targetKey>Key for each potential <targetKey> (such as AES-CBC, AES-CTR, etc), or,
  • (B) deriveKey<T>(KeyOptions<T> targetKey) with another static helper function AesCtrSecretKey.options() -> KeyOptions<AesCtrSecretKey> for each key that can be derived.

• It'd probably only make sense if we also do unwrapKey/wrapKey.

• We'd probably also need to support capabilities (CryptoKey.usages), which we today ignore when importing JWKs.

These makes sense to me. Are there any arguments for why this might not be necessary?

[ruidazeng]

See also discussion in #53

Nvm I just read #53