Allow derivedKeyAlgorithm == 'HKDF' for deriveKey()

[Treeston]

I would like to use deriveKey with PBKDF2 to derive a primary key from a primary password. I would then like to use HKDF to derive multiple independent operational keys (using different info parameters) from this primary key.

This feels like a fairly basic setup. However, I cannot find a "proper" way to realize it after perusing the WebCrypto documentation on MDN.

Here are two possible approaches I want to avoid:

• Derive the operational keys from the primary password, possibly using different salts
  This is highly inefficient, and not an acceptable solution. PBKDF2 is, by design, costly. Needing to run PBKDF2 ten times as often will require me to reduce the iteration count by the same factor to remain within responsiveness targets.
• Derive some number of bits from the primary password, then use importKey (with algorithm == 'HKDF')
  This is a feasible workaround. However, the point of deriveKey seems exactly to avoid needing to juggle raw key data in memory.

To me, the easiest medium-term solution to this issue would be to permit 'HKDF' as a value for deriveKey's derivedKeyAlgorithm - or potentially some object that specifies the number of bits required, where necessary?

[twiss]

I agree that this would be an improvement. There's precedent for this with AES, where you can pass { name: 'AES', length: 256 } as the algorithm object. The same could be done here, by specifying a HkdfDerivedKeyParams dictionary, and changing the "get key length" operation to use it.

However, there is a (somewhat theoretical) risk of breaking backwards compatibility, since if you would (for some reason) pass { name: 'HKDF', length: 128 } today when deriving a key using ECDH P-521, for example, you would get all bits, instead of getting only 128 as you would after this change. Of course there's no reason to do that today, so the risk should be fairly minimal. But, given that there's a workaround using deriveBits (even though it's not ideal), I'm not sure if it's worth it.

And finally, it's not entirely obvious how best to get this change into the spec. The new charter of the WebAppSec WG calls for maintenance of the Web Crypto API via the WICG, e.g. by writing a separate document that monkey-patches the Web Crypto API spec. This change may be too small for that. But, if someone (maybe you?) wants to write spec text for this, and ideally some tests, and maybe even add it to the existing implementations, then I personally wouldn't be opposed to it.

[Diggsey]

I ran into this exact issue as well... Very frustrating.

[Juraj-Masiar]

Derive the operational keys from the primary password, possibly using different salts

I think there is another (similar) way - by using the hash of the primary password to derive operation key.
Since the hash is 256 bit long, it has a huge entropy so you could use PBKDF2 with minimal iterations and whatever salt (even reuse the salt from the primary password, if you need to derive only one key).

Please correct me if I'm wrong because I plan to use this approach.

[Download]

I am no cryptography specialist but I doubt that the hash of a string of information ever has more entropy than the original string....