[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 02 Aug 2012 22:21:09 +0200
From: magnum <john.magnum@...hmail.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 2012-08-02 22:08, 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
This (or a variation) has been mentioned before. I suggest that [new]
GPU formats re-use old proven CPU formats' valid(), prepare(), split()
and other such functions, as well as the test vectors, as-is. At least
until there's a reason not to. In this case I believe the CPU format
evolved in parallel with the GPU ones, and we did not have git so the
"templates" was ancient. Hopefully the same would not happen again.
magnum
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.
