The main reason that I didn't provide bindings to PBKDF2 is that I didn't want to create a new output format. There's presently no crypt(3) format specified fo

The main reason that I didn't provide bindings to PBKDF2 is that I didn't want to create a new output format. There's presently no crypt(3) format specified for PBKDF2. So that means that I would need to invent one. That's not something I'm willing to do for a core language feature. Additionally, pbkdf2 is actually slightly weaker than bcrypt (partially due to the higher memory requirements of the later, 32kb vs < 1kb). So without a strong reason for including it, it wasn't included. However, the API is designed to be extendable. When scrypt gets bindings to crypt(3), it'll be made available. If PBKDF2 gets bindings, it'll be made available. If a new and stronger algorithm is made, it'll be made available (but not default for quite some time). But I personally am not willing to go out on a limb and create a new cryptographic specification for this project. And that's what it would have taken to put pbkdf2 into it. Hence, why it's not there...