Re: PBKDF2 questions

On Wed, Mar 5, 2014 at 12:43 PM, Mark Watson <watsonm@netflix.com> wrote:

> 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 ?
>

No. The site is choosing it's own security parameters. The UA is making no
statement about them, merely facilitating the 'hands off approach'


> - 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.
>

No. If a site wants to trade deniability for usability, it can.

The generateKey is not at all about improving security for users, per se.
Sites can still misbehave. It's a way for sites or applications that want
to be able to state "I didn't have the key" to be able to state so.


>
> ...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
>>>
>>
>>
>