Has anyone attempted to add support for Blowfish encryption to Crypto.Password? I have some $2y$... prefixed passwords (interfacing with the PHP password_verify()) which I need to verify.
Has anyone attempted to add support for Blowfish encryption to Crypto.Password? I have some $2y$... prefixed passwords (interfacing with the PHP password_verify()) which I need to verify.
I've looked into it briefly. As I recall, you need access to some low-level functions that AFAIK are not exposed in Nettle.
/grubba
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
Has anyone attempted to add support for Blowfish encryption to Crypto.Password? I have some $2y$... prefixed passwords (interfacing with the PHP password_verify()) which I need to verify.
I've looked into it briefly. As I recall, you need access to some low-level functions that AFAIK are not exposed in Nettle.
Indeed. If I were to create that extra access in C, it should go into the Nettle library proper.
What are my chances of getting it added to Nettle? Or would adding it to Pike only, be easier?
Henrik Grubbstr?m (Lysator) @ Pike (-) developers forum wrote:
Has anyone attempted to add support for Blowfish encryption to Crypto.Password? I have some $2y$... prefixed passwords (interfacing with the PHP password_verify()) which I need to verify.
I've looked into it briefly. As I recall, you need access to some low-level functions that AFAIK are not exposed in Nettle.
Indeed. If I were to create that extra access in C, it should go into the Nettle library proper.
What are my chances of getting it added to Nettle? Or would adding it to Pike only, be easier?
When I spoke to Nisse about it ~half a year ago, it sounded like he would likely accept such contributions, but would not implement it himself.
/grubba
What are my chances of getting it added to Nettle? Or would adding it to Pike only, be easier?
When I spoke to Nisse about it ~half a year ago, it sounded like he would likely accept such contributions, but would not implement it himself.
Ok, I submitted a working bcrypt() implementation to the nettle-bugs mailinglist (a small miracle that the code actually worked the first time).
In the mean time I'll have to figure out how to compile in custom nettle libs, because it is likely to take a while until it trickles down through the Debian release channels.
P.S. Working on encryption code is almost as tricky as working on the Shuffler: Whenever you change something it is hard to predict what will break next.
In the mean time I'll have to figure out how to compile in custom nettle libs, because it is likely to take a while until it trickles down through the Debian release channels.
It's probably easiest to install your custom nettle under some specific prefix, and then pass --with-site-prefixes to Pike's configure.
Stephen R. van den Berg wrote:
When I spoke to Nisse about it ~half a year ago, it sounded like he would likely accept such contributions, but would not implement it himself.
Ok, I submitted a working bcrypt() implementation to the nettle-bugs mailinglist (a small miracle that the code actually worked the first time).
The Nettle submission process is complete, the bcrypt support is in there permanently now.
I've had look at the V2 patch. Maybe you Pike folks can provide a bit more context. Main questions:
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? 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.
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.
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?
Why does it need to fiddle directly with blowfish subkeys, rather than calling blowfish_set_key?
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.
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.
Niels M?ller (entering a radioactive zone) @ Pike (-) developers forum wrote:
What systems is it important to interop with? System password/shadow files, defined by BSD and GNU libc, or PHP applications?
Both.
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.
That was a bug in the input routine to some BSD systems. It allowed longer input, and then created severely broken hashes if you supplied > 256 characters.
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.
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.
If you ask for a scheme, you always get a hashed result back which complies with the exact same scheme. Actually, both $2b and $2y are bug free.
The Pike side of the bcrypt verify/hash support has been committed now. If there are still issues with the Nettle side, let me know.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Niels M�ller (entering a radioactive zone) ＠ Pike (-) developers forum
-
Stephen R. van den Berg