Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D2F1E5A.2040909@banquise.net>
Date: Thu, 13 Jan 2011 16:46:34 +0100
From: Simon <simon@...quise.net>
To: john-users@...ts.openwall.com
Subject: Re: opencl sha1 jtr and others some experiments and
 some suggestion

On 13/01/2011 09:58, Samuele Giovanni Tonon wrote:
> what and where is the main cause of this slowness?  I don't expect those
> huge numbers i can get from oclhashcat (552M/s ) since it's a totally
> different approach from john but i don't expect either to go
> that slow.
> 
> I did some bit of research and came out with two idea bothering me:
> the slowness could be because because i'm not "grouping" many cleartext
> password to process at the same time ( hint, that #MD5_NUM_KEYS you can
> find on rawMD5_opencl_fmt.c )  and because of the overhead of the
> exchange of data between GPU and CPU

You are most probably right. GPU implementations will be fast if the GPU
is always crunching and the data exchange happens behind the scenes.

With JtR you could increase the quantity of passwords cracked by
iteration, but you can't really use a double buffering technique that
would give you acceptable performances.

Actually you could, but you would probably have to get around the format
check code, and also the benchmark code.

You could do that by having set_key place everything in RAM while a non
blocking gpu crypt function is running. In the crypt_all function you
start the DMA transfer of the data you just set, wait for the gpu
cracking to finish, start the DMA transfer of the computed hashes and
run the next cracking job.

The cmp function would work on an old set of hashes, but it could be
managed by keeping the corresponding cleartexts and having get_key work.

I'm sure this is not making sense if you don't know how JtR is
architectured, and it is likely it wouldn't be making much more if you
do know :)

That's why I suggest GPU enthusiasts to work on the slow hashes (like
crypt MD5 or crypt DES), where the memory transfers will take a lot less
time than the actual cracking.

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.