[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130611063722.GA22863@openwall.com>
Date: Tue, 11 Jun 2013 10:37:22 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Parallella: scrypt
Rafael -
I notice that you have edited the project description as we had
discussed off-list:
http://www.google-melange.com/gsoc/project/google/gsoc2013/lordrafa/22001
It now says "In this project I will add Epiphany support to scrypt code
using a Parallella board."
This is OK, although I hope you will have time to do more than just that
during the summer. Further tasks (stretch goals) may include: Litecoin
mining code both using Epiphany and not, FPGA programming (both for
scrypt/Litecoin just because we have the Zynq chip anyway, and for other
JtR "formats" where an FPGA is of more benefit - such as descrypt),
another/further attempt at using OpenCL to program for Epiphany.
For now, though, let's in fact focus on scrypt. We do not yet have any
scrypt code in JtR, so your first task is to add such support using the
host CPU. To do this, please use this encoding syntax:
https://www.gitorious.org/scrypt/scrypt-unix-crypt/blobs/master/unix-scrypt.txt
and my revision of Colin Percival's original implementations
(reference, somewhat optimized, and heavily optimized x86 SSE2
intrinsics) as attached to this message (this includes implementation of
the above encoding syntax as well).
My escrypt includes a defeat_tmto feature. For your project, please
keep it disabled - that is, set defeat_tmto = 0. This feature is a
work-in-progress and it's not part of scrypt proper.
(BTW, there's still much room for attack-specific optimization -
bringing more parallelism down to instruction level - but that's out of
scope of your project, at least until after you've implemented scrypt on
Epiphany. I think there's sufficient parallelism in one Salsa20 core to
fully use Epiphany, and we're limited by the 32 KB of local memory, so
bringing more parallelism to instruction level is not helpful for
Epiphany. However, it is likely helpful for modern x86-64 CPUs.)
You need to create a JtR format out of this. Please take a look at
c3_fmt.c and dummy.c in the JtR tree for some samples. I mention
c3_fmt.c because it simply uses crypt(3), whereas my escrypt tarball
provides a similar function. While normally we'd decode the ASCII
strings back to binary on loading of hashes to crack, and work on the
binaries then, for scrypt this does not matter much. It's so slow that
the time wasted on ASCII-encoding will be negligible. c3_fmt.c also
supports OpenMP with glibc's crypt_r(3), and my escrypt also provides an
MT-safe function - so you may do things similarly (to include OpenMP
support too).
Please try to complete this within a week. Then your next task will be
to experiment with scrypt time-memory tradeoff (still on the host CPU):
http://www.openwall.com/lists/crypt-dev/2013/03/21/1
and then to bring the actual scrypt computation (making use of TMTO as
needed) to Epiphany (in a revision of the JtR format - maybe a new
format name, so that both host and Epiphany versions could be invoked
from the same build of JtR).
I expect that you will need help with the TMTO - please feel free to ask
for it when you get to that point.
Frankly, I only expect sort of reasonable performance with very low
memory settings for scrypt - much like Litecoin's 128 KB (at which the
increase in computation is only about 2x). Thus, for practical use, the
JtR/host format is far more important than the JtR/Epiphany format. (We
generally don't have to use TMTO on host, but we do on Epiphany.) The
primary reason why we even bother to implement scrypt on Epiphany is for
Litecoin mining (where we know that scrypt's memory setting is only 128 KB,
which is sort of acceptable for Epiphany). Thus, for the Epiphany part
of the project to potentially make any practical sense at all, you do
need to proceed to implementation of Litecoin mining. For the Epiphany
part of the project to potentially make any practical sense for JtR in
particular (rather than merely for Litecoin mining, which is not exactly
a JtR task), you do need to proceed to implementation of other formats
(beyond scrypt) on Parallella (both chips) - I suggest descrypt (because
it'd make good use of the FPGA and reasonable use of Epiphany, and also
because it's not perfect on GPUs yet, unlike e.g. most things
MD5-based). So please try to allocate half the summer to those highly
desirable stretch goals.
Please let me know if you have any questions or/and comments.
Thanks,
Alexander
Download attachment "escrypt-0.0.35.tar.gz" of type "application/x-gzip" (12770 bytes)
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.
