[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150723163526.GB1935@openwall.com>
Date: Thu, 23 Jul 2015 18:35:26 +0200
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: my yescrypt and lyra2 benchmarks
On Thu, Jul 23, 2015 at 01:07:57PM +0200, Agnieszka Bielec wrote:
> 2015-07-23 3:47 GMT+02:00 Solar Designer <solar@...nwall.com>:
> > On Wed, Jul 22, 2015 at 09:40:02PM +0200, Agnieszka Bielec wrote:
> >> yes, but in Lyra2 I'm allocting small parts in malloc and big parts in
> >> *_region before crypt_all
> >
> > In other words, you do still have some memory (de)allocation overhead in
> > the cracking loop for Lyra2? That's not great. Even if the overhead is
> > actually negligible (since those allocations are small), we wouldn't
> > know that reliably until we've tried eliminating it. Please do.
> >
> > ... or did I misunderstand, and those small malloc()s are invoked
> > outside of the cracking loop? Where?
>
> 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.
> >> 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.
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.
