Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 8 Aug 2013 17:12:56 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Busted OpenCL formats

On 8 Aug, 2013, at 15:23 , Sayantan Datta <std2048@...il.com> wrote:
> On Thu, Aug 8, 2013 at 4:39 PM, magnum <john.magnum@...hmail.com> wrote:
>> What's with the bleeding changes to nt-opencl and raw-md4/5-opencl that you started in July? All three seem to be b0rken right now.
> 
> Can you please wait a while. I'm trying to optimize these formats as best as I can without compromising any performance for gpus, which makes them harder to run on cpu devices with 1 or 2 work item per work group. I'll probably need to write new kernels for cpu or try some #ifdefs to fix them.

No sweat, I just wondered :-)

> Also why are we trying to run them on cpu devices when we have well optimized code specifically meant for cpus? Should I add some code that cleanly ejects when a cpu device is detected for now? Later on I'll add a generic kernels for the above formats that will run on any device provided.

I confess I use CPU just for testing good habits and flexibility. OTOH our CPU code for raw formats scales very poorly on many cores. A really good kernel (under a good CPU driver) might reach nearly the same speed per core - *and* use all cores. Some people actually have 96 cores or more in one box...

Also, as much as I hate the silly LWS=1 limit of Apple's CPU device, there's no guarantee a future high performance device might have a similar limitation for one reason or the other. We have to ask it, and if it says there's a limit we must obey it.

>> raw-md5-opencl doesn't report candidates, it just says "CHECK". And it fails Test Suite.
>  
> I'm working on these issues please wait. It is difficult to recognize which call to get_key is meant for status checks and which are meant for procuring the cracked password. Although I have fixed this issue to some extent on my private repo but they are still not perfect. To get accurate status checks I'll probably need another function meant for status checks alone.

I'm not sure why this happens in bleeding though - the mask mode is not committed yet so how can index ever be > loaded_count?

Thanks,
magnum

Powered by blists - more mailing lists

Your e-mail address:

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