Join GitHub today
doc: Adding best practises for crypto.pbkdf2 #3290
@jasnell Very sorry for my late reply. I missed this.
@tomgco I have one question and one comment on the description in regarding salt.
IIRC, in PBKDF2 the salt is put into HMAC with the number of iteration counter so that its length is not necessary to match the length of the digest function. As in the example, the length of salt is 4. Of course, the longer is the better. Do you have any reason for matching with it?
Reading section 4 of RFC2818, https://tools.ietf.org/html/rfc2898#section-4 , and A.2.1 of NIST 800-132 , http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf , there is a use case to add a non-random octet to a salt according to its purpose. So the description above is not always the case. I think we need not to write a whole description as the same of that in the references above and it is enough to write a pointer to them with a short comment.
Description in regarding iteration is good. At first, I thought the iteration number of 100,000 in the example seems to be so large, but I found that it took only 1.6 sec on my host so it is no problem.
No I didn't, thanks for the ping.
I use it as a general rule of thumb, based on the strength ( and the final computed result ) of the hash function (from SHA-256 onwards), A publication that NIST released in 2010 recommended the minimum salt length be 128bits, so to recommend the length of the digest function exceeds the recommended values and grows with the introduction of longer hash-functions.
Although that is true, the complexity that would be needed to be put into the documentation would possible make it more difficult and scarier for a developer who is less security minded, but wants to use sensible defaults. And I could argue that if someone needed to implement an octect to signify the use case then this would fall outside of what should be in the documentation; for me, if we was to introduce that, it would be the same as describing the algorithm behind PBKDF2.
However you make a good point that maybe we could add the RFC as a link, and encourage the users of node to read through it to understand each parameters in more detail?
Maybe we should make a note also around how the longer the function takes the more desirable it is, as it becomes much harder for an attacker.
Thanks for the feedback,
Let me know if you would like me to incorporate anything that I have mentioned in this message in the PR, Thanks
@tomgco I agree the doc should not be too complex. I also think its correctness is important because it is not only for novices but also for experts.
For simplicity, it is not necessary to add the description of a use case of a purpose prefix in the salt. Let it to the reference.
Brilliant, I agree, thanks.
I have updated the PR accordingly, and believe we are all in agreement with the changes?