[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150425181030.GA21253@openwall.com>
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.
