[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 6 May 2015 10:21:38 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists
Agnieszka,
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.
Thanks,
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.
