Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120620170548.GA21742@openwall.com>
Date: Wed, 20 Jun 2012 21:05:48 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: handling different BINARY_SIZE values in a single format

Dhiru -

On Wed, Jun 20, 2012 at 10:13:07PM +0530, Dhiru Kholia wrote:
> EPiServer format can crack both SHA1 and SHA256 hashes.

BTW, this is not necessarily good since these are of different speed.
If one has hashes of both types, they may get a slightly larger
percentage of them cracked in the same amount of real time by running
two separate instances of John on the two hash types.

> However, the
> BINARY_SIZE for both these types is different. How can I handle this
> situation in cmp_* functions?
> 
> Currently, I have the following code which is valid for only SHA1 hashes.
> 
> static int cmp_one(void *binary, int index)
> {
>         return !memcmp(binary, crypt_out[index], 20); /* BUG: lesser
> of the two */
> }

This is sort of OK since 160-bit SHA-256 collisions won't be seen in
practice.  However, you may improve it by reducing BINARY_SIZE to 4
(32 bits) and doing the full comparison in cmp_exact() (which accepts
the source hash encoding).  This will also save memory and it might even
speed things up (better locality of reference).

> My proposal is to combine get_binary (standard JtR interface) with
> cracked_array approach.

Bad idea.  Please forget the cracked[] array approach and only recall it
when dealing with non-hashes. ;-)

Thanks,

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.