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.