[cryptography] Oddity in common bcrypt implementation

Solar Designer 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:
> http://www.openwall.com/lists/crypt-dev/2011/04/29/1

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 mailing list