[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP16937977A19388CBAA3C9A7FDCB0@phx.gbl>
Date: Thu, 2 Aug 2012 22:18:23 +0200
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: mscash2: CPU and GPU formats disagree about canonical
hash representation (and use different test vectors)
On 08/02/2012 10:08 PM, Frank Dittrich wrote:
> I noticed this with the contest edition during CMIYC 2012, but skimming
> over the john-1.7.9-jumbo-6-fixes branch, I think the problem exists in
> all trees.
>
> The CPU format supports a variable iteration count (default being
> 10240), and always uses the iteration count as part of the canonical
> hash representation, like this:
>
> $DCC2$10240#test1#607bbe89611e37446e736f7856515bf8
>
> OTOH, mscash2-cuda and mscash2-opencl don't include the iteration count
> into the canonical hash representation, but IMO they should,even if they
> only support a hard coded iteration count of 10240, instead of this:
>
> $DCC2$eighteencharacters#fc5df74eca97afd7cd5abb0032496223
To be more specific, it is not just that the canonical hash
representations differ, it is even worse.
The CPU format implementations doesn't recognize hashes written into the
pot file by GPU format implementations as valid, and vice versa.
(Of course, GPU format implementations cannot treat hashes with an
unsupported iteration count (i.e., != 10240) as valid.)
This is unfortunate, because hashes cracked by one implementation are
still counted as uncracked when loading the same hash file for cracking
with another implementation.
Frank
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.
