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 16:03:03 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Daniel's weekly report #12

Daniel,

On Mon, Sep 02, 2013 at 07:31:36PM +0200, D?niel Bali wrote:
> In the last few weeks I kept running into problems and almost none of those
> problems were solved. I still don't understand why things (like patching)
> work one time and don't work another time. The worst thing is that there is
> no documentation to read when we run into a problem, and it feels like I'm
> just trying random things.
> 
> I feel like giving up. I have absolutely no idea what I could do to
> optimize any formats. Could anybody help? Is there anything I can do?

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?

Alexander

Powered by blists - more mailing lists

Your e-mail address:

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