Niels M?ller (entering a radioactive zone) @ Pike (-) developers forum wrote:
All the extra complexity for bug compatibility, is that still relevant? Is anyone using the $2a$, $2x$, $2y$ variants? What's done in BSD and GNU libc?
Being able to actually verify encoded old entries would seem vital to me. As to why, consider the fact that there are too many implementations running around that still use $2a$ or $2b$. Quick reference, look at: https://en.wikipedia.org/wiki/Bcrypt
Also, it's not entirely clear to me if these are fully under the control of the caller, or if the implementation selects variant depending on whether or not the input would trigger the old sign extension bug.
Well, the short answer is: if you use $2y$, no bug-compatibility is needed. If you use other variants, it gets murky.
Interface requiring library users to call strcat is not so nice. Also in the implementation, there seems to be string handling all over the place.
Agreed. This was the minimal implementation.
Would it make more sense to have two functions, one taking a password and structured algorithm parameters similar to, e.g., pbkdf2_hmac_sha256, and producing the magic $2b$...$hash, and second one taking as input $2b$...$hash and the password, and returning true or false?
I'll make an amended proposal, using more straightforward interfacing options.
Why does it need to fiddle directly with blowfish subkeys, rather than calling blowfish_set_key?
Because the bcrypt algorithm does things with the blowfish subkeys that are not supported using the standard blowfish_set_key.
Again, for reference, look at: https://en.wikipedia.org/wiki/Bcrypt The EksBlowfishSetup and ExpandKey (sadly) cannot be implemented using blowfish_set_key alone.