Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Jul 2013 00:26:45 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: scrypt

On 30 Jun, 2013, at 19:05 , Solar Designer <solar@...nwall.com> wrote:
> On Sun, Jun 30, 2013 at 08:37:25PM +0400, Solar Designer wrote:
>> So I went ahead and implemented cleaner and better (but still far from
>> perfect) scrypt support for John the Ripper.
> 
> I forgot to mention that it's faster than Rafael's due to preserving and
> reusing of memory allocation(s) across scrypt computations.  My escrypt,
> which I had shared with Rafael, readily had this functionality - it only
> needed to be made use of in the format.
> 
> And indeed there's OpenMP support, which somehow was missing in Rafael's
> format.
> 
>> I've attached patch against the core tree.
> 
> I've now attached a newer revision of it.  The only changes since the
> revision I posted some minutes ago are to escrypt/crypto_scrypt-sse.c
> (more complete removal of the experimental defeat_tmto feature, which we
> don't need in JtR yet) and escrypt/Makefile.
> 
> Alexander
> <john-1.8.0.1-scrypt-2.diff>

I have committed this to bleeding (0814b02), and changed django-scrypt so it can coexist with scrypt, and so it builds and tests OK using the code in escrypt/ instead. Are these functions using SIMD for single candidates? Should django-scrypt use escrypt_r() instead of crypto_scrypt()? If so, that is for Dhiru to fix. Perhaps it's better to add django-scrypt support to scrypt instead, and drop django-scrypt.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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