Re: PBKDF2 questions

I have another question about PBKDF2.

We have decided that generateKey will explicitly ask the user for a
password. The advantage is that the UA can implement a non-spoofable UI and
the user will have the advantage that the site will never see the clear
password, only the derived key (for this reason, I required that
extractable be false when generateKey is called here).

There are two issues (neither of which should block last call):
- do we need to place any requirements on the deriveKey parameters that the
site can use to avoid it being easy to work backwards from derived keys to
the password ?
- it seems it is non-trivial for UAs to implement this in such a way that
the UX will be one that sites will choose to use. A plain dialog saying "
www.blah.com wants you to enter a password" is not very user-friendly.
Sites will generally want to provide some prompt explaining what the
password is for and also often sites want to place restrictions on password
strength (minimum length, contains upper and lower case etc.). If the UA's
native dialog doesn't have these properties, sites will likely choose to
prompt for the password the old-fashioned way, to the user's detriment. Do
we need to consider whether the site should provide prompt text, a strength
test callback etc.

...Mark




On Wed, Mar 5, 2014 at 11:52 AM, Mark Watson <watsonm@netflix.com> wrote:

> Ok, I will specify with HMAC for the moment. SP 800-132 has a normative
> minimum output length of 112 bits, which the RFC does not have. Do we want
> that ?
>
> ...Mark
>
>
> On Wed, Mar 5, 2014 at 10:01 AM, Vijay Bharadwaj <
> Vijay.Bharadwaj@microsoft.com> wrote:
>
>>  I doubt anyone uses PBKDF2 with something other than HMAC. In fact SP
>> 800-132 explicitly limits it to HMAC. So if you incorporate that limitation
>> then maybe SP 800-132 is a better reference.
>>
>>
>>
>> *From:* Mark Watson [mailto:watsonm@netflix.com]
>> *Sent:* Wednesday, March 5, 2014 9:54 AM
>> *To:* public-webcrypto@w3.org
>> *Subject:* PBKDF2 questions
>>
>>
>>
>> (1) I assume the correct reference is RFC2898
>>
>> (2) Do we need to support PBKDF2 with pseudo-random functions other than
>> HMAC ? Presently the parameters dictionary allows us to specify the
>> pseudo-random function, prf, in contrast to HKDF where we are allowed only
>> to specify the hash function to be used with HMAC
>>
>>
>>
>> Restricting to HMAC is much simpler to specify. If we allow arbitrary
>> PRFs, we need to define what properties they must have: support of sign
>> operation and import of arbitrary size raw key. These requirements restrict
>> us to HMAC anyway (from the existing algorithms).
>>
>>
>>
>> Does anyone use PBKDF with a PRF other than HMAC ? What ?
>>
>>
>>
>> ...Mark
>>
>
>