Tutorial for doing `deriveKey` using `deriveBits` + `importRaw`

[jonasfj]

It would be nice to show using a tutorial (and tests) that we don't need to support deriveKey because the functionality is trivial to replicate using deriveBits and importRawKey.

TODO:

• Test this for multiple key types.
• Write tests that shows this works and produces the same result as it would in the browser.
• Write a doc/derive-key.md tutorial demonstrating how to do this.

[jonasfj]

I played around with gemini and got it to make an example that showed equivalence: https://gist.github.com/jonasfj/2590e1837d5ce264611c5576a7788968

But if I set keyLength = 256 in the example above it doesn't work. I can't explain why, and whenever I ask gemini it comes up with a lengthy explanation of why keyLength should be 256, and not 512.

But unless, I set keyLength = 512 in the example it doesn't work.

I'm clueless, probably we have to dive into the spec. Or the implementations, I get the same behavior in both Firefox and Chrome.

It's possible that if we tried with different primitives than HMAC then it would work differently.

---

The fact that it's hard to reason about the behavior of deriveKey is also a good argument for not implementing it.

[ruidazeng]

I played around with gemini and got it to make an example that showed equivalence: https://gist.github.com/jonasfj/2590e1837d5ce264611c5576a7788968

But if I set keyLength = 256 in the example above it doesn't work. I can't explain why, and whenever I ask gemini it comes up with a lengthy explanation of why keyLength should be 256, and not 512.

But unless, I set keyLength = 512 in the example it doesn't work.

I'm clueless, probably we have to dive into the spec. Or the implementations, I get the same behavior in both Firefox and Chrome.

It's possible that if we tried with different primitives than HMAC then it would work differently.

The fact that it's hard to reason about the behavior of deriveKey is also a good argument for not implementing it.

That is really interesting about the behavior of deriveKey. Is it however more intuitive for deriveKey functionality over deriveBits and importRawKey?

[jonasfj]

Is it however more intuitive for deriveKey functionality over deriveBits and importRawKey?

@ruidazeng are you sure, we'll probably end up with a design along the lines outlined in https://github.com/google/webcrypto.dart/issues/53. I'm not sure that's "easy" to use.

[ruidazeng]

Is it however more intuitive for deriveKey functionality over deriveBits and importRawKey?

@ruidazeng are you sure, we'll probably end up with a design along the lines outlined in #53. I'm not sure that's "easy" to use.

Mmm not sure. I wonder why WebCryptoAPI included these functionalities (deriveKey/wrapKey/unwrapKey) if the functionalities are trivial and difficult to use though.

[jonasfj]

Mmm not sure. I wonder why WebCryptoAPI included these functionalities (deriveKey/wrapKey/unwrapKey) if the functionalities are trivial and difficult to use though.

Because webcrypto includes capabilities, so you can make a key that you can export.

That's maybe useful for security in a JS context, if you fear that evil code might be loaded into the page and get hold of a key you're storing a global variable or something.

I think there is less risk of that in Dart, and if you want you could just wrap you key in an object that doesn't expose the export method.