Ryan,
Thank you for the reply. We should add a testcase for it, so it is documented.
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
[cid:image001.png@01CBF2F8.1DA19110][cid:image002.png@01CBF2F8.1DA19110][cid:image003.png@01CBF2F8.1DA19110]
On 07 Nov 2013, at 00:25, Ryan Sleevi <sleevi@google.com<mailto:sleevi@google.com>> wrote:
On Wed, Nov 6, 2013 at 3:40 AM, Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com<mailto: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.
________________________________
Inventive Designers' Email Disclaimer:
http://www.inventivedesigners.com/email-disclaimer
