Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Jun 2013 00:06:07 +0100
From: Rafael Waldo Delgado Doblas <>
Subject: Re: Parallella: scrypt


Thank you Yaniv, I will do that.


2013/6/11 Yaniv Sapir <>

> 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 <
>> 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 <>
>>> Rafael -
>>> I notice that you have edited the project description as we had
>>> discussed off-list:
>>> 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:
>>> 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):
>>> 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:
> Web:
> ============================================================
> 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.