A little background: RFC 2898 defines (among other things) the PBKDF2 algorithm for generating encryption keys based on a given password. The details are unimportant, but it produces a salted password hash that is computationally impractical to crack given a sufficiently long salt over enough iterations. RFC 2989 “recommends” an iteration count of 1000 or greater (section “4.2 Iteration Count”). It also says that salts “should” be at least 8 octets (or 64 bits) long (section “4.1 Salt”).
When reading RFC’s, terminology is extremely important in implementation. The words “should” and “recommend” are very different from the word “must” (check out RFC 2119). Things that say “should” are not required to conform to the spec; however, “must” explicitly defines an absolute requirement.
In the world of cryptography, “should” things are very important. Your algorithm may not be as secure as you think if you ignore the “should” stuff, even though you have implemented everything as defined in the RFC. In the case of the PBKDF2 algorithm, simply don’t use salts less than 8 octets and less iterations then 1000. Simple as that. It’s not required by the RFC, it’s just smart.
From a developer’s standpoint, the question always looms: Do I give my users enough rope to hang themselves? When implementing PBKDF2, should I even allow salts of less than 64 bits or small iteration counts? For super secure systems, the answer probably should be “no”.
Now, as a general rule, it’s a bad idea attempt to code your own hashing algorithms. There are only a handful of people on the planet who have a firm enough grasp of modern cryptography to understand all the intricacies and implications of improperly coded cryptographic algorithms. I am not one of those people, and odds are, neither are you. So just don’t do it, especially if there’s a tried-and-true implementation available.
With that said, if you are going to attempt to code your own algorithms, there are certain test vectors that you can run through your code to make sure everything works properly. For PBKDF2 derived keys, those test vectors are defined in RFC 6070. If you are testing PBKDF2 with HmacSHA1, this is the set of data you use to test.
Sooooooooo… I’ve been playing around with PBKDF2 a bit, trying my hand at coding the algorithm in various languages, and testing the implementations that exist in various frameworks. I know I just told you not to do such things, but in fairness I’m not trying to generate the HMACs myself. PBKDF2 isn’t a hashing alogrithm, it takes a bunch of hashes and squarshes them together in such a way that would be extremely difficult and time consuming to crack the key through traditional means. And yes, I said “squarshes”.
Anyway, in testing I find that there are frameworks out there that enforce the recommended salt length specified in RFC 2898. They are incapable of running 5 out of the 6 test vectors in RFC 6070 because their salt is “salt” or “sa\0lt”; both of which are less than 64 bits in length. Like I said “UGH!!!”.
I know this is relatively minor. You can always implicitly test the validity of algorithms by running the same test data through multiple known/working implementations. It’s just the principle of the thing, ya know?