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-184.108.40.206-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
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.