Re: What is the baseKey for deriveKey when using PBKDF2?

On Wed, Nov 6, 2013 at 3:08 AM, Nick Van den Bleeken <
Nick.Van.den.Bleeken@inventivegroup.com> wrote:

>  Hi,
>
>  I’m a bit puzzled what the baseKey parameter should be for deriveKey
> when using the PBKDF2 algorithm (my guess is just a null object).
>
>  The function signature of  deriveKey is:
>
>  Promise<any> deriveKey(AlgorithmIdentifier algorithm,
>                          Key baseKey,
>                          AlgorithmIdentifier? derivedKeyType,
>                          optional boolean extractable = false,
>                          optional KeyUsage[] keyUsages = []);
>
>
>  algorithm would be something like {name: “PBKDF2”, salt: mySalt,
> iterations: 100000, password: myPassword, prf:{name:“HMAC”, hash:
> {name=“SHA-1”} }
> derivedKeyType could be something like  {name: “ AES-GCM”, iv: myIV,
> length: 512}
> extractable and keyUsage are trivial, just the values that you want them
> to be ;)
>
>  The baseKey is not required in this use case because all information is
> already available to derive the AES-GCM key.
>
>  The spec hints with a note, that if the password is omitted, the user
> agent prompts for a password, so it doesn’t make sense to get the password
> in a key as input for the keyDerivation.
>
>  Another option would be to providing the password (and the salt?) as
> input (baseKey) to deriveKey, but this is inconsistent with how we handle
> parameters in the rest of the spec.
>
>  It would be welcome to add a note to the spec if a null value is
> required for the baseKey parameter in the deriveKey function for PBKDF2,
> because I think other people might also so puzzled when reading the spec...
>
>  Kind regards,
>
> Nick
>
>  Relevant references to the spec:
> 1:
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#subtlecrypto-interface
> 2:
> https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#pbkdf2
>
>
Excellent point. Would you mind filing a spec bug on this?

baseKey cannot be NULL, given the IDL specified.

One possibility is to treat PBKDF2 as a generateKey method instead.
Another would be to make baseKey nullable, but that seems a bit odd.


> ------------------------------
>
> Inventive Designers' Email Disclaimer:
> http://www.inventivedesigners.com/email-disclaimer
>