Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 02 Aug 2012 22:21:09 +0200
From: magnum <>
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.


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.