On Mon, Jun 20, 2011 at 10:59 AM, Solar Designer <[email protected]> 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
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
