[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKGDhHWGRf_AGRWrhdfD+L-0OJqxCvFo0Nawfth_R5ggbc+UEw@mail.gmail.com>
Date: Sat, 9 May 2015 22:41:37 +0200
From: Agnieszka Bielec <bielecagnieszka8@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists
2015-05-06 9:21 GMT+02:00 Solar Designer <solar@...nwall.com>:
> On Sat, Apr 11, 2015 at 08:50:15PM +0300, Solar Designer wrote:
>> On Sat, Apr 11, 2015 at 07:28:29PM +0200, Agnieszka Bielec wrote:
>> > right, also there is malloc() in POMELO().
>> > will it be faster if I move it to somewhere else?
>>
>> Yes. In fact, it might be a good idea to enhance clones of POMELO's and
>> other PHC finalists' code with yescrypt-like API for this, and
>> specifically with a parameter similar to "yescrypt_local_t * __local".
>> You may also reuse yescrypt's alloc_region(). Such versions would be
>> usable not only in JtR, but also e.g. in user authentication services.
>
> It looks like you haven't done anything on this yet. You should. Right
> now, the performance figures you're getting for POMELO on CPU are
> significantly affected by the malloc() overhead. You should avoid this.
>
> Please take a look at how scrypt_fmt.c currently in jumbo avoids this.
> Its crypt_all() calls escrypt_r() with &(local[index]), where local[]
> is an array of structs holding metainfo about each thread's current
> memory allocation. escrypt_r() itself uses alloc_region() to replace
> those allocations with larger ones if/when needed (when it sees a salt
> string requiring a larger allocation). Eventually, scrypt_fmt.c's
> done() calls escrypt_free_local(&local[i]).
>
> I've since updated these interfaces a little bit in yescrypt as
> submitted to PHC (and the "escrypt" name is gone, too), but it's the
> same concept. If/when you introduce this for POMELO, etc. please reuse
> the alloc_region(), etc. code from yescrypt-v1, not the older "escrypt"
> revision currently in jumbo.
The speed isn't affected, I did it previously but there was some bug
for the bigger cost values. I gave up due to no better results. If you
want I can do this. We can inform user that eg. there is no enough
memory or crack passwords using less number of threads.
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.
