Re: pbkdf2 on hackage Re: Re[2]: [Haskell-cafe] Password hashing

Thomas Hartman wrote:

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/PBKDF2

Since no one took up my code review request I just did the best I could and uploaded to hackage. There were indeed some mistakes in my initial post, fixed now. (Code review is still wished, though!)

Alas, documentation doesn't build with hackage, altough it does for me locally. (Seems like almost everything I do these days -- what am I doing wrong?!)

Also I'm open to folding this into a more established crypto package if there are any takers... psst, dominic.

I'd be happy to do so. In fact, I have another contribution which I need to work on so maybe now is a good time to roll my sleeves up. I haven't been following the thread on this. Could you give me some references? I assume it's a perfectly good cryptographic function, then it would be very helpful for me if you created a patch against the crypto repository.

Also, dominic, shouldn't your crypto package be added to category Cryptography (a cabal file change) so it lists aside the other crypto packages?

Yes good point - something else that needs doing. I've created the first ticket in the trac http://trac.haskell.org/crypto/ticket/1

...

...

If there are any crypto gurus who can code-review this I would be much obliged, and when I'm confident enough that this does the right thing I'll put it up on hackage.

I don't do much crypto so this *definitely* needs a review before it becomes a library?

It depends what you are going to use it for. I've put a big disclaimer on the crypto library because there are all sorts of attacks I've not checked it's proof against (e.g. who knows how long keys are kept in memory by a runtime system). You'd probably have to put in quite a lot of work researching how e.g. this is done in other implementations and seeing how the equivalent protection could be implemented in Haskell.

...

...

2008/11/26 John Meacham :

...

What you are using there is not a salt, but rather a secret key. The important thing about a salt is that it is different for _every user_. and you actually store the salt unhashed along with the hash. (it is not secret information). A salt protects against a dictionary attack, for instance, you might have a dictionary of hash's and the common passwords they go to but if you add a 32 bit salt, you would need 2^32 entries for each dictionary word, making such an attack unworkable. You can also trivially tell if two users have the _same_ password just by comparing the hashes without a salt.

John is right but it still doesn't stop you publishing your function which someone can then use as John describes.