[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Jun 2013 00:06:07 +0100
From: Rafael Waldo Delgado Doblas <lord.rafa@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: scrypt
Hello,
Thank you Yaniv, I will do that.
Rafa
2013/6/11 Yaniv Sapir <yaniv@...pteva.com>
> 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.
