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

It's been a while, but I could swear we had this discussion before (though I don't remember the outcome).

Why not create basekey with something like importKey("raw", myPassword, {name: "PBKDF2", salt: mySalt, iterations: 100000, prf:{name:"HMAC", hash: {name="SHA-1"} } )

For PBKDF2, the password *is* the key material. It seems strange to me that one would include key material in the algorithm object.

From: Nick Van den Bleeken [mailto:Nick.Van.den.Bleeken@inventivegroup.com]
Sent: Wednesday, November 13, 2013 9:09 AM
To: Ryan Sleevi
Cc: public-webcrypto@w3.org
Subject: Re: What is the baseKey for deriveKey when using PBKDF2?

Ryan,

Sorry for the delay, I created the issue https://www.w3.org/2012/webcrypto/track/issues/58 (I was really bussy preparing my Wenbcrypto talk and doing other work...).

Kind regards,

Nick Van den Bleeken
R&D Manager

Phone: +32 3 425 41 02
Office fax: +32 3 821 01 71
nick.van.den.bleeken@inventivegroup.com<mailto:nick.van.den.bleeken@inventivegroup.com>
www.inventivedesigners.com<http://www.inventivedesigners.com>


[cid:image001.png@01CEE0B8.028AFAF0][cid:image002.png@01CEE0B8.028AFAF0][cid:image003.png@01CEE0B8.028AFAF0]

On 07 Nov 2013, at 00:20, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:




On Wed, Nov 6, 2013 at 3:08 AM, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com<mailto: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



________________________________

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