Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 2 Aug 2012 22:34:13 +0200
From: Frank Dittrich <>
Subject: Re: mscash2: CPU and GPU formats disagree about canonical
 hash representation (and use different test vectors)

On 08/02/2012 10:21 PM, magnum wrote:
> On 2012-08-02 22:08, Frank Dittrich wrote:
> 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.

May be there is a reason do add different test cases or to skip some, I
don't know.
There are other differences between CPU, opencl and cuda for mscash2.

Implementation:                CPU opencl cuda
Max. password length in bytes:  27     31   27
Honours --encoding=name:       yes     no   no
Binary size                     16      4   16
Salt size:                      48     24   84

Binary size difference might be irrelevant.
--encoding=name support probably means, the CPU format will overwrite
some test vectors when invoked with --encoding=
If Opencl has a test case with a 31 bytes long password, it can
obviously not be used by the other two implementations.
And the salt different size also puzzles me:
Is the CPU size exactly twice the opencl size because it supports UTF-16
encoded user names with 24 characters?
And why does cuda support salt size 48?


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.