[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130522094108.GA6483@openwall.com>
Date: Wed, 22 May 2013 13:41:08 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: cmp_all on gpu for descrypt-opencl
On Wed, May 22, 2013 at 11:50:41AM +0530, Sayantan Datta wrote:
> I think the salt is always null during benchmark, why ?
Yes, because there's no code in place to generate a fake db_salt for
benchmarking. We may add it, or we might not bother. Why do you care?
> As a result I can't get the loaded hashes from loader directly.
Huh? I think you're wrong, and this is unrelated to what's (not)
available during self-test and benchmarking anyway.
> This is not the main problem as
> I can get the binaries to be loaded directly from test[]
Why would you? This only matters for self-test and benchmarking, but as
soon as you do anything custom like that, the self-test becomes less of
a test of the actual code anyway.
> But during
> benchmark returning anything other than *count gives FAILED(crypt all).
Yes. IIRC, I documented this in source code comments.
> Also cmp_all() is called whether or not we are doing it inside the
> crypt_all(). How do we bench the cmp_all integrated with crypt_all() ?
You simply define cmp_all() as always returning 1. (We may add a
fmt_default_cmp_all() for such use.) The extra function call cost is
negligible, since it stays on the CPU and is only done once per tens of
thousands of candidate passwords (passed to GPU, and even more generated
by GPU).
Alexander
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.
