[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Jun 2011 03:08:52 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Either my test script is b0rken or BF has an 8-bit bug
magnum -
Thank you for reporting this!
On Mon, Jun 20, 2011 at 12:41:44AM +0200, magnum wrote:
> Can someone having access to an OpenBSD system verify the enclosed
> Blowfish hash? Or produce a correct one: It is supposed to be a single
> pound sign in ISO-8859-1, but I can't crack it (or any other non-ascii)
> with John.
>
> It's produced using Perl, Authen::Passphrase and I suspect the bug (or
> feature) is in that one. I read stdin as raw, which is usually what
> works best with Authen::Passphrase for non-Unicode formats and non-ascii
> plaintexts. I have also tried to read stdin with binmode set to
> iso-8859-1 and a couple other variants but nothing I've tried gets me a
> crackable hash.
Oops. In BF_std.c: BF_std_set_key(), change:
tmp |= *ptr;
to:
tmp |= (unsigned char)*ptr;
This gets your hash cracked.
Now I am wondering how Authen::Passphrase avoided the bug (IIRC, it used
my code from crypt_blowfish), and why I am getting different hashes for
8-bit chars produced by crypt() in Perl on Owl (which uses crypt_blowfish
in glibc on Owl). I'll need to investigate that. If crypt_blowfish has
the bug too, and it looks like it does, that's pretty bad, because it
means we have incorrect (incompatible with OpenBSD's) hashes in the wild
as well. Moreover, those might be weaker than expected, as sign
expansion in the OR operation may be overwriting key bits from other
characters (the exact impact needs to be analyzed). I am quite
embarrassed of that. I should have tested the 8-bit chars vs. OpenBSD
myself, years ago (when I released crypt_blowfish separately from JtR).
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
