pbkdf2 seems to generate a wrong hash

[snakamura]

I tested pbkdf2 function from pwstore-fast and pbkdf packages, and found that these two libraries generated different results.

>>> Crypto.PBKDF.ByteString.sha256PBKDF2 "password" "salt" 1000 32
"c,(\DC2\228mF\EOT\DLE+\167a\142\157m}/\129(\246&kJ\ETX&M*\EOT`\183\220\179"

>>> Crypto.PasswordStore.pbkdf2 "password" (Crypto.PasswordStore.importSalt $ Data.ByteString.Base64.encode "salt") 1000
"\191>\158?\217=\248\233SG\207\231\138\139\&8\255\SUB\185g\SO]\244\&0\159%\255z\229\216\239\133U"

As a reference, I also generated a hash with pbkdf2-ruby and it generated the same result as pbkdf library.

>>> PBKDF2.new(:password=>'password', :salt=>'salt', :iterations=>1000, :hash_function => OpenSSL::Digest::SHA256, :key_length => 32).bin_string
=> "c,(\x12\xE4mF\x04\x10+\xA7a\x8E\x9Dm}/\x81(\xF6&kJ\x03&M*\x04`\xB7\xDC\xB3"

Did I miss something?

[alexanderkjeldaas]

What is the status of this? RFC6070 contains authorative test vectors.

[adinapoli]

Hi there, I'm the implementor of the pbkdf2 function. I tested the algorithm myself against the rfc vectors, and used the library to generate legacy hashes for a Django app I had, and it all worked fine, so this issue is coming as a surprise. Is this the second library you tried?

http://hackage.haskell.org/package/pbkdf-1.1.1.1

Alfredo

[snakamura]

Yes, it is.

[adinapoli]

Ok, I will take a look over the weekend if I have time. Please bear in mind though that the RFC6070 gives you test vector for pbkdf2 which uses HMAC-Sha1 as pseudorandom function derivation. My implementation uses internally hmac-sha256:

http://hackage.haskell.org/package/pwstore-fast-2.4.4/docs/src/Crypto-PasswordStore.html#pbkdf2

[tom-bop]

@adinapoli do you have any update on this?

[galenhuntington]

The problem apparently is that the salt is base64-encoded before it is used to hash. Indeed, if one bypasses it,

> Crypto.PasswordStore.pbkdf2 "password" (Crypto.PasswordStore.importSalt "salt") 1000
"c,(\DC2\228mF\EOT\DLE+\167a\142\157m}/\129(\246&kJ\ETX&M*\EOT`\183\220\179"

This is pretty irregular. Normally the encoding is just for outputting the string, and the salt is used directly as bytes during hashing. However, I suppose it's not any less secure, and for the sake of those already using this package it shouldn't be changed now. Still, I'd be reluctant to use this package for new projects, given this inconsistency with other PBKDF implementations.