I'm a little confused though. S-crypt seems to be a symmetric encryption algorithm and to store passwords you need a one-way hash. I'm obviously missing something. What is it?
I see. Is there some documentation for the key derivation function that I missed? Or are we supposed to reverse-engineer the file encryption code to figure out how to use the the KDF? If the latter, that seems a little odd in light of the fact that you're actively promoting scrypt as a replacement for brcrypt and the concern you've expressed about people using crypto code incorrectly. I do not mean to imply that you are under any sort of obligation to provide documentation. But it seems to me that your stated purposes would be better served if the interface to the KDF were documented.
Oh come on, give me a little bit of credit here. Where is the scrypt key function defined? What is its signature? Are there any initialization functions that need to be called before calling scrypt?
Yes, I can figure all this out by reverse engineering the code. But is that really what you intend people to do? Even just a couple of sentences of documentation would save a lot of people a lot of head-scratching, e.g.:
"The scrypt key generation function itself is called crypt_scrypt. Its signature is in lib/crypto/crypto_script.h. The reference implementation is in crypo_script-ref.h. There are two optimized implementations, one for CPUs that have SSE support, and another for ones that don't. You don't have to call any initialization functions before calling crypto_scrypt."
Or something like that. If your goal is really for people to use this I think you'd see a pretty large ROI from the effort it would take you to write a paragraph like that and stick it in a README file in the distro.
Let me try to be excruciatingly precise here: you seem to be advocating scrypt for use as a password hash, but your implementation only provides file encryption functionality out of the box. To convert the code you provide to produce and verify password hashes requires some uncommon expertise because there are, as you yourself so often take pains to point out, many ways to get it wrong. My question is: is there some documentation that you have provided to make this task easier that I have overlooked? And if the answer is no, why not? It seems very odd for you to 1) advocate scrypt for use as a password hash, 2) caution people against writing their own crypto code, and then 3) provide neither the code nor the guidance necessary for a software engineer who is not already an expert in cryptography to actually use scrypt as a password hash.
