Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Jul 2015 04:36:55 +0300
From: Solar Designer <>
Subject: Re: Agnieszka's weekly report #10


Some corrections/updates:

On Tue, Jul 07, 2015 at 04:21:43AM +0300, Solar Designer wrote:
> On Tue, Jul 07, 2015 at 01:53:51AM +0200, Agnieszka Bielec wrote:
> > Priorities:
> > -yescrypt
> I think your priorities should look more like this:
> - Tune all PHC finalists implemented so far for the same defensive use
> performance as is seen for bcrypt cost 5 for their most optimal
> implementations on "well", and use the resulting cost settings for the
> new test vectors (replacing those that were in there before):

You should already have the memory (de)allocation out of the loop for
this.  So you'd need to either implement it in some temporary way first
(like you have for Lyra2?) or complete this task first:

> - Switch all other PHC finalists implemented in JtR so far to use
> yescrypt's *_region() functions for memory allocation (effectively
> keeping it out of the loop):

As to third-party OpenCL and CUDA implementation of yescrypt:

> - Implement yescrypt in OpenCL.  May take a look at the existing OpenCL
> implementation being used for BSTY cryptocoin mining, and at Lyra2
> authors' CUDA implementation.  (URLs were on the PHC discussions list.)
> - Consider integrating Lyra2 authors' CUDA implementation of yescrypt as
> well.

I've just recalled that there was a BSTY coin miner CUDA implementation
as well, and it's likely faster (but more specialized) than the Lyra2
authors' one.  It uses some inline PTX assembly, but it's specialized to
BSTY's older revision of yescrypt and with some parameters hard-coded.
Maybe you'd be able to update it to current yescrypt and generalize it
for arbitrary parameters.


Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ