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
Thanks. I'm still a bit confused by the description. It seems the $2x/$2y were introduced to work around a bug in a PHP implementation back in 2011, but not picked up by everyone, "Nobody else, including canonical OpenBSD, adopted the idea of 2x/2y. This version marker change was limited to crypt_blowfish.".
What systems is it important to interop with? System password/shadow files, defined by BSD and GNU libc, or PHP applications?
And the other bug mentioned affects only input passwords that are longer than 255 bytes. But the algorithm description says that password length is limited to 72 bytes, so then that shouldn't be an issue.
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.
I'd like to hear the long answer... If I want to generate a new bcrypt line, and I pass a new password and salt, and "$2b" in the settings input, will I always get an output string with "$2b" in it? And similarly for the other three variants.
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.
I see, it replaces the key setup.