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.