[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP28362EFCB05F3CE60D9632BFDCB0@phx.gbl>
Date: Thu, 2 Aug 2012 22:34:13 +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: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?
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.
