[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libscrypt

I'm working on adding support for Scrypt in Nettle.  My local repository
is working including self tests and a decent API:


I'm working on pushing this upstream (PBKDF2 is in, Salsa20 almost in),
but I haven't had time lately to finish it.  Comments on the API etc is
most useful, probably best on the Nettle mailing list.

Btw, Nettle is a low-level crypto library under LGPLv2+, used for
example by recent GnuTLS.  It is similar to libgcrypt but with a simpler


mån 2012-11-05 klockan 04:18 +0400 skrev Solar Designer:
> Hi all,
> What's the current status on a libscrypt?  I will likely try optimizing
> the scrypt code (in fact, I've already played with that a bit) and then
> revising it (deviating from scrypt proper).  Indeed, it'd be convenient
> to be doing that with a libscrypt rather than with the scrypt file
> encryption program - and ultimately I'll need a library rather than a
> standalone program (in fact, I'd need to have scrypt's memory allocation
> split from the actual crypto).  Obviously, I'd want to contribute back
> whatever is relevant.
> On Sun, Jan 08, 2012 at 02:58:52PM -0800, Colin Percival wrote:
> > On 01/03/12 09:40, Dan Kaminsky wrote:
> > >    I just released phidelius, which basically uses the output of scrypt's PRNG
> > > to feed /dev/random and the like.  Go to dankaminsky.com/phidelius
> > > <http://dankaminsky.com/phidelius> to see why I'd do such a horrifying thing.
> > 
> > Cool. :-)
> I took a look at Dan's phidelius-1.01 as downloaded from:
> http://s3.amazonaws.com/dmk/phidelius-1.01.tgz
> It contains a verbatim copy of scrypt-1.1.6 plus more files (specific to
> Phidelius).  It does not turn scrypt into a library, but it does show
> how the existing scrypt code can be linked to and invoked.
> I also found an actual libscrypt, under that name even, as part of
> Chromium OS:
> http://git.chromium.org/gitweb/?p=chromiumos/third_party/libscrypt.git
> git clone http://git.chromium.org/chromiumos/third_party/libscrypt.git
> This one has a verbatim copy of scrypt-1.1.6 under libscrypt/src, and it
> adds autofiles at top level to build a library.  It appears to always
> use the slower crypto_scrypt-ref.c code.
> There's also Crypt-Scrypt in CPAN, which reuses Chromium OS libscrypt:
> http://search.cpan.org/~gray/Crypt-Scrypt/
> https://github.com/gray/crypt-scrypt
> Finally, there's Simon's modscrypt, which is a hack of the scrypt
> program to make it print the test vectors instead of doing what it does
> normally:
> https://www.gitorious.org/scrypt/modscrypt
> git clone git://gitorious.org/scrypt/modscrypt.git
> The only changes are:
> $ diff -urx .git scrypt-1.1.6 modscrypt | diffstat
>  lib/crypto/crypto_scrypt-nosse.c |   13 +++++++++++++
>  lib/crypto/crypto_scrypt-sse.c   |   13 +++++++++++++
>  main.c                           |   30 ++++++++++++++++++++++++++++++
>  3 files changed, 56 insertions(+)
> (somehow the -ref file is not patched to print the test vectors as well)
> modscrypt is not a library, yet it may be useful for my testing too.
> > I've attached the autocrap files.
> Would it be better to start with these or with those from Chromium OS?
> BTW, earlier today I found that scrypt mailing list archive is finally
> available via the web.  Here's the message I am replying to:
> http://mail.tarsnap.com/scrypt/msg00035.html
> > BTW, I'm planning on adding scrypt to Google
> > code soon (to join kivaloo, spiped, and libcperciva, with which it shares some
> > code).
> What's the status on this?
> Thanks,
> Alexander