[cryptography] Oddity in common bcrypt implementation
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:
> 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
[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....
More information about the cryptography