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.