[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKGDhHUv2cJkLm2DjNH+mjo0Y_sMBqvhnLdJmzB6MgMpNeKkUQ@mail.gmail.com>
Date: Sun, 5 Jul 2015 13:27:51 +0200
From: Agnieszka Bielec <bielecagnieszka8@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 on GPU
2015-07-05 9:39 GMT+02:00 Solar Designer <solar@...nwall.com>:
> Agnieszka,
>
> On Sun, Jul 05, 2015 at 09:05:19AM +0300, Solar Designer wrote:
>> Is the memory (de)allocation overhead kept out of the loop already?
>> I previously suggested that you reuse yescrypt's yescrypt-platform.c:
>> *_region() functions for this, so that we use the same memory allocation
>> mechanism for all PHC finalists.
>
> Just to make it clear: this is important and high priority, for all of
> your PHC finalist formats.
>
> I feel I have to state it this way since you appear to have been
> ignoring/postponing this task for a long while.
it's out of the loop but not like in yescrypt
it's in set_salt and only when costs are different than previously
memory is allocated again, this is not effective only when we are
cracking passwords with different costs at once. in my test first and
second hash always have the same costs
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.
