crypto.subtle.deriveKey doesn't support that many derived key algorithms right now. In particular, it seems we should support HKDF.

https://hg.mozilla.org/mozilla-central/rev/58731d4cdf3a

FF119 MDN docs for this can be tracked in https://github.com/mdn/content/issues/29411.

This appears to be an update to SubtleCrypto.deriveKey().

The description says:

crypto.subtle.deriveKey doesn't support that many derived key algorithms right now. In particular, it seems we should support HKDF.

But then the actual patch

use the entire output of ECDH key derivation when the target algorithm doesn't specify a length r=jschanck

SO what does this actually deliver?

• Would I be correct in stating that following this update we support HKDF (we did not before?).
• Do we already support the other algorithms listed here: ECDH and PBKDF2
• Do we support all the derivedKeyAlgorithm options?
• Is there are wpt.live test I can run to verify what is supported by different browsers?

If it's just support for HKDF which was missing I'd probably just add a browser compatibility update: but if I do so, good to be able to know whether these are also supported on Chrome, Firefox and so on.

(In reply to Hamish Willee from comment #4)

• Would I be correct in stating that following this update we support HKDF (we did not before?).

Yes, as the derivedKeyAlgorithm in the document you link below.

• Do we already support the other algorithms listed here: ECDH and PBKDF2

Those are unchanged (we support them as algorithm in the linked document).

• Do we support all the derivedKeyAlgorithm options?

Yes.

• Is there are wpt.live test I can run to verify what is supported by different browsers?

https://wpt.fyi/results/WebCryptoAPI/derive_bits_keys?label=master&label=experimental&aligned (unfortunately I don't know which specific test illustrates this - there may not be one).

If it's just support for HKDF which was missing I'd probably just add a browser compatibility update: but if I do so, good to be able to know whether these are also supported on Chrome, Firefox and so on.

Chrome supports it.

@Dana, thank you. So to confirm what I am doing makes sense, and confirm broadly what else might be missing in the docs.

1. I added HKDF option to derivedKeyAlgorithm in the docs and a corresponding update in browser compatibility data.
2. Does this also add HKDF support to the algorithm param in SubtleCrypto.importKey() too?
3. I've also added PBKDF2 to derivedKeyAlgorithm - Have we supported this for lifetime of deriveKey()?
4. import() defines a number of other algorithms - are these valid for derivedKeyAlgorithm too: RSASSA-PKCS1-v1_5, RSA-PSS, or RSA-OAEP. IN fact there is a table in the spec here - which can be derivedKeyAlgorithm options?
5. Given your answer to 4, does FF support all of those from the first version? Which don't we support?

Last of all, and probably stupid, when would you want to create a derived HKDF key? The docs give an example for two users who exchange public keys, and use ECDH to create a shared AES key that they can use to communicate. Why would you instead create a derived HKDF key?

(In reply to Hamish Willee from comment #6)

1. I added HKDF option to derivedKeyAlgorithm in the docs and a corresponding update in browser compatibility data.

Awesome!

2. Does this also add HKDF support to the algorithm param in SubtleCrypto.importKey() too?

I believe we already supported that, so I suppose it makes sense to update the docs anyway.

3. I've also added PBKDF2 to derivedKeyAlgorithm - Have we supported this for lifetime of deriveKey()?

Actually, it doesn't look like that's working. I filed bug 1856679.

4. import() defines a number of other algorithms - are these valid for derivedKeyAlgorithm too: RSASSA-PKCS1-v1_5, RSA-PSS, or RSA-OAEP. IN fact there is a table in the spec here - which can be derivedKeyAlgorithm options?

I think just the AES ones, HMAC, HKDF, and PBKDF2. Certainly none of the RSA ones, and I'm fairly sure none of the EC ones.

5. Given your answer to 4, does FF support all of those from the first version? Which don't we support?

We've always supported the AES ones, and I think HMAC.

Last of all, and probably stupid, when would you want to create a derived HKDF key? The docs give an example for two users who exchange public keys, and use ECDH to create a shared AES key that they can use to communicate. Why would you instead create a derived HKDF key?

It's for if you want to derive an HKDF key to then derive other keys from that key, basically (so rather than just one AES key, this lets you create a number of derived AES keys, for example).

Thank you! I have tried to update the BCD for the derivedKeyAlgorithm options on deriveKey(). Decided not to do that for the import at this time because it is out of scope for my release. But if we ever touch the import method I will. Docs/compatibility changes now in review.