Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for deriveKey Method in Key Derivation Algorithms #173

Open
ruidazeng opened this issue Nov 10, 2024 · 5 comments
Open

Support for deriveKey Method in Key Derivation Algorithms #173

ruidazeng opened this issue Nov 10, 2024 · 5 comments
Labels
enhancement New feature or request
Milestone

Comments

@ruidazeng
Copy link

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 jonasfj added the enhancement New feature or request label Nov 15, 2024
@jonasfj
Copy link
Member

jonasfj commented Nov 15, 2024

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
Copy link
Member

jonasfj commented Feb 12, 2025

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 jonasfj added this to the 1.0.0-rc1 milestone Feb 12, 2025
@jonasfj
Copy link
Member

jonasfj commented Feb 12, 2025

See also discussion in #53

@ruidazeng
Copy link
Author

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
Copy link
Author

See also discussion in #53

Nvm I just read #53

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants