Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Jun 2013 08:11:25 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: scrypt

On Wed, Jun 12, 2013 at 02:27:42PM +0200, magnum wrote:
> We actually have Colin's reference implementation in bleeding-jumbo, added by Dhiru for the "scrypt" format (with format_name django-scrypt). And Jim optimized it to 2x. I haven't looked at it but maybe it should be renamed to django-scrypt (and your revisions merged)?

Ouch!  Dhiru - you should start announcing your additions to the tree in
here.  At least new formats.  Somehow I missed this one in git.

It's a pity that Jim spent time on this.  The reference implementation,
by definition, was not optimized.  Colin, the original author, also
provides two other implementations, which are much faster (more than 2x
over reference).  There's no point in us optimizing the reference
implementation in any way - we simply should drop and replace it.

I think we should start over, taking my escrypt and building a format
around it.  We can have it support django's encoding syntax along with
the main syntax that escrypt supports.  Initially, though, we may keep
Dhiru's scrypt_fmt_plug.c mostly intact (as a separate format) - just
have it call crypto_scrypt() as provided by escrypt.

The reference implementation is good for initial playing with the
time-memory tradeoff, though - not trying to get it to run fast, but
getting it to work at all, before re-doing it for the optimized code.
(I did all of this a while ago already, but it's a good exercise for
someone else who is just starting with this stuff.)

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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