[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Aug 2015 14:26:44 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: handling of high numbers of single-salt descrypt hashes
On Thu, Aug 13, 2015 at 10:59:21PM -0800, Royce Williams wrote:
> I am trying to load an unusually large number of descrypt hashes (128
> million), all with the same salt. (Yes, I know that this is bizarre.
> :) If the answer is "don't do that", I will be OK with that -- I can
> use hashcat instead for this analysis, which can handle this job with
> no problem).
No, the answer is "do it". First, please check if JtR is able to load
those hashes fine on CPU. It should. Then, we'll need to get
descrypt-opencl to work for this, too.
What speeds is oclHashcat giving you for this obscure case? How does
this compare to JtR on CPU?
Sayantan - you probably need to introduce a threshold on hash count
after which the old-fashioned way of sending the computed hashes back to
host would be used. Not only for descrypt-opencl, but also for other
formats where you implemented on-GPU hash comparison. Just determine
after which hash count (as well as hash count per salt, where applicable -
so it might need to be two thresholds, then) things start to become
worse than when having the hashes sent back to host. Then as a separate
task revise the OpenCL formats such that you can raise the thresholds,
and do that.
> With all six of my GPUs, I get similar results, but some of the errors
> result in john exiting uncleanly in such a way that memory usage on my
> GPUs not being freed up. I know that a reboot will clear the issue,
> but I'm not sure what other methods are possible.
This sounds like a driver bug, if the john processes are indeed fully
killed by that point.
Alexander
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.
