|
Message-ID: <20150506072138.GA30773@openwall.com> 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.