Re: Expected algorithm ’type' for the prf parameter of the Pbkdf2Params dictionary

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

> All,
>
> What is the expected algorithm ’type' for the prf parameter of the
> Pbkdf2Params dictionary:
> 1. A symmetric signing hash function (e.g: prf :  {name:“HMAC”, hash:
> {name=“SHA-1”}} )
> 2. A digest function, and we always automatically wrap it with HMAC (prf :
>  {name=“SHA-1”} )
> 3. Either a symmetric signing hash function or a digest function. If it is
> a digest function we automatically wrap it with HMAC
>
> Currently everybody uses HMAC, so we could go for option 2 and make it
> easier for the user of the API and automatically wrap an HMAC around the
> provided  hash function. But what if a vulnerability is detected in HMAC
> and a hypothetical HMAC2 is recommended instead of the vulnerable HMAC. So
> we would preferable do option 3 or 1, reading the spec I’m not sure what
> the expected behaviour is, my guess is option 1, but I’m not sure.
>
> Kind regards,
>
> Nick
>
>
Option 1 seems correct. As per the PBKDF2 spec (RFC 2898), one of the
parameters of PBKDF2 is the prf, which is an AlgorithmIdentifier of the set
PBKDF2-PRFs. AlgorithmIdentifier in ASN.1 conceptually maps to the
Algorithm object.

Currently, the only PRF in RFC 2898 is HMAC with SHA1, and there are no
updates to it.

>From an API perspective, only Option 1 seems to be the correct one, but
even as I say that, it does seem 'slightly' inconsistent with the choice of
MGF1 for the PSS/OAEP case, since technically the MGF is also a variable in
the params.