I'm working on adding support for Scrypt in Nettle. My local repository is working including self tests and a decent API:
https://www.gitorious.org/scrypt/nettle-scrypt 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 design. /Simon 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
