[cryptography] Oddity in common bcrypt implementation

Jeffrey Walton noloader at gmail.com
Mon Jun 20 20:41:11 EDT 2011


On Mon, Jun 20, 2011 at 10:59 AM, Solar Designer <solar at openwall.com> wrote:
> 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.
>
Take consolation that you are not the first. From Schneiers website:

    NOTE: There is a bug in some source code implementations
    of Blowfish. Here are the details. The reference
    implementation does not have this bug.

The 'details' mentioned above is at
http://www.schneier.com/blowfish-bug.txt, and here's the crux of
Morgan's report:

    [bfinit] chokes whenever the most significant bit
    of key[j] is a '1'.  For example, if key[j]=0x80,
    key[j], a signed char, is sign extended to 0xffffff80
    before it is ORed with data....

Jeff



More information about the cryptography mailing list