[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150418222310.GA2340@openwall.com>
Date: Sun, 19 Apr 2015 01:23:10 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists
Agnieszka,
On Sat, Apr 18, 2015 at 11:59:58PM +0200, Agnieszka Bielec wrote:
> 2015-04-18 20:45 GMT+02:00 Agnieszka Bielec <bielecagnieszka8@...il.com>:
> > If benchmark encrypts one password on various gws, bencharking will
> > give better result than it should be due to less random memory access
> > I'm trying to investigate this
>
> It's true. All the time I was receiving wrong benchmarking results
> because if we have the same password to encrypt in various GPU's units
> function H which randomly accesses the memory works faster due better
> coalescing
Yes, we have this problem. It's not exactly one password (and not to
"encrypt", but rather to "hash") - it's all those in tests[] - but
that's still too few. We previously saw this problem manifest when
benchmarking a version of bcrypt-opencl that used global rather than
local memory. (For local memory, the benchmark results appear accurate
despite of this issue with the benchmark.)
I recently mentioned this problem here:
http://www.openwall.com/lists/john-dev/2015/04/08/6
> I've modified the file bench.c to random all keys and I think I've
> received true results now
Thanks! However, it's up to key jumbo developers such as magnum to deal
with this issue for real, as discussed in the other thread I referenced.
> not as bad ( comparing to previous ) in my opinion
I agree.
> I think that there are 3 possible solutions
> 1). modify bench.c like I've modified (but, are there a hashes which
> cannot receive some specific password values? )
For some, the password lengths matter. But this may be controlled with
parameters in the format definition.
> 2). spefify more tests cases for fmt_tests (but, sometimes we will
> need to pass 100 tests cases and sometimes more)
Actually, we may need tens of thousands for fair GPU benchmarks.
> 3). make fmt_main to generate password values if the answer in question is yes
You mean have e.g. init() update tests[]? Yes, but that's a hack, and
it may also be slow or complex.
> what are your opinions?
magnum is suggesting some integration with mask mode for this.
I'll defer to him to make a choice.
For now, please just don't use --test, and also don't spend more time on
the builtin support for specifying the costs to benchmark. I feel that
this distracts you from your actual project.
Instead, please generate test password hash files, and test wordlists
(or use e.g. incremental mode locked to same MinLen and MaxLen to
prevent the length switching overhead). Have your password cracked at
e.g. 500000 candidate passwords tested (e.g., see what your
length-locked incremental mode generates as its 500000th password, and
hash that to produce your test case). This will be about 5 seconds at
the speeds you're currently posting. And you'll note the c/s rate
reported on the status line when john terminates.
> BTW I think that I should make some charts comparing the speed of GPU
> with CPU in the future
Yes, please. Include the different CPUs/builds and different GPUs.
Also different cost settings, starting with the lowest supported.
Thanks,
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.
