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: http://www.openwall.com/lists/oss-security/2011/06/20/2 http://www.openwall.com/lists/oss-security/2011/06/20/6 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. Alexander _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
