Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Sep 2013 15:47:25 +0200
From: Dániel Bali <balijanosdaniel@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Daniel's weekly report #12

Alexander,


2013/9/3 Solar Designer <solar@...nwall.com>
>
>
> Ouch.
>
> My impression from your recent weekly reports is that the primary issue
> you bumped into was with LDS usage, and we need LDS both for bcrypt and
> for the 64-bit addition instruction that we could use for SHA-512.  Is
> this right?
>
> If so, how about we temporarily switch focus from actually producing
> faster code to producing any working JtR format that would use some GCN
> asm code, even if it's not faster (not even potentially) than code we
> already have?  This could be something simple and ridiculous, like
> CRC-32 - just as a sample, to let someone else continue with the project,
> and potentially do so in JtR context.  In fact, once you have CRC-32 as
> a JtR format written using GCN asm, maybe you'd be able to proceed with
> e.g. raw MD5 while still avoiding the LDS issue (although indeed we'd
> need to solve that problem sooner or later)?
>
> Does this unblock your work now?
>

Thank you for your answer.
Yes this is a route that I could take.

CRC-32 could work. One question: what do you mean by CRC-32 as a JtR format?
Would this have to run inside the JtR "framework"?

Regards,
Daniel

Content of type "text/html" skipped

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ