Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 2 Jul 2013 00:26:45 +0200
From: magnum <>
Subject: Re: scrypt

On 30 Jun, 2013, at 19:05 , Solar Designer <> 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->

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.


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.