Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 24 Jul 2015 18:10:30 +0200
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: my yescrypt and lyra2 benchmarks

On Fri, Jul 24, 2015 at 12:01:33AM +0200, Agnieszka Bielec wrote:
> 2015-07-23 18:35 GMT+02:00 Solar Designer <solar@...nwall.com>:
> > On Thu, Jul 23, 2015 at 01:07:57PM +0200, Agnieszka Bielec wrote:
> >> outside in set_salt()
> >
> > This isn't entirely outside.  With many hashes with different salts
> > loaded for cracking at once, set_salt() will be invoked once per each
> > (at most) max_keys_per_crypt candidate passwords.
> 
> but I have
> if(prev_saved_salt.m_cost==saved_salt.m_cost &&
> prev_saved_salt.nThreads==saved_salt.nThreads &&
> prev_saved_salt.nCols==saved_salt.nCols)
>         return;
> 
> I was thinking about only choose the biggest values but lyra2 has many
> parameters and many arrays and if I had wanted to choose the biggest
> all arrays here there would exists the situation that we don't have
> enough memory and we have enough memory using this code above.
> anyway for the same costs (and they are the same here) this isn't bad

OK, this makes some sense.

> >> >> in yescrypt I'm allocating in crypt_all() but only at first call
> >> >> crypt_all(), I didn't changed function yescrypt_kdf() and
> >> >> yescrypt_kdf_body(),
> >> >
> >> > Sounds fine.
> >> >
> >> >> can this be like here?
> >> >
> >> > I don't understand your question.
> >>
> >> I'm asking if it's ok to have allocating at first call crypt_all, above
> >
> > Yes, that's OK.  The only overhead is then a conditional branch, which
> > is clearly negligible compared to the time spent in these slow hashes.
> 
> even there is no overhead in this situation (--test is passed and
> --skip-self-test is not passed)

I don't understand what you mean by this, except that we appear to be
talking of different things.  Nevermind.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ