[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Jun 2013 18:56:19 -0400
From: Yaniv Sapir <yaniv@...pteva.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: scrypt
Hi Rafa,
Looking forward to helping with this. When you get to the
Epiphany/Parallella programming part, don't hesitate to email if you have a
question.
Yaniv.
On Tue, Jun 11, 2013 at 6:53 PM, Rafael Waldo Delgado Doblas <
lord.rafa@...il.com> wrote:
> Hello,
>
> I will do the first task that you told me, implement scrypt in host mode.
> I would like to have a road map for the milestones. Also I would like to
> confirm if the milestones are:
>
> For the first half of the summer:
> First, implement scrypt in host mode.
> Second, experiment with scrypt time-memory tradeoff.
> Third, move it to epiphany.
>
> For the second half of the summer(early August or maybe before?) :
> Fourth, implement epiphany based Litecoin mining.
> Fifth, implement descrypt on Parallella.
>
> Furthermore, I need more information about descrypt.
>
> Best regards,
> Rafa
>
>
> 2013/6/11 Solar Designer <solar@...nwall.com>
>
>> 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
>>
>
>
--
===========================================================
Yaniv Sapir
Adapteva Inc.
1666 Massachusetts Ave, Suite 14
Lexington, MA 02420
Phone: (781)-328-0513 (x104)
Email: yaniv@...pteva.com
Web: www.adapteva.com
============================================================
CONFIDENTIALITY NOTICE: This e-mail may contain information
that is confidential and proprietary to Adapteva, and Adapteva hereby
designates the information in this e-mail as confidential. The information
is
intended only for the use of the individual or entity named above. If you
are
not the intended recipient, you are hereby notified that any disclosure,
copying,
distribution or use of any of the information contained in this
transmission is
strictly prohibited and that you should immediately destroy this e-mail and
its
contents and notify Adapteva.
==============================================================
Content of type "text/html" skipped
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.
