Date: Sat, 25 Apr 2015 21:10:30 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: [GSoC] John the Ripper support for PHC finalists On Sat, Apr 25, 2015 at 03:41:11PM +0200, Frank Dittrich wrote: > On 04/25/2015 01:39 PM, Solar Designer wrote: > > On Sat, Apr 25, 2015 at 04:27:49AM +0200, Agnieszka Bielec wrote: > >> I'm sending more benchmarking tests. > > > > These are very nice. Maybe you'd format this spreadsheet such that we > > could export it into a reasonably-looking PDF? And add descriptions of > > our systems in there (what actual hardware dev=1 corresponds to, etc.) > > Oh, and actual sizes corresponding to the different m_cost settings, in > > kilobytes. Then we'll "deliver" this as a report to the PHC community. > > Do we need to use SALT_SIZE 64 instead of 32 for this? > The impact of salt size might not be comparable zto m_cost/t_cost, but I > doubt it can be ignored. We should indeed correct our SALT_SIZE to be 64, but this should not affect performance at all because we're passing the actual salt lengths from our test vectors into POMELO. Also, POMELO is designed such that the salt length has almost no effect on its performance. It's only processed during initialization, not in the costly loops. Just to clarify: SALT_SIZE should be 64, and it is the maximum salt length that POMELO supports. Actual salt lengths may vary, and it's OK to keep whatever we happen to have in our test vectors for now. And this reminds me: Agnieszka, you mention "many salts" vs. "only one salt" in your spreadsheet. For POMELO, these should be the same number, and in fact we should remove the separate reporting of the two numbers once we make it one and the same. (To remove separate reporting, set BENCHMARK_LENGTH to -1.) Normally, these would differ significantly only when set_key() is slow - that is, if we managed to move some of the processing (that is key specific but not salt specific) out of the actual hash function and into set_key(). If much processing could be moved like that, it'd indicate a weakness of the PHC finalist. None of them should have design errors allowing for that. So my question is: are the "many salts" vs. "only one salt" benchmark results significantly different for any cost settings on any devices currently (and can you please post specific numbers)? If so, this may need to be investigated. Other than that, if the two numbers were actually significantly different, we'd care about the larger one for this research project, and it'd usually be the "many salts" one. ... Oh, I think "many salts" may in fact be measurably higher with low cost settings when targeting GPUs, because keys only need to be transferred to the GPU once, not once per salt. If this optimization is implemented, then yes we should keep separate reporting in the OpenCL format. And you should use primarily the "many salts" number. 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.