|
Message-ID: <20150814112644.GA24584@openwall.com> 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.