Regression of crypto.pbkdf2Sync post v0.10.x or API misuse?

[kzc]

I'm trying to get the same results from crypto.pbkdf2Sync for all node versions from 0.10.x onwards.

This code:

console.log(
  require('crypto').pbkdf2Sync(
    'password',
    Buffer('24ecaf7be94c3a5a37cc2d16abd79792d02c4c20ffb18b565548d60422df00d2', 'hex'),
    50000,
    16,
    'sha256').toString('hex'),
  process.version);

produces the following output when run against various node versions:

df8d6a0d99440db481034b3af1eb3126 v5.3.0
df8d6a0d99440db481034b3af1eb3126 v5.1.1
df8d6a0d99440db481034b3af1eb3126 v4.2.3
df8d6a0d99440db481034b3af1eb3126 v0.12.9
67d2b02210ddcb55b6434f899592e9af v0.10.41
67d2b02210ddcb55b6434f899592e9af v0.10.40

First of all, am I using the API correctly?

If so, what changed post v0.10.41 to produce differing results?

[kzc]

I ran the tests on OS X 10.9.5 against the official binary releases for darwin-x64, if it matters:

node-v0.10.41-darwin-x64.tar.gz
node-v0.12.9-darwin-x64.tar.gz
node-v4.2.3-darwin-x64.tar.xz
node-v5.3.0-darwin-x64.tar.xz

[mscdex]

74d9aa4 added the digest parameter for the crypto.pbkdf2*() methods (the change is also listed in the changelog here and here). Before that commit, SHA-1 was always used as the digest algorithm. That commit landed post-v0.10, so node v0.12 was the first "stable" version that supported the new parameter.

You can verify this by using 'sha1' instead of 'sha256' and you will see the same value as node v0.10.

[kzc]

@mscdex Thanks for the explanation and 'sha1' workaround.

In hindsight the API parameter difference was also apparent in the 0.10.x docs:

https://nodejs.org/docs/v0.10.9/api/crypto.html#crypto_crypto_pbkdf2sync_password_salt_iterations_keylen