Follow @Openwall on Twitter for new release announcements and other news
[<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.