[cryptography] Oddity in common bcrypt implementation
solar at openwall.com
Mon Jun 20 10:59:52 EDT 2011
On Wed, Jun 15, 2011 at 04:22:55AM +0400, Solar Designer wrote:
> 3. Order of ExpandKey()s in the costly loop:
BTW, this inconsistency is seen even in bcrypt.c in OpenBSD - source
code comment vs. actual code.
> Then I released my bcrypt code from JtR for reuse, under the name of
> crypt_blowfish in 2000. Several Linux distros started using it (patched
> into glibc), as well as PostgreSQL's contrib/pgcrypto, CommuniGate Pro
> messaging server, and some other programs. More recently, this same
> code got into PHP 5.3.0+. Of course, those hashes are fully compatible
> with OpenBSD's.
I have to retract that statement. Yesterday, I was informed of a bug in
JtR, which also made its way into crypt_blowfish, and which made the
hashes incompatible with OpenBSD's for passwords with non-ASCII characters
(those with the 8th bit set). Yes, it was an unintended/inadvertent
sign extension. What's worse, in some cases it results in other
characters in those passwords being ignored. Very nasty, and embarrassing.
I am surprised this could go unnoticed for 13 years. I am trying to
learn some lessons from this.
More detail here:
Although the code fix is a one-liner, fixing this in all affected
software is difficult, especially where backwards compatibility matters.
I'd appreciate any suggestions.
More information about the cryptography